From nobody Tue Sep 1 06:28:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3EF1B30B9 for ; Tue, 1 Sep 2015 06:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp4T5Nf-EcpJ for ; Tue, 1 Sep 2015 06:28:33 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id A7D441B35DD for ; Tue, 1 Sep 2015 06:28:33 -0700 (PDT) Received: (qmail 1759 invoked by uid 0); 1 Sep 2015 13:28:33 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 1 Sep 2015 13:28:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id BpUR1r00E2SSUrH01pUUye; Tue, 01 Sep 2015 07:28:31 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=xskcdSivAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=u07AKapRAAAA:8 a=WpEKLkXjkxahXcKt2AoA:9 a=vabGb5E8FAig-NHM:21 a=T-hUytySZOPtYo10:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:Subject:From; bh=ZqMJMp0ZGlyoKELA88wxGeec66JkxKd1EhBDFD/DrcY=; b=bsguXIW400aq3LMoK1B1UI9vdyiRW9CRIT8/AEyryP1vWVBrlirAGw23SZx33N93xY4QrlqVNMCCWPShleHS+Df7zms65K23tJu35MbBMEiPRB2qJpsFnl9EdTQJ1/OL; Received: from box313.bluehost.com ([69.89.31.113]:60461 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZWlbv-0006gT-0Z; Tue, 01 Sep 2015 07:28:27 -0600 From: Lou Berger To: Andy Bierman References: <20150828.084127.247634384116908046.mbj@tail-f.com> <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> X-Enigmail-Draft-Status: N1110 Message-ID: <55E5A7F6.3000204@labn.net> Date: Tue, 1 Sep 2015 09:28:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 13:28:36 -0000 On August 28, 2015 5:33:41 PM Andy Bierman wrote: > On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: > >> On August 28, 2015 3:53:33 PM Andy Bierman wrote: >> >> > On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) > > >> > wrote: >> > >> >> >> >> >> >> -----Original Message----- >> >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka >> >> Sent: Friday, August 28, 2015 4:31 AM >> >> To: Martin Bjorklund ; andy@yumaworks.com >> >> Cc: netmod@ietf.org >> >> Subject: Re: [netmod] logical systems model >> >> >> >> >> >> ..... >> >> >> >> >> >> NACM, as well as all other modules we have, is based on the assumption >> of >> >> a single managed device. >> >> >> >> I think it is a typical trend that what once was a single instance >> becomes >> >> an array. If we did ietf-routing 20 years ago, there would probably be >> no >> >> routing-instance list. >> >> >> >> So I think it is a real problem that we can't migrate from a container >> to >> >> a list and reuse the container's data model. Groupings might help >> somewhat >> >> but they are still not fully reusable, if, for example, they contain >> >> absolute references. >> >> >> >> Lada >> >> >> >> >> >> One comment, if you forgive the pitch, but this problem / use case is by >> >> the way exactly one of the reasons for mounting, which allows you to >> >> introduce and impose an additional structure on top of an existing >> >> structure, and "insert" the existing structure into it. Augmentations >> etc >> >> can only add below the hierarchy, there is no way we can put a new >> >> container or list or whatever on top of an existing structure (without >> >> replicating the existing structure in a duplicate model), but peer-mount >> >> lets you do that. One use case used in Open Daylight involves >> organizing/ >> >> inserting device-level information into a network inventory, which is >> >> basically imposed "on top". >> >> >> >> >> > >> > I thing YANG Mount would be the best way to solve this problem. >> > It provides a standard way to do "chroot" and it is flexible. >> > The mechanics of a "datastore within a datastore" are the >> > same and independent of the source of the data (local, >> > remote, virtual, etc.) >> > >> >> So I think an example of how you see this working would helpful. >> >> Can one of you give an example of how this word work for a device (which >> may be physical or virtual) that allocates done resources, say interfaces >> to one logical entity (router, system, etc) and other resources to a second >> entity? And of course I want to manage all with yang and the first and >> second (sub) entity must be completely independent and ignorant of each >> other. >> > > Is there an example of this in your draft? > Sure, this is what logical-network-element and device view is all about and the example is actually in the slides from the last ietf that I pointed to a couple of weeks ago. > Do you mean an example of what the controller looks like? No, the server/device. > Maybe the analogy to chroot is not universally understood. > > The logical system knows only about itself: > > /interfaces > /system > > The / node is represented by or or in the protocol. > > > > > > > > > > Each logical system can have its own "eth0" interface or whatever. > They are mapped to real interfaces in the physical system. > It's the control of this mapping that is part of the question. .. BTW this "physical " system may itself be a virtual device (e.g., VM w/ NFV) . .. > All operations on the logical system are validated against its own > virtual datastore. YANG validation does not work on individual array > slices -- it only applies to an entire datastore. > > On the physical server there needs to be a data model to manage the > logical servers (as Martin suggested). > > <--- root on PHY server > <--------------- contains the real interfaces, > including eth23 > > > vs1 > > eth23 > eth0 > > > <----------- YANG mount point (virtual > server root) > > > eth0 > .... > > > > > > > > > On the physical system, the virtual roots are within list entries, > not at the top of the tree. The physical server data and/or any > of the logical servers can be accessed at once. Okay, so our logical-network-element is basically your virtual-server.root Think this is an interesting approach that is worth looking at to address the logical-network-element (virtual router/chassis/fabric/) problem. I like that it can go n-levels deep as it is basically recursive. The challenge will be dealing with mapping for every top level module that will need it, e.g., hardware, QoS. The only major restriction / change from what we are proposing is that we can allow multiple LNEs to manage one system. I'm suspect loosing this would be a big deal. I'll discuss with the DT. > > There is no extra indexing cost. The same data model (e.g ietf-interfaces) > can be used in physical and virtual server. YANG Mount provides a lot > more than simply identifying /virtual-servers/virtual-server/root > as the start of an embedded datastore. As Alex said, not all of it > needs to be standardized at once. Sure, but local mounting case does. Lou > > Th "virtual-servers" node is not under each because only > the physical server loads and supports that module. > > > > Thanks, >> Lou >> > >> > > > Andy > > >> > Andy >> > >> > >> > >> > ---------- >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> > >> From nobody Tue Sep 1 06:46:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828151B8477 for ; Tue, 1 Sep 2015 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1C9lppL6RqT for ; Tue, 1 Sep 2015 06:46:15 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 7E6711B8474 for ; Tue, 1 Sep 2015 06:46:14 -0700 (PDT) Received: (qmail 15699 invoked by uid 0); 1 Sep 2015 13:46:10 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 1 Sep 2015 13:46:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Bpm11r00W2SSUrH01pm4fa; Tue, 01 Sep 2015 07:46:09 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=q4tKywmclXmVBukMDmMA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=8SZfUT2iz/PFQtkzwOrgRXmHod4Khli7gYpiko2j+ro=; b=TOjIL5+v6IAuKwb1uCsUgNyLVtVsbs5cr3NbQZQxR+cyusHtay8/xUMHbPjaGhkWhVY/lA7fERuRnYKYfYvPjBGDCgA+jPc1+SofXciZe6Q2KmKjcjZXug1XyLTxengO; Received: from box313.bluehost.com ([69.89.31.113]:34191 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZWlsv-0001HP-Sf; Tue, 01 Sep 2015 07:46:01 -0600 To: "Alexander Clemm (alex)" , Andy Bierman References: <20150828.084127.247634384116908046.mbj@tail-f.com> <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55E5AC15.504@labn.net> Date: Tue, 1 Sep 2015 09:45:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 13:46:16 -0000 Alex, Thanks for the response - see below. I think the additions of 'mounts' that are themselves configurable (with support for local and recursion/cascades) is a really interesting and may turn out to be very useful/important. Although it does add its own complexity. That said, there are some specifics that will need to be addressed to use this approach: e.g. to quote: Mounted data is "read-only" data. YANG-Mount does not extend towards RPCs that are defined as part of YANG modules whose contents is being mounted. YANG-Mount does not extend towards notifications. Perhaps most of these limitations can be relaxed for local mounts. Also handling when a device/server doesn't support local mounts (or is invalid) On 8/28/2015 6:16 PM, Alexander Clemm (alex) wrote: > Hi Lou, > > > > Andy basically already provided the answer, but just to add to your > question: yes, there is an example in the draft (appendix A). > Actually, I was looking for an example on the server/device. I do like your example though, as it shows *exactly* the case of a sibling of /device (i.e, topologies). Thanks, Lou >... From nobody Tue Sep 1 07:14:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9481B2F0B for ; Tue, 1 Sep 2015 07:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVRU5FAFB__n for ; Tue, 1 Sep 2015 07:14:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3517A1B2F26 for ; Tue, 1 Sep 2015 07:14:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150901141448.9876.63906.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 07:14:48 -0700 From: IETF Secretariat Archived-At: Subject: [netmod] Milestones changed for netmod WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 14:14:50 -0000 Changed milestone "Submit YANG 1.1 to the IESG", set due date to October 2015 from March 2015, added draft-ietf-netmod-rfc6020bis to milestone. Changed milestone "Submit YANG guidelines update to the IESG", set due date to December 2015 from April 2015, added draft-ietf-netmod-rfc6087bis to milestone. URL: https://datatracker.ietf.org/wg/netmod/charter/ From nobody Tue Sep 1 07:29:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4AB1B3ECA for ; Tue, 1 Sep 2015 07:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BycXykjnsktK for ; Tue, 1 Sep 2015 07:29:47 -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 20D7F1B3D0C for ; Tue, 1 Sep 2015 07:29:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B4C714B2 for ; Tue, 1 Sep 2015 16:29:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6ANTFKkNb1Pz for ; Tue, 1 Sep 2015 16:29:42 +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 for ; Tue, 1 Sep 2015 16:29:42 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94FB42004E for ; Tue, 1 Sep 2015 16:29:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0HAauA6wqhFt; Tue, 1 Sep 2015 16:29:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A78F20048; Tue, 1 Sep 2015 16:29:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C8DA536E6936; Tue, 1 Sep 2015 16:29:36 +0200 (CEST) Date: Tue, 1 Sep 2015 16:29:36 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150901142936.GA60706@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 14:29:54 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-03-31 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2015-08-31-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 19th YANG 1.1 Virtual Interim Monday, August 31st, 2015, 17:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants DB = Dean Bogdanovic JS = Juergen Schoenwaelder KW = Kent Watsen LL = Ladislav Lhotka MB = Martin Bjorklund MJ = Mahesh Jethanandani * Definition of 'data tree' One option is to define 'data tree' to capture the choice currently embedded in the xpath expression evaluation section. This will make the xpath section way simpler. It is unclear whether this also brings simplification at other places. Is it a goal to remove any reference to in normative text? Note that RESTCONF does not have but instead a unified datastore (but it seems this got lately changed again). Observation: YANG does not define terms like 'datastore' or 'configuration datastore' or . RFC 6020 is silently assuming the import of these terms from RFC 6241. MB: I suggest to import the necessary terms. JS: I agree that key terms should be defined in the document or the definition should be imported. In an ideal world, we would have an architecture document defining architectural concepts and then YANG and protocol specifications would import from there. We can only slowly move to an ideal world in the IETF. KW: Should we refer to an 'intended' configuration datastore instead of the running configuration datastore? LL: Perhaps 'active' configuration with 'active' meaning 'running' on a traditional NETCONF server? KW: running + ephemeral => intended => applied MB: YANG 1.0 clearly uses running. If we create a new term, it must resolve to in NETCONF. LL: The issue for me is config false node refering to a config true node. With possible future extensions of NETCONF (or RESTCONF), referring to may not be useful anymore. MB: The notifications in the SMIv2 mapping to YANG make use of references to datastore content. JS: But this is accomplished via leafrefs, not via xpath expressions. Resolution: We keep the choice text in xpath section. We will replace with 'running configuration datastore'. What about data tree? It seems to make sense to expand its definition but we need to figure out where the expansion would not be OK. LL volunteers to take a look. MB will do this as well. --Dxnq1zWXvFF0Q93v-- From nobody Tue Sep 1 08:05:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ED21B39F7 for ; Tue, 1 Sep 2015 08:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO9soP7MTR2Y for ; Tue, 1 Sep 2015 08:05:30 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id D19F71B5361 for ; Tue, 1 Sep 2015 08:05:21 -0700 (PDT) Received: (qmail 14409 invoked by uid 0); 1 Sep 2015 15:05:20 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 1 Sep 2015 15:05:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Bx5C1r0122SSUrH01x5Fm0; Tue, 01 Sep 2015 15:05:19 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=84BadPHTAAAA:8 a=48vgC7mUAAAA:8 a=S1agpBxfS-h6xHnnXsMA:9 a=pILNOxqGKmIA:10 a=uATRSz0lsMwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=WHlQ2Ur3DeFcz/ZWznnaQ/htYfF9lEu1Wsa4fqcqNKw=; b=hR+bi1bI/Cv/9Yh/a+Tcu73qD9y0L1UBqlnCLuXUbLKt4vGF/zaVOGhMQoZXfkvlhqoDJitkrq/g+KjhzO5s/cTF5Qm9WHPOk0h+mLwKnTQwWzR7tf86aErpA1nr2qEP; Received: from box313.bluehost.com ([69.89.31.113]:47884 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZWn7Z-0000V4-Kh; Tue, 01 Sep 2015 09:05:13 -0600 To: Ladislav Lhotka , Randy Presuhn , netmod@ietf.org References: <8207307.1440875332299.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55E5BEA5.7000500@labn.net> Date: Tue, 1 Sep 2015 11:05:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [netmod] New Yang issue? (was Re: Motivations for Structuring Models) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:05:33 -0000 On 8/31/2015 11:04 AM, Ladislav Lhotka wrote: >> Randy Presuhn writes: >> ... >> Life is such that once a resource has been modeled, it will be >> used/re-used/embedded in systems in ways in which its designers >> couldn't be expected to imagine. A consequence of this is that >> if instance naming is completely locked down when the management >> interface for a resource is first defined (as it is in SNMP) then >> all sorts of peculiar hacks will be needed to deal with, for example, >> virtual routers. Unfortunately, an SNMP/SMI-like mindset is so >> pervasive that folks seem to overlook that there are other ways >> to deal with this situation. >> >> What GDMO did was to use a separate "NAME BINDING" construct to >> specify contexts in which instances might show up, allowing >> instances to be put in places that weren't even imagined when >> the original class definition was written. Name bindings could >> be standardized, or be vendor or even product-specific, allowing >> the simplicity or complexity of a given system's instance tree >> to reflect the actual simplicity or complexity of that system, >> rather than requiring all systems to be structured for the >> worst case. > > How could this be expressed in YANG terms? (I tried to figure it out > myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT > Recommendation X.722). > This is exactly the (sub) model reuse issue I was getting at in http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html I think this new capability (i.e., the ability to define complex, augmentable and reusable structures that are "included" when defining more complex models) would be a good new issue to track. Lou From nobody Tue Sep 1 09:40:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FC21A9127 for ; Tue, 1 Sep 2015 09:40:34 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0UpwnvrxoJw for ; Tue, 1 Sep 2015 09:40:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51821B35B2 for ; Tue, 1 Sep 2015 09:40:29 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.256.15; Tue, 1 Sep 2015 16:40:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 16:40:25 +0000 From: Kent Watsen To: Lou Berger , Ladislav Lhotka , "Randy Presuhn" , "netmod@ietf.org" Thread-Topic: tracking new YANG language issues Thread-Index: AQHQ5NTnxqG7viswOUSrUALmFK8MJw== Date: Tue, 1 Sep 2015 16:40:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:RLhklHvdcB1WXuh296IcNE52AgPeaoPlHKgk5MuXMGCwl+BL8r2/PL9RzWxF4aXm9xXDt+f+C2DEWZnB8hlTaLLBButTCUV9/y1xebYerOm8UvSfFh1YELdE28CepJL0gMbgf6wSztj9pb3KOoQJdA==; 24:qfrcl7yojSu6Q+W0BcCSrMLfWom+eaTEUDKW31b8YE9/LF/lQ94gmj5HEFIs98WSA5ZYBS1co1YrgqWHw14h++e9MmofyBmH+lYOcVhsLGQ=; 20:g8zz57/TBgMP52QxhpUtX5R3hfsku0VX71eKfDXwJZxuDoGKfCjTZdRTckq0+exYYK0vcva/bOQJDKjluEzM+Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(31014005)(377454003)(189002)(479174004)(5004730100002)(62966003)(106116001)(40100003)(5001860100001)(54356999)(15975445007)(64706001)(101416001)(86362001)(5002640100001)(92566002)(83506001)(97736004)(68736005)(106356001)(122556002)(5007970100001)(19580395003)(66066001)(4001350100001)(2656002)(46102003)(4001540100001)(36756003)(107886002)(50986999)(81156007)(2501003)(77156002)(102836002)(105586002)(2900100001)(10400500002)(99286002)(229853001)(5001830100001)(19580405001)(189998001)(87936001)(5001920100001)(5001770100001)(5001960100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <7297D514FFEA84409E7E7834B98A4F90@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 16:40:25.5937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:40:34 -0000 [chair hat on, changed subject line] On 9/1/15, 11:05 AM, "Lou Berger" wrote: >This is exactly the (sub) model reuse issue I was getting at in >http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html > >I think this new capability (i.e., the ability to define complex, >augmentable and reusable structures that are "included" when defining >more complex models) would be a good new issue to track. > >Lou Yes, we need to start tracking new YANG language issues like this one. How/where is the question... First off, anything that can be implemented using a YANG language extension should be submitted as a draft and released that way. Everything else is essentially destined for a 6020bis-bis - agreed? The big question, which may not even have to be answered immediately, is if 6020bis-bis is YANG 1.2 or a 2.0. That is, will we confine ourselves to backwards compatibility or not. Personally, since I don't have a sense for how much 2.0 there might be, I think it would be interesting just to collect the YANG 2.0 ideas now. It would be good to see what all else is out there besides the I2RS and OpenConfig stuff we already know about. Thoughts? - how should we proceed? - use GitHub issue tracker? Kent From nobody Tue Sep 1 09:47:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B461B4535 for ; Tue, 1 Sep 2015 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGbUSuBPF5UU for ; Tue, 1 Sep 2015 09:47:21 -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 ECEEB1B51CF for ; Tue, 1 Sep 2015 09:47:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A7BA310DA; Tue, 1 Sep 2015 18:47:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cCFuNQzLvrHA; Tue, 1 Sep 2015 18:47:18 +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, 1 Sep 2015 18:47:18 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97C892004E; Tue, 1 Sep 2015 18:47:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wMtpxr2RU67t; Tue, 1 Sep 2015 18:47:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C854B20048; Tue, 1 Sep 2015 18:47:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E6A136F3554; Tue, 1 Sep 2015 18:47:11 +0200 (CEST) Date: Tue, 1 Sep 2015 18:47:11 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150901164711.GA25138@elstar.local> Mail-Followup-To: Kent Watsen , Lou Berger , Ladislav Lhotka , Randy Presuhn , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:47:22 -0000 On Tue, Sep 01, 2015 at 04:40:25PM +0000, Kent Watsen wrote: > [chair hat on, changed subject line] > > > > On 9/1/15, 11:05 AM, "Lou Berger" wrote: > > >This is exactly the (sub) model reuse issue I was getting at in > >http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html > > > >I think this new capability (i.e., the ability to define complex, > >augmentable and reusable structures that are "included" when defining > >more complex models) would be a good new issue to track. > > > >Lou > > > Yes, we need to start tracking new YANG language issues like this one. > How/where is the question... > > First off, anything that can be implemented using a YANG language > extension should be submitted as a draft and released that way. > Everything else is essentially destined for a 6020bis-bis - agreed? > I suggest people write I-Ds if they have any far reaching ideas. At this point in time, I think the WG needs to focus on wrapping up YANG 1.1. There are several other chartered work items this WG has signed up for. While it is nice to constantly throw in new ideas, I strongly advice everybody to focus on finishing existing chartered work. /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 Sep 1 09:59:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BB31B3F92 for ; Tue, 1 Sep 2015 09:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR2txXogK44x for ; Tue, 1 Sep 2015 09:59:30 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450: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 EB9AF1B549B for ; Tue, 1 Sep 2015 09:59:06 -0700 (PDT) Received: by wibz8 with SMTP id z8so39221754wib.1 for ; Tue, 01 Sep 2015 09:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eUmQE8GPYPDzvhgJk3qNtVxNqushHybLb6kmxiJzJZw=; b=j10wWHiypXPM/S61TxcDmpl4RIdYOnqNlUrxLIYxyvyvO52ypbm/ScdEUJBfCuovGg zFZ99ZsWDvH/nODH+GrygQaMtB++U/I+K0y4eamxaC3fibJWtpbRuH+YHwpFrEYmdbir V1mjXAQS8WdIk7mWBs2Ef2Hzu86W3Po4u/kfsNDvWZUDrsmBcx5/Y5qZ0oV0wYRNx9G0 Flo6V1HQ3wmYzsTwRPIPJQWGI9YEfrc2jB+vnohHCGoiuN+auxw+raer3ufnbhXXOUYK 790jCgzYLGmlOCHgJw8SNKCFrrY3NjB6IrnmWGEicmpXsL11Mys+PLi/7UDsoQ2H1mO8 j+qg== X-Received: by 10.194.174.133 with SMTP id bs5mr16418587wjc.156.1441126745555; Tue, 01 Sep 2015 09:59:05 -0700 (PDT) Received: from ams-giheron-8915.cisco.com ([173.38.220.57]) by smtp.gmail.com with ESMTPSA id hr17sm3623808wib.16.2015.09.01.09.59.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Sep 2015 09:59:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Giles Heron In-Reply-To: <20150901164711.GA25138@elstar.local> Date: Tue, 1 Sep 2015 17:58:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150901164711.GA25138@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:59:32 -0000 On 1 Sep 2015, at 17:47, Juergen Schoenwaelder = wrote: >=20 > On Tue, Sep 01, 2015 at 04:40:25PM +0000, Kent Watsen wrote: >> [chair hat on, changed subject line] >>=20 >>=20 >>=20 >> On 9/1/15, 11:05 AM, "Lou Berger" wrote: >>=20 >>> This is exactly the (sub) model reuse issue I was getting at in >>> http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html >>>=20 >>> I think this new capability (i.e., the ability to define complex, >>> augmentable and reusable structures that are "included" when = defining >>> more complex models) would be a good new issue to track. >>>=20 >>> Lou >>=20 >>=20 >> Yes, we need to start tracking new YANG language issues like this = one. >> How/where is the question... >>=20 >> First off, anything that can be implemented using a YANG language >> extension should be submitted as a draft and released that way. >> Everything else is essentially destined for a 6020bis-bis - agreed? >>=20 >=20 > I suggest people write I-Ds if they have any far reaching ideas. I think GitHub would be better. The overhead is much lower than writing = a draft. > At this point in time, I think the WG needs to focus on wrapping up > YANG 1.1. There are several other chartered work items this WG has > signed up for. While it is nice to constantly throw in new ideas, I > strongly advice everybody to focus on finishing existing chartered > work. agreed. Giles > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Sep 1 10:31:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81A1B634B for ; Tue, 1 Sep 2015 10:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSazNtxo7tze for ; Tue, 1 Sep 2015 10:31:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214D91B62F0 for ; Tue, 1 Sep 2015 10:31:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E05681938; Tue, 1 Sep 2015 19:31:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ifKq11eKREsG; Tue, 1 Sep 2015 19:31:00 +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, 1 Sep 2015 19:31:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FAD820053; Tue, 1 Sep 2015 19:31:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G8cF-XYh9R70; Tue, 1 Sep 2015 19:30:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A54920048; Tue, 1 Sep 2015 19:30:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E5D536F35D1; Tue, 1 Sep 2015 19:30:55 +0200 (CEST) Date: Tue, 1 Sep 2015 19:30:55 +0200 From: Juergen Schoenwaelder To: Giles Heron Message-ID: <20150901173054.GA25214@elstar.local> Mail-Followup-To: Giles Heron , Kent Watsen , Randy Presuhn , "netmod@ietf.org" References: <20150901164711.GA25138@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:31:05 -0000 On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote: > On 1 Sep 2015, at 17:47, Juergen Schoenwaelder wrote: > > > > I suggest people write I-Ds if they have any far reaching ideas. > > I think GitHub would be better. The overhead is much lower than writing a draft. > IETF processes usually starts with ideas presented in I-Ds. I do not care much which tools people use to produce I-Ds. /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 Sep 1 10:46:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF91B544A for ; Tue, 1 Sep 2015 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwLuCMZQiwyY for ; Tue, 1 Sep 2015 10:45:59 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450: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 293681B54A7 for ; Tue, 1 Sep 2015 10:45:59 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so20661439wic.0 for ; Tue, 01 Sep 2015 10:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0An5frUTOEaXi8y4OQRYwbol6DoiIU2fvDnSk1zTYas=; b=Rdxr/fWwpQkorAQxgbgu0aj7huFtcsgc9JHUKU1BYS8rd/Js6eXIxOyQMHYbgYg7hz bS/Dia2+4AYoFMWuEXgy4KY+e3OcLiaJcCH55NPQ4SWjNbfOPke3KBx+Q5H9zV7WM8A0 PRxJwUw26Wlq6UlenyxspOJwQnvcYmfX6a8qWwW60b5/4WQV1sM5foNgCiyT5+qT1Kl9 mRX+fwtdR9FqwLvGbfeFY8AqaI9Iv7PgFShjxI8h3dWaRhR5C+vA3Mh9MrGSzALhmJoZ 2Cr4pb716BpykKA/xFdD2uxyU2eMYWvJF6InBR9AUoU+9DCQTXC++sdd+CPIJ2PRFzM4 /yGQ== X-Received: by 10.194.84.211 with SMTP id b19mr37994740wjz.120.1441129557774; Tue, 01 Sep 2015 10:45:57 -0700 (PDT) Received: from ams-giheron-8915.cisco.com ([173.38.220.57]) by smtp.gmail.com with ESMTPSA id lq9sm28277313wjb.35.2015.09.01.10.45.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Sep 2015 10:45:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Giles Heron In-Reply-To: <20150901173054.GA25214@elstar.local> Date: Tue, 1 Sep 2015 18:45:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150901164711.GA25138@elstar.local> <20150901173054.GA25214@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:46:01 -0000 On 1 Sep 2015, at 18:30, Juergen Schoenwaelder = wrote: >=20 > On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote: >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder = wrote: >>>=20 >>> I suggest people write I-Ds if they have any far reaching ideas. >>=20 >> I think GitHub would be better. The overhead is much lower than = writing a draft. >>=20 >=20 > IETF processes usually starts with ideas presented in I-Ds. I do not > care much which tools people use to produce I-Ds. sure, that is the process in general. But I=E2=80=99m unconvinced that = it=E2=80=99s the right way to proceed with YANG. E.g. we used a = numbered of issues for YANG 1.1. So why not a numbered list of = suggestions for YANG 2.0? Giles > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Sep 1 10:58:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E58A1B4D37 for ; Tue, 1 Sep 2015 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B99mkAUq7WQc for ; Tue, 1 Sep 2015 10:58:32 -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 117171B5295 for ; Tue, 1 Sep 2015 10:58:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D1FE9151A; Tue, 1 Sep 2015 19:58:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id w145d3wW-jfO; Tue, 1 Sep 2015 19:58:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Sep 2015 19:58:29 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD4592004E; Tue, 1 Sep 2015 19:58:29 +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 Mf5X1vZGJXp8; Tue, 1 Sep 2015 19:58:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0972720048; Tue, 1 Sep 2015 19:58:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5EC436F36BE; Tue, 1 Sep 2015 19:58:24 +0200 (CEST) Date: Tue, 1 Sep 2015 19:58:24 +0200 From: Juergen Schoenwaelder To: Giles Heron Message-ID: <20150901175824.GA25324@elstar.local> Mail-Followup-To: Giles Heron , Kent Watsen , Randy Presuhn , "netmod@ietf.org" References: <20150901164711.GA25138@elstar.local> <20150901173054.GA25214@elstar.local> 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.4.2.3i Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:58:34 -0000 On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote: > On 1 Sep 2015, at 18:30, Juergen Schoenwaelder wrote: > > > > On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote: > >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder wrote: > >>> > >>> I suggest people write I-Ds if they have any far reaching ideas. > >> > >> I think GitHub would be better. The overhead is much lower than writing a draft. > >> > > > > IETF processes usually starts with ideas presented in I-Ds. I do not > > care much which tools people use to produce I-Ds. > > sure, that is the process in general. But I’m unconvinced that it’s the right way to proceed with YANG. E.g. we used a numbered of issues for YANG 1.1. So why not a numbered list of suggestions for YANG 2.0? > The formal answer is that the WG is charted to do YANG 1.1 and not 2.0. The other answer is that (a) collecting issues is easy, (b) finding agreement on issues is difficult, (c) getting the final text written and _all the details that pop up worked out_ is very hard work. Unfortunately, you see many people working on (a), less people on (b) and finally very few doing (c). /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 Sep 1 13:52:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3141B3114 for ; Tue, 1 Sep 2015 13:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM364s74y3Ze for ; Tue, 1 Sep 2015 13:52:50 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9D71B3F33 for ; Tue, 1 Sep 2015 13:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1441140769; x=1442350369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WxzOkTP5q+rLwXz1I7J3W1pj4tP95FPcdkTrPKoY1SU=; b=gUsb0cDFiazYlt+4mH1FWN0Kwz6gvIr4Y4Cm8dxPJvOZTL0H5YL1UCvf NFc6A0bsFhgK81ULwyvyU9HIZTAQHtnpwUkgM9oQeALSnskHYD9501hGj qnM3ZpIWKh4Ak84HUcvZ2ynnvYFf3budzxQLKhHpmoMNh5V+w5u42tGNd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARAwAZD+ZV/5tdJa1aA4MbVGkGgx27DAEJgW0KhTFKAhyBKzgUAQEBAQEBAYEKhCMBAQEEAQEBIBE6CwwCAgIBCA4CAQQBAQECAgYdAwICAhkGBgsUAQgIAgQBDQUIiBEDEg20eo9oDYUHAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSBHopOgk+CCxYLEAcGDIJXL4EUBZVBAYsHlR2HPCaDf3GBSIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,450,1437436800"; d="scan'208";a="23541745" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 01 Sep 2015 20:52:49 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t81Kqnhc029791 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 20:52:49 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.1104.5; Tue, 1 Sep 2015 15:52:47 -0500 Received: from xhc-rcd-x05.cisco.com (173.37.183.79) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 1 Sep 2015 15:52:47 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0248.002; Tue, 1 Sep 2015 15:52:48 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , Giles Heron Thread-Topic: [netmod] tracking new YANG language issues Thread-Index: AQHQ5NTnxqG7viswOUSrUALmFK8MJ54oNdmAgAADTICAAAjsgIAABDGAgAADfQD//9lP0A== Date: Tue, 1 Sep 2015 20:52:47 +0000 Message-ID: References: <20150901164711.GA25138@elstar.local> <20150901173054.GA25214@elstar.local> <20150901175824.GA25324@elstar.local> In-Reply-To: <20150901175824.GA25324@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 20:52:51 -0000 RldJVywgSSBwcmVmZXIgSS1EIGFzIHdlbGwuICBUaGlzIGlzIGEgdmVyeSB3ZWxsIGVzdGFibGlz aGVkIGFuZCB2ZXJ5IHdlbGwgdW5kZXJzdG9vZCBwcm9jZXNzLiAgT25lIGFkdmFudGFnZSBpcyB0 aGF0IHRoaW5ncyBhcmUgdmVyeSBlYXN5IHRvIGZpbmQgKGZyb20gdGhlIGRvY3VtZW50cyBwYWdl KS4gIFJlZ2FyZGxlc3Mgd2hpY2ggd2F5IGlzIGNob3NlbiwgaGF2aW5nIHRoZSBJRVRGIGRhdGF0 cmFja2VyIHBhZ2UgYXMgYW4gZW50cnkgcG9pbnQgZnJvbSB3aGVyZSB0byBmaW5kIHN0dWZmIGlz IElNSE8gYSBtdXN0Lg0KLS0tIEFsZXgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SnVlcmdlbiBTY2hvZW53YWVsZGVyDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTUg MTA6NTggQU0NClRvOiBHaWxlcyBIZXJvbiA8Z2lsZXMuaGVyb25AZ21haWwuY29tPg0KQ2M6IFJh bmR5IFByZXN1aG4gPHJhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb20+OyBuZXRtb2RAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSB0cmFja2luZyBuZXcgWUFORyBsYW5ndWFnZSBpc3N1 ZXMNCg0KT24gVHVlLCBTZXAgMDEsIDIwMTUgYXQgMDY6NDU6NTVQTSArMDEwMCwgR2lsZXMgSGVy b24gd3JvdGU6DQo+IE9uIDEgU2VwIDIwMTUsIGF0IDE4OjMwLCBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4gDQo+ ID4gT24gVHVlLCBTZXAgMDEsIDIwMTUgYXQgMDU6NTg6NTlQTSArMDEwMCwgR2lsZXMgSGVyb24g d3JvdGU6DQo+ID4+IE9uIDEgU2VwIDIwMTUsIGF0IDE3OjQ3LCBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+PiAN Cj4gPj4+IEkgc3VnZ2VzdCBwZW9wbGUgd3JpdGUgSS1EcyBpZiB0aGV5IGhhdmUgYW55IGZhciBy ZWFjaGluZyBpZGVhcy4NCj4gPj4gDQo+ID4+IEkgdGhpbmsgR2l0SHViIHdvdWxkIGJlIGJldHRl ci4gIFRoZSBvdmVyaGVhZCBpcyBtdWNoIGxvd2VyIHRoYW4gd3JpdGluZyBhIGRyYWZ0Lg0KPiA+ PiANCj4gPiANCj4gPiBJRVRGIHByb2Nlc3NlcyB1c3VhbGx5IHN0YXJ0cyB3aXRoIGlkZWFzIHBy ZXNlbnRlZCBpbiBJLURzLiBJIGRvIG5vdCANCj4gPiBjYXJlIG11Y2ggd2hpY2ggdG9vbHMgcGVv cGxlIHVzZSB0byBwcm9kdWNlIEktRHMuDQo+IA0KPiBzdXJlLCB0aGF0IGlzIHRoZSBwcm9jZXNz IGluIGdlbmVyYWwuICBCdXQgSeKAmW0gdW5jb252aW5jZWQgdGhhdCBpdOKAmXMgdGhlIHJpZ2h0 IHdheSB0byBwcm9jZWVkIHdpdGggWUFORy4gIEUuZy4gd2UgdXNlZCBhIG51bWJlcmVkIG9mIGlz c3VlcyBmb3IgWUFORyAxLjEuICBTbyB3aHkgbm90IGEgbnVtYmVyZWQgbGlzdCBvZiBzdWdnZXN0 aW9ucyBmb3IgWUFORyAyLjA/DQo+DQoNClRoZSBmb3JtYWwgYW5zd2VyIGlzIHRoYXQgdGhlIFdH IGlzIGNoYXJ0ZWQgdG8gZG8gWUFORyAxLjEgYW5kIG5vdCAyLjAuIFRoZSBvdGhlciBhbnN3ZXIg aXMgdGhhdCAoYSkgY29sbGVjdGluZyBpc3N1ZXMgaXMgZWFzeSwgKGIpIGZpbmRpbmcgYWdyZWVt ZW50IG9uIGlzc3VlcyBpcyBkaWZmaWN1bHQsIChjKSBnZXR0aW5nIHRoZSBmaW5hbCB0ZXh0IHdy aXR0ZW4gYW5kIF9hbGwgdGhlIGRldGFpbHMgdGhhdCBwb3AgdXAgd29ya2VkIG91dF8gaXMgdmVy eSBoYXJkIHdvcmsuIFVuZm9ydHVuYXRlbHksIHlvdSBzZWUgbWFueSBwZW9wbGUgd29ya2luZyBv biAoYSksIGxlc3MgcGVvcGxlIG9uIChiKSBhbmQgZmluYWxseSB2ZXJ5IGZldyBkb2luZyAoYyku DQoNCi9qcw0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5n IGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg== From nobody Tue Sep 1 13:55:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D68B1B4555 for ; Tue, 1 Sep 2015 13:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvNHxQKfN5Fj for ; Tue, 1 Sep 2015 13:55:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 704691B454A for ; Tue, 1 Sep 2015 13:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441140838; bh=xXbaRgRFuh+jO874jhzXBqdO1yqmFgqiMaiCkJAr7pc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EKoc4VUO6oBdxHXMA4GF5RTXYBfv27ze/2tjVlv4zL/1HddgW6bJIYPNJFJqn4XhJ nd6fFNtnZ+AL8gDd73C7PftQbA6ABV7I3D6obLgwt6J/h4jXuI+kIt4OlOHwfUNOq5 vJ+n/DBox20e+3TF4kLRSgZZA5NY+qdyP5WKN3LE= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <20150901175824.GA25324@elstar.local> Date: Tue, 1 Sep 2015 16:55:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <19D2D252-4FAC-437F-8248-4CBCD44398C4@lucidvision.com> References: <20150901164711.GA25138@elstar.local> <20150901173054.GA25214@elstar.local> <20150901175824.GA25324@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=30 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 109, in=1440, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 20:55:08 -0000 > On Sep 1, 2015:1:58 PM, at 1:58 PM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote: >> On 1 Sep 2015, at 18:30, Juergen Schoenwaelder = wrote: >>>=20 >>> On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote: >>>> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>> I suggest people write I-Ds if they have any far reaching ideas. >>>>=20 >>>> I think GitHub would be better. The overhead is much lower than = writing a draft. >>>>=20 >>>=20 >>> IETF processes usually starts with ideas presented in I-Ds. I do not >>> care much which tools people use to produce I-Ds. >>=20 >> sure, that is the process in general. But I=E2=80=99m unconvinced = that it=E2=80=99s the right way to proceed with YANG. E.g. we used a = numbered of issues for YANG 1.1. So why not a numbered list of = suggestions for YANG 2.0? >>=20 >=20 > The formal answer is that the WG is charted to do YANG 1.1 and not > 2.0. The other answer is that (a) collecting issues is easy, (b) > finding agreement on issues is difficult, (c) getting the final text > written and _all the details that pop up worked out_ is very hard > work. Unfortunately, you see many people working on (a), less people > on (b) and finally very few doing (c). >=20 > /js Juergen is technically correct, although conversations with the = AD have started about adjusting our charter to facilitate a 2.0 rev of = Yang. If you have input/opinions around whether or not we should embark on this, I suggest sending a note to Benoit. I am also collecting issues to publish into a draft, that will = document these problems right now.=20 If anyone has issues they wish to document and want to contribute, = please contact me offline.=20 =E2=80=94Tom >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Sep 1 14:21:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0101B31A1 for ; Tue, 1 Sep 2015 14:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKPPzxL_a_jI for ; Tue, 1 Sep 2015 14:21:33 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7C91B3767 for ; Tue, 1 Sep 2015 14:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5186; q=dns/txt; s=iport; t=1441142494; x=1442352094; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/Ll4MWErUrdPFYbDnZvR7sVBK8ZXsRKuV6NUVt+f+Kg=; b=OpzeDJJp7JIw9HpJQ6UIIo9k7IuuzItHgNqWn91xmJxVJYvMU51bkatF sMgW+6kWGudCF1ovMOr8Si4ahfCTcemfXy7g0kz30hM1ojt6OUfnQ7oDJ JRfW9WhPWEa4pxWemdSXZLJb2NByATotMnKP2MaPYmvHMlkOjG6QzFc/O 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CRAgBTFuZV/5tdJa1dgxtUaQa3YIZJAQmBbQqFMUoCgUc4FAEBAQEBAQGBCoQjAQEBBAEBATc0BBMEAgEIEQQBAQsUCQcnCxQJCAIEARIIiCYNyWoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItwhFo4BoMSgRQFjG4BiFIBhiuIE4dRkVEmgg8cgVRxgUiBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,450,1437436800"; d="scan'208";a="184105761" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 01 Sep 2015 21:21:11 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t81LLAIX016392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 21:21:10 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Sep 2015 16:21:09 -0500 Received: from xhc-rcd-x07.cisco.com (173.37.183.81) by xch-aln-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 1 Sep 2015 16:21:09 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0248.002; Tue, 1 Sep 2015 16:21:09 -0500 From: "Alexander Clemm (alex)" To: Randy Presuhn , "netmod@ietf.org" Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ5COlTzsSGcsnXUGEg7nqAdBBep4oKvQQ Date: Tue, 1 Sep 2015 21:21:09 +0000 Message-ID: References: <18043244.1441049496150.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> In-Reply-To: <18043244.1441049496150.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 21:21:35 -0000 Hi Randy, GDMO had some very powerful concepts. The ability to separate definition h= ierarchy and containment hierarchy is indeed very powerful. In many ways, = it was ahead of its time. The problem I see is that in the context of YANG= (much simpler), I don't think the same concept of name bindings is applica= ble, really. The difference is that in GDMO, MOC definitions did not make = any statement about naming/ containment - this made it possible to separate= containment out from other aspects of the model, cleanly, as they were ort= hogonal concepts. In YANG, however, the definition of the containment stru= cture is very much at the core of what is being defined as part of the mode= l. This is in part what makes it simple (and IMHO arguably also easier to = read and consume - name bindings were arguably "harder to follow"), but the= re are some limitations that we are starting to bump into. I think it is p= ossible to address these (allowing the definition of mount points is one pr= oposal), but the mechanism will need to be different from name bindings sim= ply because the MOCs being linked are not defined "on their own", but as pa= rt of containment relationships intrinsically tied to their definitions. = =20 --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Monday, August 31, 2015 12:32 PM To: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models Hi - >From: Ladislav Lhotka >Sent: Aug 31, 2015 8:04 AM >To: Randy Presuhn , netmod@ietf.org >Subject: Re: [netmod] Motivations for Structuring Models ... >> What GDMO did was to use a separate "NAME BINDING" construct to=20 >> specify contexts in which instances might show up, allowing instances=20 >> to be put in places that weren't even imagined when the original=20 >> class definition was written. Name bindings could be standardized,=20 >> or be vendor or even product-specific, allowing the simplicity or=20 >> complexity of a given system's instance tree to reflect the actual=20 >> simplicity or complexity of that system, rather than requiring all=20 >> systems to be structured for the worst case. > >How could this be expressed in YANG terms? (I tried to figure it out=20 >myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT=20 >Recommendation X.722). A key concept of naming in that universe is "containment". As with X.500 Directory or modern file systems, object instances are identi= fied by their "distinguishing attribute(s)" within the context of a contain= ing object. The containment hierarchy within a given system generally refl= ects physical or logical containment. Perhaps an example of how it could be used would help. Suppose I've defined a "cpu" class and a "motherboard" class. Further suppose that the "cpu" class has an attribute called "processorId" = which is guaranteed to be unique within any naming context in which one mig= ht find more than one processor as immediate siblings. To say that a cpu co= uld be identified (named) within the context of a motherboard, one could say something like cpuOfMotherboard NAME BINDING SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS motherboard AND SUBCLASSES; WITH ATTRIBUTE processorId; REGISTERED AS blah ; This says that if one has located an instance of the motherboard class or a= ny of its subclasses, instances of the cpu class that are immediately conta= ined by it could be named within that context by their "processorId" attrib= ute. (A meta-model requirement is that any instantiable object class needs= to have at least one attribute suitable for use in naming.) Later, say we find that we need to model line cards with cpus, and those li= ne cards (for whatever reason) are not derived from the motherboard class. = But we can still use the cpu class to manage those processors by adding an= other name binding: cpuOfLinecard NAME BINDING SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS lineCard AND SUBCLASSES; WITH ATTRIBUTE processorId; REGISTERED AS blahblah ; The point is that the class definition does not by itself determine where o= bject instances might appear in a managed system; the supported name bindin= gs determine where instances can be, whether (and how) they are created, an= d whether (and how) they can be deleted. Is that a bit clearer? No tidy way to do all of this in Yang-land is appar= ent to me - the (meta-) modeling assumptions seem too far removed, particul= arly with regard to inheritance and containment - but someone more creative= than me might figure out how to do it. But the point is not to ape GDMO. = The point is that this capability was included in that world to address re= al-world modeling needs, and we're seeing those same needs resurfacing here= . Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Sep 1 16:52:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6078D1B3E9C for ; Tue, 1 Sep 2015 16:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlU3u_utjCpM for ; Tue, 1 Sep 2015 16:52:05 -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 87EBE1B3FBF for ; Tue, 1 Sep 2015 16:51:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 068D01324; Wed, 2 Sep 2015 01:51:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RCrxZ3T8N7Jq; Wed, 2 Sep 2015 01:51:38 +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, 2 Sep 2015 01:51:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6BBC2004E; Wed, 2 Sep 2015 01:51:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v3PLbkZ_t2xM; Wed, 2 Sep 2015 01:51:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6317520048; Wed, 2 Sep 2015 01:51:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 473FF36F3BD6; Wed, 2 Sep 2015 01:51:32 +0200 (CEST) Date: Wed, 2 Sep 2015 01:51:31 +0200 From: Juergen Schoenwaelder To: Nadeau Thomas Message-ID: <20150901235131.GA26069@elstar.local> Mail-Followup-To: Nadeau Thomas , "netmod@ietf.org" References: <20150901164711.GA25138@elstar.local> <20150901173054.GA25214@elstar.local> <20150901175824.GA25324@elstar.local> <19D2D252-4FAC-437F-8248-4CBCD44398C4@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19D2D252-4FAC-437F-8248-4CBCD44398C4@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] tracking new YANG language issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 23:52:07 -0000 On Tue, Sep 01, 2015 at 04:55:03PM -0400, Nadeau Thomas wrote: > > Juergen is technically correct, although conversations with the AD > have started about adjusting our charter to facilitate a 2.0 rev of > Yang. If you have input/opinions around whether or not we should > embark on this, I suggest sending a note to Benoit. Sorry, any such debate belongs into the WG first. I do not recall having seen a WG charter to put up a revision of something on the charter where the current revision of the same thing is not even complete. The process you run is really backwards. The process usually is roughly this: - some people publish individual I-Ds - the WG discusses these individual I-Ds - the WG forms and opinion whether the work should be taken on - if the work does not fit the current charter, the WG consults with the AD concerning a charter revision Tom, it seems you are mostly running this backwards if you start with a private charter revision discussion with the respective AD. /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 Sep 1 17:01:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2F21B5278 for ; Tue, 1 Sep 2015 17:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F299JQnpW74c for ; Tue, 1 Sep 2015 17:01:14 -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 1AF381B5275 for ; Tue, 1 Sep 2015 17:01:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CE899133B for ; Wed, 2 Sep 2015 02:01:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dEE8aTUkVl3S for ; Wed, 2 Sep 2015 02:01:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 2 Sep 2015 02:01:10 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6943E20048 for ; Wed, 2 Sep 2015 02:01:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dWi5PruWc3ZI; Wed, 2 Sep 2015 02:01:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C97F52004E; Wed, 2 Sep 2015 02:01:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A47DB36F3C25; Wed, 2 Sep 2015 02:01:04 +0200 (CEST) Date: Wed, 2 Sep 2015 02:01:04 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150902000104.GB26069@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 00:01:16 -0000 I like the idea to step back and I actually only now found the time to read this thread, from its very start all the way to GDMO. (This is how my email client mutt sorted the thread for me. ;-) I agree that we do have a big big data model coordination challenge in the IETF (and soon beyond as other SDOs start to extend IETF models). The sad truth is that addressing the challenge requires say 85% human brains (good early reviews paired with followup communication plus and some oversight and steering) and perhaps 10% better tools and likely only 5% conventions (if at all). This being the IETF, we seem to focus on the 10% and the 5% of the challenge first (probably because we know how hard it is to allocate the human resources needed to work on the 85% of the challenge). Things get somewhat interesting if well intended attempts to address the 2% of the challenge end up destabilizing data models that were written to form basic building blocks and that we have published (through a consensus process) and that have been implemented and deployed and that were also designed to provide a basis for other SDOs to extend them (I am talking about ietf-interfaces, obviously). Concerning the openconfig proposal that started this debate, I fail to see how good model design becomes significantly easier by having a rigid fixed plan where the models are to be rooted. Writing good extensible models is hard, and it will always be. A big part of the problem is (i) to identify a common model for a technology that can be implemented across multiple devices and (ii) to future prove the model such that extensions of the model can work easily (and predicting the future remains difficult for most of us). To me, it seems we have a software engineering challenge paired with the specifics of working in a volunteer organization that in addition has its own internal boundaries (called areas and working groups). We also witness the differences of opinion between people who believe small design teams for criticial pieces can help to solve the 85% challenge and people who believe more agile processes should be used (where you throw out rough ideas quickly and subsequently iteratively revise them to either become a good idea or to remove them if they did not fly). Unfortunately, the meta-debate between a more traditional approach and a more agile approach does not help with the 85% challenge, at least not in the near future. So in conclusion, I believe the key problem is a lack of skilled human resources that can help with the 85% of the challenge. So what can we do? Trying to increase the amount of skilled human resources involved in data model writing (training, mentoring, sharing of know-how - but this is a long-term process) and making sure that the skilled human resources we have stay productive by focusing work, by prioritizing work, and by maintaining a constructive atmosphere. Looking at the many things going on and the number of people deeply technically involved in those things, I am increasingly concerned that we loose focus and make no measurable progress on the things we want to achieve. /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 Sep 1 17:55:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0E11ACE3A for ; Tue, 1 Sep 2015 17:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGrfL1bk0x6S for ; Tue, 1 Sep 2015 17:54:57 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4F1ACDC8 for ; Tue, 1 Sep 2015 17:54:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L44XhLUg5vCbQuqao4/M3+dYeX2ZT31yC26A3God9ZAMRAfCpRkVkoi0lcJ280NZ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZWwK6-0000kf-PD for netmod@ietf.org; Tue, 01 Sep 2015 20:54:46 -0400 Received: from 99.101.141.2 by webmail.earthlink.net with HTTP; Tue, 1 Sep 2015 20:54:46 -0400 Message-ID: <11730207.1441155286776.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Tue, 1 Sep 2015 20:54:46 -0400 (EDT) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed5c5023cf89604565b5964d5058e0123d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 00:54:59 -0000 Hi - >From: "Alexander Clemm (alex)" >Sent: Sep 1, 2015 2:21 PM >To: Randy Presuhn , "netmod@ietf.org" >Subject: RE: [netmod] Motivations for Structuring Models > >Hi Randy, > >GDMO had some very powerful concepts. The ability to separate >definition hierarchy and containment hierarchy is indeed very >powerful. In many ways, it was ahead of its time. The problem >I see is that in the context of YANG (much simpler), I don't >think the same concept of name bindings is applicable, really. Agreed. At best it would probably be an ugly bolt-on; some of the concerns it is intended to address are ones that folks in the Netconf universe have tended to declare out-of-scope, though as more people use these tools we'll probably encounter more calls to revisit those long-held assumptions. > The difference is that in GDMO, MOC definitions did not make > any statement about naming/ containment - this made it possible > to separate containment out from other aspects of the model, > cleanly, as they were orthogonal concepts. In YANG, however, > the definition of the containment structure is very much at > the core of what is being defined as part of the model. That's a polite way of saying the difficulty is architectural, and *completely* fixing it would likely be disruptive. I think you're right. > This is in part what makes it simple (and IMHO arguably > also easier to read and consume - name bindings were arguably > "harder to follow"), but there are some limitations that we > are starting to bump into. They're essentially the same problems as arise with naming in SNMP-land, with the same causes and consequences. > I think it is possible to address these (allowing the > definition of mount points is one proposal), but the > mechanism will need to be different from name bindings > simply because the MOCs being linked are not defined "on > their own", but as part of containment relationships > intrinsically tied to their definitions. I agree a mechanism to accomplish something like it will likely be quite different. Name bindings rely on a particular characteristics of the metamodel and have specific consequences for the management protocol, and both sets of assumptions don't hold true in netconf/yang-land. Trying to ape GDMO does not seem like a productive route to me, given where Yang already finds itself. As long as naming is so closely bound to the definition, however, use of the models is constrained in unhelpful ways. Using mount points, at least as they've been formulated so far, only addresses parts of the problem. Whether that's going to be good enough remains to be seen. Without mount points or something similar, what we currently have is only about as broken as SNMP/SMI, and the industry got a lot of mileage out of that. I suspect the debate over mount points will be the beginning of netconf's counterpart to the "subagent wars" where the issue was not so much one of "can this be made to work with(out) this technology increment" than one of "what is the impact of this technology increment on our overall development/deployment/operational cost". Randy From nobody Wed Sep 2 03:43:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027E61A0030 for ; Wed, 2 Sep 2015 03:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMwUqXWU_lqL for ; Wed, 2 Sep 2015 03:42:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1F1A001B for ; Wed, 2 Sep 2015 03:42:57 -0700 (PDT) Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 5839F1AE0498; Wed, 2 Sep 2015 12:42:55 +0200 (CEST) Date: Wed, 02 Sep 2015 12:42:54 +0200 (CEST) Message-Id: <20150902.124254.850446502172825615.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 10:42:59 -0000 Andy Bierman wrote: > On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: > > Can one of you give an example of how this word work for a device (which > > may be physical or virtual) that allocates done resources, say interfaces > > to one logical entity (router, system, etc) and other resources to a second > > entity? And of course I want to manage all with yang and the first and > > second (sub) entity must be completely independent and ignorant of each > > other. [...] > The logical system knows only about itself: > > /interfaces > /system This is important. > The / node is represented by or or in the protocol. > > > > > > > > > > Each logical system can have its own "eth0" interface or whatever. > They are mapped to real interfaces in the physical system. > > All operations on the logical system are validated against its own > virtual datastore. YANG validation does not work on individual array > slices -- it only applies to an entire datastore. Yes. > On the physical server there needs to be a data model to manage the > logical servers (as Martin suggested). > > <--- root on PHY server > <--------------- contains the real interfaces, > including eth23 > > > vs1 > > eth23 > eth0 > > > <----------- YANG mount point (virtual > server root) > > > eth0 > ... > > > > > > > I like this, but I would actually not use mount here. I don't think it is necessary. This would be a model for devices that support multiple 'virtual-servers' / 'logical-network-elements'. So in this model you configure these logical-network-elements and allocate resources like interfaces etc to them. For true virtual servers, you'd also configure the NETCONF server and authentication params, meaning that each such virtual server has its own config, which is completely separate from the others. In this architecture, it would not be correct to mount all the models in the virtual server list. /martin From nobody Wed Sep 2 06:17:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022211B331D for ; Wed, 2 Sep 2015 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYRFz-QdJp4n for ; Wed, 2 Sep 2015 06:17:28 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 80B1C1B3265 for ; Wed, 2 Sep 2015 06:17:28 -0700 (PDT) Received: (qmail 5300 invoked by uid 0); 2 Sep 2015 13:17:26 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 2 Sep 2015 13:17:26 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id CDHD1r00i2SSUrH01DHGg7; Wed, 02 Sep 2015 07:17:23 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=xskcdSivAAAA:8 a=F3EUjgcWmFXdw__AOKAA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=DLUDCDM5XRBkWEh+ruiXgkc2uR5iVW2KmC3JLFRQz8o=; b=tz1JIbLtteeJ3EBOfjbXAKvYAJ0zJwkYahxkDdJsM/uPAtTu/CQW2QeNDqbHpbtPnJ3a2XzI+IJNExVsNqM+wHIE7cvYzwcsTVjErl9wVYIrY/ayh9ytmIytn/0Tq2dJ; Received: from box313.bluehost.com ([69.89.31.113]:35651 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZX7ud-0005uF-JA; Wed, 02 Sep 2015 07:17:15 -0600 To: Martin Bjorklund , andy@yumaworks.com References: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150902.124254.850446502172825615.mbj@tail-f.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55E6F6D8.1060405@labn.net> Date: Wed, 2 Sep 2015 09:17:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150902.124254.850446502172825615.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:17:30 -0000 Martin, On 09/02/2015 06:42 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: >>> Can one of you give an example of how this word work for a device (which >>> may be physical or virtual) that allocates done resources, say interfaces >>> to one logical entity (router, system, etc) and other resources to a second >>> entity? And of course I want to manage all with yang and the first and >>> second (sub) entity must be completely independent and ignorant of each >>> other. > > [...] > >> The logical system knows only about itself: >> >> /interfaces >> /system > > This is important. > >> The / node is represented by or or in the protocol. >> >> >> >> >> >> >> >> >> >> Each logical system can have its own "eth0" interface or whatever. >> They are mapped to real interfaces in the physical system. >> >> All operations on the logical system are validated against its own >> virtual datastore. YANG validation does not work on individual array >> slices -- it only applies to an entire datastore. > > Yes. > >> On the physical server there needs to be a data model to manage the >> logical servers (as Martin suggested). >> >> <--- root on PHY server >> <--------------- contains the real interfaces, >> including eth23 >> >> >> vs1 >> >> eth23 >> eth0 >> >> >> <----------- YANG mount point (virtual >> server root) >> >> >> eth0 >> ... >> >> >> >> >> >> >> > > I like this, but I would actually not use mount here. I don't think > it is necessary. This would be a model for devices that support > multiple 'virtual-servers' / 'logical-network-elements'. So in this > model you configure these logical-network-elements and allocate > resources like interfaces etc to them. For true virtual servers, > you'd also configure the NETCONF server and authentication params, > meaning that each such virtual server has its own config, which is > completely separate from the others. In this architecture, it would > not be correct to mount all the models in the virtual server list. > We discussed this in the DT and (I think) agreed there is room / need for both approaches based on device owner/client management model (i.e., is the device owner responsible for client config, device owner without client view.) Do you have a reference for a model that can be used to support this, or just thinking one is needed? Thanks, Lou > > /martin > From nobody Wed Sep 2 07:31:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1E71B2FDA for ; Wed, 2 Sep 2015 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kg5oLv9DdBc for ; Wed, 2 Sep 2015 07:31:03 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBF1B2C16 for ; Wed, 2 Sep 2015 07:31:03 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id AEC3D1CC036B for ; Wed, 2 Sep 2015 16:31:03 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 02 Sep 2015 16:31:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] data tree X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:31:05 -0000 Hi, one of the topics from the last virtual interim that needs further discussion is the ambiguity of the term "data tree". In 6020bis, it is used with three different meanings: 1. Explicit definition in Sec. 3: "The instantiated tree of configuration and state data on a device." 2. In many cases, it is used to denote *any* YANG-modelled tree, i.e. including RPC input/output data and notification. An example is the definition of container, also in Sec. 3: "An interior data node that exists in at most one instance in the data tree." 3. In a few other cases, it is used in a more restricted sense of a *configuration* data tree, for example in sec. 4.2.7: "When a node from one case is created in the data tree, all nodes from all other cases are implicitly deleted." In my review of 6020bis-06 I proposed to use "data tree" only in the meaning #2, that is: OLD o data tree: The instantiated tree of configuration and state data on a device. NEW o data tree: The instantiated tree of configuration, state data, combined configuration and state data, RPC input or output, or notification. We could use "configuration data tree" for #3, but a special term would probably also be needed for #1. Comments, suggestions? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 2 08:39:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6BF1B2ED8 for ; Wed, 2 Sep 2015 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-swvaiR9-hT for ; Wed, 2 Sep 2015 08:39:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 31C8B1B4A64 for ; Wed, 2 Sep 2015 08:38:35 -0700 (PDT) Received: by lbpo4 with SMTP id o4so8496517lbp.2 for ; Wed, 02 Sep 2015 08:38:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=igQ6RylnmpiReiQ9upIb81JEzQYoxKcLslPuGvMbL2E=; b=PWtxBP0+IHTvWONCipB07+tG40aIN/tP+xo1myTqkzIivd8tbG7aTkPlxvqqDxuOA8 rpC/K9FVbM0bk7sFoxx1aVf97c6OS12mTnGbjXhXTo87KWI0X6404yEbG7LAuuvKqU3E 252BpvwzqMpc0RNa9Sp9yKwgMrMf/wZL0hJXS5KKOEkdnEkf8ctyYOw8YYRZFyf4WZKz ZLvFxDeJw0C7In6E6C3QQfv65D15MPGHuF74kWvS1/bKyBUJVIc/5h89yfb4gL9oAK8f +Rc/GAY38ZTKro5doEs7XYuCqcCkhgSmZs1pUsF51vM6p9zkxFnPGeIzWBWkE+bqr0Wx PFQA== X-Gm-Message-State: ALoCoQlaS71XASts+yHbg64SLQCn2ITYUQZF05LFABx+L0fu6TYV+M052nBnO6eVrw6muvDn01oi MIME-Version: 1.0 X-Received: by 10.112.161.232 with SMTP id xv8mr16332448lbb.123.1441208313470; Wed, 02 Sep 2015 08:38:33 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 2 Sep 2015 08:38:33 -0700 (PDT) In-Reply-To: <55E6F6D8.1060405@labn.net> References: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net> Date: Wed, 2 Sep 2015 08:38:33 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c3c46c928263051ec575e3 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:39:22 -0000 --001a11c3c46c928263051ec575e3 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 2, 2015 at 6:17 AM, Lou Berger wrote: > Martin, > > On 09/02/2015 06:42 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: > >>> Can one of you give an example of how this word work for a device > (which > >>> may be physical or virtual) that allocates done resources, say > interfaces > >>> to one logical entity (router, system, etc) and other resources to a > second > >>> entity? And of course I want to manage all with yang and the first and > >>> second (sub) entity must be completely independent and ignorant of each > >>> other. > > > > [...] > > > >> The logical system knows only about itself: > >> > >> /interfaces > >> /system > > > > This is important. > > > >> The / node is represented by or or in the > protocol. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Each logical system can have its own "eth0" interface or whatever. > >> They are mapped to real interfaces in the physical system. > >> > >> All operations on the logical system are validated against its own > >> virtual datastore. YANG validation does not work on individual array > >> slices -- it only applies to an entire datastore. > > > > Yes. > > > >> On the physical server there needs to be a data model to manage the > >> logical servers (as Martin suggested). > >> > >> <--- root on PHY server > >> <--------------- contains the real interfaces, > >> including eth23 > >> > >> > >> vs1 > >> > >> eth23 > >> eth0 > >> > >> > >> <----------- YANG mount point (virtual > >> server root) > >> > >> > >> eth0 > >> ... > >> > >> > >> > >> > >> > >> > >> > > > > I like this, but I would actually not use mount here. I don't think > > it is necessary. This would be a model for devices that support > > multiple 'virtual-servers' / 'logical-network-elements'. So in this > > model you configure these logical-network-elements and allocate > > resources like interfaces etc to them. For true virtual servers, > > you'd also configure the NETCONF server and authentication params, > > meaning that each such virtual server has its own config, which is > > completely separate from the others. In this architecture, it would > > not be correct to mount all the models in the virtual server list. > > > > We discussed this in the DT and (I think) agreed there is room / need > for both approaches based on device owner/client management model (i.e., > is the device owner responsible for client config, device owner without > client view.) How does this work in YANG exactly? How does the "foo" container get rooted under "/" in 1 server implementation and get rooted under "/device" in another server implementation? I am confused as to why this would be considered a feature and not a bug. > Do you have a reference for a model that can be used to > support this, or just thinking one is needed? > > Thanks, > Lou > > > > /martin > > > > Andy --001a11c3c46c928263051ec575e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 2, 2015 at 6:17 AM, Lou Berger <lberger@labn.net> wrote:
Martin,

On 09/02/2015 06:42 AM, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.= com> wrote:
>> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger <lberger@labn.net> wrote:
>>> Can one of you give an example of how this word work for a dev= ice (which
>>> may be physical or virtual) that allocates done resources, say= interfaces
>>> to one logical entity (router, system, etc) and other resource= s to a second
>>> entity? And of course I want to manage all with yang and the f= irst and
>>> second (sub) entity must be completely independent and ignoran= t of each
>>> other.
>
> [...]
>
>> The logical system knows only about itself:
>>
>>=C2=A0 =C2=A0 =C2=A0/interfaces
>>=C2=A0 =C2=A0 =C2=A0/system
>
> This is important.
>
>> The / node is represented by <config> or <data> or <= ;filter> in the protocol.
>>
>>=C2=A0 =C2=A0 <get-config>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <source><running/></sour= ce>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <filter>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <interfaces />
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <system />
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</filter>
>>=C2=A0 =C2=A0 </getconfig>
>>
>> Each logical system can have its own "eth0" interface or= whatever.
>> They are mapped to real interfaces in the physical system.
>>
>> All operations on the logical system are validated against its own=
>> virtual datastore.=C2=A0 YANG validation does not work on individu= al array
>> slices -- it only applies to an entire datastore.
>
> Yes.
>
>> On the physical server there needs to be a data model to manage th= e
>> logical servers (as Martin suggested).
>>
>>=C2=A0 <config>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<--- root on PHY server
>>=C2=A0 =C2=A0 <interfaces=C2=A0 />=C2=A0 =C2=A0<----------= ----- contains the real interfaces,
>> including eth23
>>=C2=A0 =C2=A0 <virtual-servers>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<virtual-server>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>vs1</name>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <itf-map>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <real-itf>et= h23</real-itf>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <vir-itf>eth= 0</vir-itf>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <itf-map>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <more-virtual-server-params .= .. />
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <root>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<----------- YANG mount= point (virtual
>> server root)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<interfaces><= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <interfa= ce>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<name>eth0</name>
>>=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 </interf= ace>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</interfaces>=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<system ... />= ;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </root>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </virtual-server>
>>=C2=A0 =C2=A0 =C2=A0</virtual-servers>
>>=C2=A0 =C2=A0</config>
>
> I like this, but I would actually not use mount here.=C2=A0 I don'= t think
> it is necessary.=C2=A0 This would be a model for devices that support<= br> > multiple 'virtual-servers' / 'logical-network-elements'= ;.=C2=A0 So in this
> model you configure these logical-network-elements and allocate
> resources like interfaces etc to them.=C2=A0 For true virtual servers,=
> you'd also configure the NETCONF server and authentication params,=
> meaning that each such virtual server has its own config, which is
> completely separate from the others.=C2=A0 In this architecture, it wo= uld
> not be correct to mount all the models in the virtual server list.
>

We discussed this in the DT and (I think) agreed there is room / need
for both approaches based on device owner/client management model (i.e., is the device owner responsible for client config, device owner without
client view.)=C2=A0


How doe= s this work in YANG exactly?
How does the "foo" contain= er get rooted under "/" in 1 server implementation
and = get rooted under "/device" in another server implementation?
I am confused as to why this would be considered a feature and not a = bug.

=C2=A0
Do= you have a reference for a model that can be used to
support this, or just thinking one is needed?

Thanks,
Lou
>
> /martin
>


Andy

--001a11c3c46c928263051ec575e3-- From nobody Wed Sep 2 08:59:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DB91B4B71 for ; Wed, 2 Sep 2015 08:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2eF0THExo3j for ; Wed, 2 Sep 2015 08:59:15 -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 9404A1B4B6B for ; Wed, 2 Sep 2015 08:59:15 -0700 (PDT) Received: by vkbc123 with SMTP id c123so8480378vkb.3 for ; Wed, 02 Sep 2015 08:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mfphaA3W28B6nc+ZuBRSZG45vdaWhPkYEL6OMtsOZBU=; b=Fd/haVyvGvopHLoN320dHHyvf7NqZVAoIPKE38aogdm0k4rOPGCT6th5cFuP0jDkp9 ODLbjN2jweqAjrO6qrqRwB11FxPFUknpeDaRUEKhnLfnkM/PixFAMTInxdIgETZZ43jJ TOnC+RK2ehfhSbf2IkOh+A77sBXXx9L8V73C1AJXbyaC1UMglHHd8frdSeXu400ImEOM iZSR6XjwVw9+prHtkYEdCjpnqizI6a5wvXJvfvaVmb+kx2OSsjNEJXPCwExjWTpqrbu/ Kpeg7A+CS8C2/FvjU/Pm9ctw/56G1fWLeFdwZn7cTDIUUqpsnuSxDz2t4CeGaQKJgBoC p1hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mfphaA3W28B6nc+ZuBRSZG45vdaWhPkYEL6OMtsOZBU=; b=Pa0S3gp/gMR/hoEALreXz+Km3GDrrbB1z6a6OtVz0Yt+xpxisogDTEoPRI/0yVK+s6 tvyqn70cAhCx0IHgQwdAgNSsQdRR2WjLcw26rgSWEZcu0qV5OQz84AsEeXKJd2DnPzvW TP74JhMTjix8RidG7oxZQpR3abWWnV8rAkBNa9I18kyei3Bum2lHI67EOX79mlvQlhfZ vkXiV81LpVEbZ3JZs7Eb0NIhExF6CtFr3uUsL/WX63z/njk38A8PTygani2FHgAV71YB m30dMCDy81aF3Csi7/FcSDk1BCIrmkUK0ehZoUfSQxHKE+H78sQ3DzRLiD2AuIGQYNrs kQFw== X-Gm-Message-State: ALoCoQkf/nX3B7coAwW4T7m46ZKfS2iBB0ax8Ql8r7dr8xVLdxfGvrAjA1/vufJsrG+Pa/+5zBcc MIME-Version: 1.0 X-Received: by 10.52.99.5 with SMTP id em5mr10216056vdb.27.1441209554546; Wed, 02 Sep 2015 08:59:14 -0700 (PDT) Received: by 10.31.193.5 with HTTP; Wed, 2 Sep 2015 08:59:14 -0700 (PDT) In-Reply-To: References: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net> Date: Wed, 2 Sep 2015 08:59:14 -0700 Message-ID: From: Paul Borman To: Andy Bierman Content-Type: multipart/alternative; boundary=001a1132f4788c04d8051ec5bf60 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:59:18 -0000 --001a1132f4788c04d8051ec5bf60 Content-Type: text/plain; charset=UTF-8 It depends on if you want to be able to just use YANG for schemas, or if you want to force people to use another mechanism on top of YANG to make it flexible enough for complete schemas. For example, an interfaces schema may end up with paths like (I am not using full prefixed YANG paths, so please don't be confused by that): /interfaces/eth0/... But, if you want to report everything about a device, you would probably want: /device/interfaces/eth0/.. /device/protocols/tcp/... Now step back, you actually want to contain everything about all your devices: /router1.me.com/interfaces/eth0/... /router2.me.com/interfaces/eth1/... And now you realize you have other things besides network devices to add to your schema: /network/router1.me.com/interfaces/eth0/... /server/server1.me.com/memory/... And then you want to group by continent and datacenter: /na/dc/network/router1.me.com/interfaces/eth0/... /na/dc/server/server1.me.com/memory/... And since we live in a global community: /me.com/na/dc/network/router1.me.com/interfaces/eth0/... /me.com/na/dc/server/server1.me.com/memory/... These are just examples to show the point, and the point is simple, if you try to authoritatively say where the root of the tree must be, either a) your schema cannot be incorporated, or b) you have to build something on top. Why should an organization expend the incredible amount of effort it takes to describe things in YANG just to have the results limited? I honestly don't care about NETCONF, I care about a schema language we can use, our network device vendors can support, and is flexible enough that we can organize our tree how it makes sense without forcing our global structure onto our vendors. YANG is coming up short for this goal. Thanks, -Paul On Wed, Sep 2, 2015 at 8:38 AM, Andy Bierman wrote: > > > On Wed, Sep 2, 2015 at 6:17 AM, Lou Berger wrote: > >> Martin, >> >> On 09/02/2015 06:42 AM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: >> >>> Can one of you give an example of how this word work for a device >> (which >> >>> may be physical or virtual) that allocates done resources, say >> interfaces >> >>> to one logical entity (router, system, etc) and other resources to a >> second >> >>> entity? And of course I want to manage all with yang and the first and >> >>> second (sub) entity must be completely independent and ignorant of >> each >> >>> other. >> > >> > [...] >> > >> >> The logical system knows only about itself: >> >> >> >> /interfaces >> >> /system >> > >> > This is important. >> > >> >> The / node is represented by or or in the >> protocol. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Each logical system can have its own "eth0" interface or whatever. >> >> They are mapped to real interfaces in the physical system. >> >> >> >> All operations on the logical system are validated against its own >> >> virtual datastore. YANG validation does not work on individual array >> >> slices -- it only applies to an entire datastore. >> > >> > Yes. >> > >> >> On the physical server there needs to be a data model to manage the >> >> logical servers (as Martin suggested). >> >> >> >> <--- root on PHY server >> >> <--------------- contains the real interfaces, >> >> including eth23 >> >> >> >> >> >> vs1 >> >> >> >> eth23 >> >> eth0 >> >> >> >> >> >> <----------- YANG mount point >> (virtual >> >> server root) >> >> >> >> >> >> eth0 >> >> ... >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > I like this, but I would actually not use mount here. I don't think >> > it is necessary. This would be a model for devices that support >> > multiple 'virtual-servers' / 'logical-network-elements'. So in this >> > model you configure these logical-network-elements and allocate >> > resources like interfaces etc to them. For true virtual servers, >> > you'd also configure the NETCONF server and authentication params, >> > meaning that each such virtual server has its own config, which is >> > completely separate from the others. In this architecture, it would >> > not be correct to mount all the models in the virtual server list. >> > >> >> We discussed this in the DT and (I think) agreed there is room / need >> for both approaches based on device owner/client management model (i.e., >> is the device owner responsible for client config, device owner without >> client view.) > > > > How does this work in YANG exactly? > How does the "foo" container get rooted under "/" in 1 server > implementation > and get rooted under "/device" in another server implementation? > I am confused as to why this would be considered a feature and not a bug. > > > >> Do you have a reference for a model that can be used to >> support this, or just thinking one is needed? >> >> Thanks, >> Lou >> > >> > /martin >> > >> >> > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1132f4788c04d8051ec5bf60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It depends on if you want to be able to just use YANG for = schemas, or if you want to force people to use another mechanism on top of = YANG to make it flexible enough for complete schemas.

Fo= r example, an interfaces schema may end up with paths like (I am not using = full prefixed YANG paths, so please don't be confused by that):

/interfaces/eth0/...<= /font>

But, if you want to report everything about= a device, you would probably want:

/device/interfaces/eth0/..
/device/protocols/tcp/...

<= /div>
Now step back, you actually want to contain everything about all = your devices:


And now you realize you have ot= her things besides network devices to add to your schema:


<= /div>
And then you want to group by continent and datacenter:

/na/dc/server= /server1.me.com/memory/...

And since we live in a global community:

Thes= e are just examples to show the point, and the point is simple, if you try = to authoritatively say where the root of the tree must be, either a) your s= chema cannot be incorporated, or b) you have to build something on top.

Why should an organization expend the incredible amou= nt of effort it takes to describe things in YANG just to have the results l= imited?=C2=A0 I honestly don't care about NETCONF, I care about a schem= a language we can use, our network device vendors can support, and is flexi= ble enough that we can organize our tree how it makes sense without forcing= our global structure onto our vendors.=C2=A0 YANG is coming up short for t= his goal.

Thanks,

=C2=A0 = =C2=A0 -Paul

On Wed, Sep 2, 2015 at 8:38 AM, Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaworks.com> wrote:

On Wed, Sep 2, 2015 at 6:17 AM, Lou Berger <lberger@labn.net>= ; wrote:
Martin,

On 09/02/2015 06:42 AM, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.com> wrote:
>> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger <lberger@labn.net> wrote:
>>> Can one of you give an example of how this word work for a dev= ice (which
>>> may be physical or virtual) that allocates done resources, say= interfaces
>>> to one logical entity (router, system, etc) and other resource= s to a second
>>> entity? And of course I want to manage all with yang and the f= irst and
>>> second (sub) entity must be completely independent and ignoran= t of each
>>> other.
>
> [...]
>
>> The logical system knows only about itself:
>>
>>=C2=A0 =C2=A0 =C2=A0/interfaces
>>=C2=A0 =C2=A0 =C2=A0/system
>
> This is important.
>
>> The / node is represented by <config> or <data> or <= ;filter> in the protocol.
>>
>>=C2=A0 =C2=A0 <get-config>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <source><running/></sour= ce>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <filter>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <interfaces />
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <system />
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</filter>
>>=C2=A0 =C2=A0 </getconfig>
>>
>> Each logical system can have its own "eth0" interface or= whatever.
>> They are mapped to real interfaces in the physical system.
>>
>> All operations on the logical system are validated against its own=
>> virtual datastore.=C2=A0 YANG validation does not work on individu= al array
>> slices -- it only applies to an entire datastore.
>
> Yes.
>
>> On the physical server there needs to be a data model to manage th= e
>> logical servers (as Martin suggested).
>>
>>=C2=A0 <config>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<--- root on PHY server
>>=C2=A0 =C2=A0 <interfaces=C2=A0 />=C2=A0 =C2=A0<----------= ----- contains the real interfaces,
>> including eth23
>>=C2=A0 =C2=A0 <virtual-servers>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<virtual-server>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>vs1</name>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <itf-map>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <real-itf>et= h23</real-itf>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <vir-itf>eth= 0</vir-itf>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <itf-map>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <more-virtual-server-params .= .. />
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <root>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<----------- YANG mount= point (virtual
>> server root)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<interfaces><= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <interfa= ce>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<name>eth0</name>
>>=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 </interf= ace>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</interfaces>=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<system ... />= ;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </root>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </virtual-server>
>>=C2=A0 =C2=A0 =C2=A0</virtual-servers>
>>=C2=A0 =C2=A0</config>
>
> I like this, but I would actually not use mount here.=C2=A0 I don'= t think
> it is necessary.=C2=A0 This would be a model for devices that support<= br> > multiple 'virtual-servers' / 'logical-network-elements'= ;.=C2=A0 So in this
> model you configure these logical-network-elements and allocate
> resources like interfaces etc to them.=C2=A0 For true virtual servers,=
> you'd also configure the NETCONF server and authentication params,=
> meaning that each such virtual server has its own config, which is
> completely separate from the others.=C2=A0 In this architecture, it wo= uld
> not be correct to mount all the models in the virtual server list.
>

We discussed this in the DT and (I think) agreed there is room / need
for both approaches based on device owner/client management model (i.e., is the device owner responsible for client config, device owner without
client view.)=C2=A0


=
How does this work in YANG exactly?
How does the "foo&q= uot; container get rooted under "/" in 1 server implementation
and get rooted under "/device" in another server implemen= tation?
I am confused as to why this would be considered a featur= e and not a bug.

=C2=A0
Do you have a reference for a model that can be = used to
support this, or just thinking one is needed?

Thanks,
Lou
>
> /martin
>

Andy

=

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


--001a1132f4788c04d8051ec5bf60-- From nobody Wed Sep 2 09:12:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF3F1B4AD4 for ; Wed, 2 Sep 2015 09:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxhgOBZUmAQ1 for ; Wed, 2 Sep 2015 09:12:10 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 52C051B4AA4 for ; Wed, 2 Sep 2015 09:12:10 -0700 (PDT) Received: (qmail 15602 invoked by uid 0); 2 Sep 2015 16:12:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 2 Sep 2015 16:12:09 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id CNC11r00P2SSUrH01NC41h; Wed, 02 Sep 2015 16:12:08 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=ZutIaTDcMxFky4Jskz4A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=HfpL8M7+/sxbUXHnWCsSOeiKugaYOiyKR/z7S7VVdX0=; b=RxOLXl1P1Jp7JatwGHzOdWVDFD8oa1z9qLX4Bik3QZsm85vO62LkVvAtnBrXg7USQHmtr1CNFxdXb/nfWqCRO5XDjh74Jr1q8dKfOkaOv0w0522o3WmZxbPefc5l/LSU; Received: from box313.bluehost.com ([69.89.31.113]:35000 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZXAdm-0006zh-70; Wed, 02 Sep 2015 10:12:02 -0600 To: Andy Bierman References: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net> From: Lou Berger Message-ID: <55E71FCF.8000709@labn.net> Date: Wed, 2 Sep 2015 12:11:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:12:11 -0000 On 09/02/2015 11:38 AM, Andy Bierman wrote: > > > > I like this, but I would actually not use mount here. I don't think > > it is necessary. This would be a model for devices that support > > multiple 'virtual-servers' / 'logical-network-elements'. So in this > > model you configure these logical-network-elements and allocate > > resources like interfaces etc to them. For true virtual servers, > > you'd also configure the NETCONF server and authentication params, > > meaning that each such virtual server has its own config, which is > > completely separate from the others. In this architecture, it would > > not be correct to mount all the models in the virtual server list. > > > > We discussed this in the DT and (I think) agreed there is room / need > for both approaches based on device owner/client management model (i.e., > is the device owner responsible for client config, device owner without > client view.) > > > > How does this work in YANG exactly? I can see how yang might be used to manage an NFV 'hypervisor' that would spin up some base level of management capability, but would like to hear what Martin was thinking as he's the one that proposed this... Lou > How does the "foo" container get rooted under "/" in 1 server implementation > and get rooted under "/device" in another server implementation? > I am confused as to why this would be considered a feature and not a bug. > > > > Do you have a reference for a model that can be used to > support this, or just thinking one is needed? From nobody Wed Sep 2 09:31:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2F71B3DB3 for ; Wed, 2 Sep 2015 09:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZChblQUGv5M for ; Wed, 2 Sep 2015 09:31:37 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 08FBA1B42B8 for ; Wed, 2 Sep 2015 09:31:30 -0700 (PDT) Received: by padhy1 with SMTP id hy1so16738526pad.1 for ; Wed, 02 Sep 2015 09:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DkaRuFyB/xU6rlZ628hsh50PN9GVW0w5wsQP3WFC/xY=; b=vqkW9Uifdgax1BtMc+Egb2Qk2HYSlm+52p3RPKTKnYCbptCml2aWZM4gZezCavGXWK vxCVjpAJVGkqA6XYAMQCzTZgJuC0CzR2pSdNq4hdpEC+HjvY4PEb2I/jjvoAFG0LXjnw X2EGuk2wqI9ygsSDH2k3Nzj7oEebWOdhdGsezSxQZSjfdSfohdb8jbP11iBLC+SSkUvh kByZ36bsGP9Gie+5UDwqRH9EGmavQ4ZACLk8HpQS6ltaxM/XoerRn5H3Or9jx3SI4StM JKztemcIIo6EcmHN2OvLf4/7icUzUGHfSkR4qdPKP+Vm5Dx8eid9Y864hbsXQs1vm8rJ /OrQ== X-Received: by 10.66.122.97 with SMTP id lr1mr56896743pab.76.1441211489707; Wed, 02 Sep 2015 09:31:29 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1008::34d? ([2001:420:c0c8:1008::34d]) by smtp.gmail.com with ESMTPSA id ev2sm22173737pbb.37.2015.09.02.09.31.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Sep 2015 09:31:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_20B1C768-F5C6-4084-A3EE-66A67B77ECB8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 2 Sep 2015 09:31:27 -0700 Message-Id: References: To: Ladislav Lhotka X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] data tree X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:31:39 -0000 --Apple-Mail=_20B1C768-F5C6-4084-A3EE-66A67B77ECB8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Sep 2, 2015, at 7:31 AM, Ladislav Lhotka wrote: > > Hi, > > one of the topics from the last virtual interim that needs further > discussion is the ambiguity of the term "data tree". In 6020bis, it is > used with three different meanings: > > 1. Explicit definition in Sec. 3: "The instantiated tree of > configuration and state data on a device." > > 2. In many cases, it is used to denote *any* YANG-modelled tree, > i.e. including RPC input/output data and notification. An example is > the definition of container, also in Sec. 3: "An interior data node > that exists in at most one instance in the data tree." > > 3. In a few other cases, it is used in a more restricted sense of a > *configuration* data tree, for example in sec. 4.2.7: "When a node > from one case is created in the data tree, all nodes from all other > cases are implicitly deleted." > > In my review of 6020bis-06 I proposed to use "data tree" only in the > meaning #2, that is: > > OLD > > o data tree: The instantiated tree of configuration and state data > on a device. > > NEW > > o data tree: The instantiated tree of configuration, state data, > combined configuration and state data, RPC input or output, or > notification. > +1 > We could use "configuration data tree" for #3, but a special term would > probably also be needed for #1. > > Comments, suggestions? > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_20B1C768-F5C6-4084-A3EE-66A67B77ECB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 2, 2015, at 7:31 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote:

Hi,
one of the topics from the last virtual = interim that needs further
discussion is the ambiguity of = the term "data tree". In 6020bis, it is
used with three = different meanings:

1. Explicit definition = in Sec. 3: "The instantiated tree of
=   configuration and state data on a device."

2. In many cases, it is used to denote *any* YANG-modelled = tree,
  i.e. including RPC input/output data = and notification. An example is
  the = definition of container, also in Sec. 3: "An interior data node
  that exists in at most one instance in the data = tree."

3. In a few other cases, it is used = in a more restricted sense of a
=   *configuration* data tree, for example in sec. 4.2.7: "When = a node
  from one case is created in the data = tree, all nodes from all other
  cases are = implicitly deleted."

In my review of = 6020bis-06 I proposed to use "data tree" only in the
meaning= #2, that is:

 OLD

    o  data tree: The instantiated = tree of configuration and state data
on a = device.

 NEW

    o data tree: The instantiated tree = of configuration, state data,
=       combined configuration and state = data, RPC input or output, or
=       notification.


+1

We could use "configuration data tree" for #3, but a special = term would
probably also be needed for #1.
Comments, suggestions?

Lada

--
Ladislav Lhotka, CZ.NIC = Labs
PGP Key ID: E74E8C0C

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_20B1C768-F5C6-4084-A3EE-66A67B77ECB8-- From nobody Wed Sep 2 12:03:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8479E1B4A31 for ; Wed, 2 Sep 2015 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzHdPrz6wN_N for ; Wed, 2 Sep 2015 12:03:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 23E831B4B28 for ; Wed, 2 Sep 2015 12:03:15 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 112471AE0498; Wed, 2 Sep 2015 21:03:13 +0200 (CEST) Date: Wed, 02 Sep 2015 21:03:13 +0200 (CEST) Message-Id: <20150902.210313.942746255374334050.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <55E6F6D8.1060405@labn.net> References: <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 19:03:25 -0000 Lou Berger wrote: > Martin, > > On 09/02/2015 06:42 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: > >>> Can one of you give an example of how this word work for a device (which > >>> may be physical or virtual) that allocates done resources, say interfaces > >>> to one logical entity (router, system, etc) and other resources to a second > >>> entity? And of course I want to manage all with yang and the first and > >>> second (sub) entity must be completely independent and ignorant of each > >>> other. > > > > [...] > > > >> The logical system knows only about itself: > >> > >> /interfaces > >> /system > > > > This is important. > > > >> The / node is represented by or or in the protocol. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Each logical system can have its own "eth0" interface or whatever. > >> They are mapped to real interfaces in the physical system. > >> > >> All operations on the logical system are validated against its own > >> virtual datastore. YANG validation does not work on individual array > >> slices -- it only applies to an entire datastore. > > > > Yes. > > > >> On the physical server there needs to be a data model to manage the > >> logical servers (as Martin suggested). > >> > >> <--- root on PHY server > >> <--------------- contains the real interfaces, > >> including eth23 > >> > >> > >> vs1 > >> > >> eth23 > >> eth0 > >> > >> > >> <----------- YANG mount point (virtual > >> server root) > >> > >> > >> eth0 > >> ... > >> > >> > >> > >> > >> > >> > >> > > > > I like this, but I would actually not use mount here. I don't think > > it is necessary. This would be a model for devices that support > > multiple 'virtual-servers' / 'logical-network-elements'. So in this > > model you configure these logical-network-elements and allocate > > resources like interfaces etc to them. For true virtual servers, > > you'd also configure the NETCONF server and authentication params, > > meaning that each such virtual server has its own config, which is > > completely separate from the others. In this architecture, it would > > not be correct to mount all the models in the virtual server list. > > > > We discussed this in the DT and (I think) agreed there is room / need > for both approaches based on device owner/client management model (i.e., > is the device owner responsible for client config, device owner without > client view.) Do you have a reference for a model that can be used to > support this, or just thinking one is needed? I don't know if it is possible to find agreement among hypervisor implementations etc to find a common model. But from a YANG language perspective I think it is pretty straightforward. Since each virtual server is truly virtual, there is no need for the mount functionality in such a model. As for the other model with logical systems within a real system, where each logical system tries to present its own 'system view' of the config and state, even though in reality there is just one config, I think a mechanism like 'mount' would be useful. If it was done with 'mount' instead of the proposed model in draft-rtgyangdt-rtgwg-device-model-00, it doesn't cost anything for the 99% (more?) of all systems that do not have this kind of logical systems, and data models would not have to augment the /device/logical-network-elements/logical-network-element path. /martin From nobody Wed Sep 2 12:06:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7610D1B4B24 for ; Wed, 2 Sep 2015 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIIt-XvHoaj4 for ; Wed, 2 Sep 2015 12:06:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 442DC1B4F0B for ; Wed, 2 Sep 2015 12:06:25 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 867571AE0498; Wed, 2 Sep 2015 21:06:24 +0200 (CEST) Date: Wed, 02 Sep 2015 21:06:24 +0200 (CEST) Message-Id: <20150902.210624.1210217597013068697.mbj@tail-f.com> To: borman@google.com From: Martin Bjorklund In-Reply-To: References: <55E6F6D8.1060405@labn.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 19:06:26 -0000 Paul Borman wrote: > It depends on if you want to be able to just use YANG for schemas, or if > you want to force people to use another mechanism on top of YANG to make it > flexible enough for complete schemas. > > For example, an interfaces schema may end up with paths like (I am not > using full prefixed YANG paths, so please don't be confused by that): > > /interfaces/eth0/... > > But, if you want to report everything about a device, you would probably > want: > > /device/interfaces/eth0/.. > /device/protocols/tcp/... > > Now step back, you actually want to contain everything about all your > devices: > > /router1.me.com/interfaces/eth0/... > /router2.me.com/interfaces/eth1/... > > And now you realize you have other things besides network devices to add to > your schema: > > /network/router1.me.com/interfaces/eth0/... > /server/server1.me.com/memory/... > > And then you want to group by continent and datacenter: > > /na/dc/network/router1.me.com/interfaces/eth0/... > /na/dc/server/server1.me.com/memory/... > > And since we live in a global community: > > /me.com/na/dc/network/router1.me.com/interfaces/eth0/... > /me.com/na/dc/server/server1.me.com/memory/... > > These are just examples to show the point, and the point is simple, if you > try to authoritatively say where the root of the tree must be, either a) > your schema cannot be incorporated, or b) you have to build something on > top. I agree. This illustrates that we should not try to enforce all models to be under /device. If the interface model is under /interfaces, it can then be mounted in different structural models, serving different purposes, as shown above. /martin From nobody Wed Sep 2 13:17:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2F1B2CEB for ; Wed, 2 Sep 2015 13:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwISC9Mevtu1 for ; Wed, 2 Sep 2015 13:17:17 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id E1AE31B2B74 for ; Wed, 2 Sep 2015 13:17:16 -0700 (PDT) Received: (qmail 13816 invoked by uid 0); 2 Sep 2015 20:17:13 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 2 Sep 2015 20:17:13 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id CLH51r0072SSUrH01LH8wT; Wed, 02 Sep 2015 14:17:11 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=vyBYbEnLhHHhiNcwUroA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=mSok/DchSayy/spVfegFP89h+rEKLsr57qUpDTn/TEA=; b=XVwwCf6REyydRyOn+acC4+9L3Ut6cYDP+1T9YtdJE22PXCcHCYDU2cTJxACAfkVubEif3uRis9L5weFbxcTjQfC1xd/N0ZwBbE6o4sqpZAoxr1MfLvPg4+hdTdFR3iSS; Received: from box313.bluehost.com ([69.89.31.113]:53632 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZXESw-0007B7-Pb; Wed, 02 Sep 2015 14:17:07 -0600 To: Martin Bjorklund References: <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net> <20150902.210313.942746255374334050.mbj@tail-f.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55E7593E.7020201@labn.net> Date: Wed, 2 Sep 2015 16:17:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150902.210313.942746255374334050.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 20:17:18 -0000 Martin, On 9/2/2015 3:03 PM, Martin Bjorklund wrote: > If it was done with > 'mount' instead of the proposed model in > draft-rtgyangdt-rtgwg-device-model-00, it doesn't cost anything for > the 99% (more?) of all systems that do not have this kind of logical > systems, and data models would not have to augment the > /device/logical-network-elements/logical-network-element path. This is a compelling point (at least to me). Of course there's lots of details to flush out to make this work, but seems like it's worth exploring this approach in more detail. The initial set of issues I see were in an earlier e-mail: On 9/1/2015 9:45 AM, Lou Berger wrote: > That said, there are some specifics that will need to be addressed to > use this approach: e.g. to quote: > Mounted data is "read-only" data. > YANG-Mount does not extend towards RPCs that are defined as > part of YANG modules whose contents is being mounted. > YANG-Mount does not extend towards notifications. > Perhaps most of these limitations can be relaxed for local mounts. > > Also handling when a device/server doesn't support local mounts (or is > invalid) Lou From nobody Wed Sep 2 17:23:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6DA1B2FBE for ; Wed, 2 Sep 2015 17:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7eCvmuoR_Mf for ; Wed, 2 Sep 2015 17:23:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173CE1A8A84 for ; Wed, 2 Sep 2015 17:23:37 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 3 Sep 2015 00:23:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Thu, 3 Sep 2015 00:23:34 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: posted: draft-kwatsen-netmod-opstate-00 Thread-Index: AQHQ5d7F5vaOtbNW5Eu+UYf7uFNYsg== Date: Thu, 3 Sep 2015 00:23:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:ksPp/GzB8eN20ByruGLope2A5IcIbXxiWv+UbmtR5UWjQbf7K1eyhT2C1TBsrub8a4ZjFv3abIAv2wdj4ou0uzMqVGJvkB0vpqA8RykFziJ1P26XM4g3HBDV9wlNt0qXt8f1eAU1Pdk+LtSxdDouwg==; 24:Kmyjgj/wFgL1v6mZNKN5ZisikYWO6kNwRznOL9otGgIM3nLtsM1XYe/H4x80rkfH55i6HwWG7MzrpWK8FGyLBd/pG3M8DjOlPGzPQQIpuks=; 20:DQiQgZAqILVQ6Vns0zYcDvxM1lEvYUzGpIGDrqIJr+lM+3weYZ3X524gEU/DmxjKaX9Z/JFiGJ6yUj+dQkQljA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0688BF9B46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(189002)(24454002)(52044002)(199003)(377454003)(377424004)(40100003)(10400500002)(189998001)(4001350100001)(87936001)(5001960100002)(110136002)(5001860100001)(107886002)(122556002)(68736005)(50986999)(5001830100001)(5007970100001)(2501003)(15975445007)(77156002)(81156007)(46102003)(4001540100001)(62966003)(36756003)(230783001)(450100001)(5004730100002)(86362001)(64706001)(83506001)(101416001)(102836002)(5002640100001)(229853001)(2351001)(66066001)(2900100001)(99286002)(92566002)(106116001)(97736004)(106356001)(105586002)(54356999)(19580405001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1360F2004A56044EB3F48C973D8EDD7A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2015 00:23:34.6628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: [netmod] posted: draft-kwatsen-netmod-opstate-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 00:23:39 -0000 For next week's interim meeting, but feel free to post comments before then ;) Cheers, Kent On 9/2/15, 7:55 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kwatsen-netmod-opstate-00.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-kwatsen-netmod-opstate >Revision: 00 >Title: Operational State Enhancements for YANG, NETCONF, and RESTCONF >Document date: 2015-09-02 >Group: Individual Submission >Pages: 12 >URL: =20 >https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/ >Htmlized: =20 >https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00 > > >Abstract: > This document presents enhancements to YANG, NETCONF, and RESTCONF to > better support the definition of and access to operational state > data. > > =20 > =20 > > >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. > >The IETF Secretariat > From nobody Wed Sep 2 23:46:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B8A1B3168 for ; Wed, 2 Sep 2015 23:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U67epYofqMvc for ; Wed, 2 Sep 2015 23:46:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 299691B3C3C for ; Wed, 2 Sep 2015 23:46:24 -0700 (PDT) Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id D0FFD1AE0475; Thu, 3 Sep 2015 08:46:21 +0200 (CEST) Date: Thu, 03 Sep 2015 08:46:21 +0200 (CEST) Message-Id: <20150903.084621.2128646705679413229.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <55E7593E.7020201@labn.net> References: <55E6F6D8.1060405@labn.net> <20150902.210313.942746255374334050.mbj@tail-f.com> <55E7593E.7020201@labn.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 06:46:25 -0000 Lou Berger wrote: > Martin, > > On 9/2/2015 3:03 PM, Martin Bjorklund wrote: > > If it was done with > > 'mount' instead of the proposed model in > > draft-rtgyangdt-rtgwg-device-model-00, it doesn't cost anything for > > the 99% (more?) of all systems that do not have this kind of logical > > systems, and data models would not have to augment the > > /device/logical-network-elements/logical-network-element path. > > This is a compelling point (at least to me). Of course there's lots of > details to flush out to make this work, but seems like it's worth > exploring this approach in more detail. > > The initial set of issues I see were in an earlier e-mail: > > On 9/1/2015 9:45 AM, Lou Berger wrote: > > That said, there are some specifics that will need to be addressed to > use this approach: e.g. to quote: > Mounted data is "read-only" data. > > YANG-Mount does not extend towards RPCs that are defined as > part of > YANG modules whose contents is being mounted. > YANG-Mount does not > extend towards notifications. > Perhaps most of these limitations can be > relaxed for local mounts. > > Also handling when a device/server doesn't > support local mounts (or is > invalid) Lou If this is viewed as a way to incorporate the schema defined in another module, rather than tie it to run-time behavior, there is no need to make it read-only. Further, with the addition of 'action' and inline notifications in YANG 1.1, we can make this handle RPCs and notifications at the top-level as well. For example: module system { ... rpc shutdown { ... } } module controller { ... list device { key name; leaf name { ... } leaf addres { ... } mount system; } } would behave similar (forgetting namespaces etc) to as if it was defined as: module controller { ... list device { key name; leaf name { ... } leaf addres { ... } action shutdown { ... } } } Maybe we should try to find another term than 'mount', since it seems people think about the specific solution in draft-clemm-netmod-mount. It might also be necessary to 'mount' parts of a module. /martin From nobody Thu Sep 3 07:06:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D01B36DD for ; Thu, 3 Sep 2015 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEjszeaggqRn for ; Thu, 3 Sep 2015 07:06:08 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7FE1B314C for ; Thu, 3 Sep 2015 07:06:07 -0700 (PDT) Received: from [96.22.157.164] (helo=corretto) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZXV9A-0000IT-Lp; Thu, 03 Sep 2015 15:05:48 +0100 Date: Thu, 3 Sep 2015 10:05:59 -0400 From: Rob Shakir To: "=?utf-8?Q?netmod=40ietf.org?=" , Kent Watsen Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (325) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Cc: "=?utf-8?Q?draft-openconfig-netmod-opstate=40tools.ietf.org?=" Subject: Re: [netmod] review of draft-openconfig-netmod-opstate-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:06:11 -0000 Kent, Apologies, I missed this email. If I can respond to a limited section of = it. On August 24, 2015 at 22:14:47, Kent Watsen (kwatsen=40juniper.net) wrote= : > =20 > And yet again in Section 2, =46igure 1 and text just below it don't squ= are up. The applied =20 > config is shown as having the same leaves as the intended config, and i= s listed below the =20 > line marked config: false. Also, the text says =22Only derived state is= marked as operational =20 > data=22 and while I also see =22operational:true=22 in =46igure 1, this= is a forward reference =20 > to Section 9.1, which is confusing. Attached is a picture illustrating = my view on this.=C2=A0 I don=E2=80=99t agree with this diagram. The applied configuration is ess= entially the current running state of the hardware. It cannot be directly= changed by a user, and hence it needs to be read-only and hence config f= alse. operational: true is used to represent op-state that does not correspond = to any configuration (neither applied, nor intended), but represent param= eters that are related to protocol interactions, counters, etc. This agai= n is read-only. > Also in Section 2, the end of the 6th paragraph states =22To this end, = operational state=C2=A0 > information can be considered to be 'unknown' to the network manager.=22= - what does this mean=3F > =C2=A0 - isn't it just a matter of the NMS polling on this YANG-modeled= data=3F Consider a system that has a single NMS that talks to all elements, and i= t is the *only* means of managing those elements. In general, that NMS kn= ows what the state of the intended config is (it wrote it), if the system= is synchronous then it also knows the state of the applied config. There= fore if it is polling, it is likely to want to only get the derived state= data, which can be filtered on operational true. The intention of these = statements is to impress the need on the reader to have a mechanism to po= ll only this data efficiently (if this is, indeed, to be polled). r. =C2=A0 From nobody Thu Sep 3 07:26:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298921B3ECC for ; Thu, 3 Sep 2015 07:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRQHmYCuGge8 for ; Thu, 3 Sep 2015 07:26:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF21B3ECB for ; Thu, 3 Sep 2015 07:26:14 -0700 (PDT) Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 4557B1AE0475; Thu, 3 Sep 2015 16:26:12 +0200 (CEST) Date: Thu, 03 Sep 2015 16:26:11 +0200 (CEST) Message-Id: <20150903.162611.397597160390971164.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: draft-openconfig-netmod-opstate@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] review of draft-openconfig-netmod-opstate-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:26:18 -0000 Um9iIFNoYWtpciA8cmpzQHJvYi5zaD4gd3JvdGU6DQo+IEkgZG9u4oCZdCBhZ3JlZSB3aXRoIHRo aXMgZGlhZ3JhbS4gVGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBpcw0KPiBlc3NlbnRpYWxseSB0 aGUgY3VycmVudCBydW5uaW5nIHN0YXRlIG9mIHRoZSBoYXJkd2FyZS4gSXQgY2Fubm90IGJlDQo+ IGRpcmVjdGx5IGNoYW5nZWQgYnkgYSB1c2VyLCBhbmQgaGVuY2UgaXQgbmVlZHMgdG8gYmUgcmVh ZC1vbmx5DQoNCkFncmVlZC4NCg0KPiBhbmQgaGVuY2UgY29uZmlnIGZhbHNlLg0KDQpOb3QgbmVj ZXNzYXJpbHkuICBJbiB0aGUgc29sdXRpb24gd2UgcHJvcG9zZSAoc2VlDQpkcmFmdC1rd2F0c2Vu LW5ldG1vZC1vcHN0YXRlKSB0aGUgYXBwbGllZCBjb25maWcgZGF0YXN0b3JlIGlzIHJlYWQNCm9u bHkuDQoNCg0KL21hcnRpbg0K From nobody Thu Sep 3 07:37:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44A1B2B3B for ; Thu, 3 Sep 2015 07:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qWu4_QzIuRR for ; Thu, 3 Sep 2015 07:37:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.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 A74F41B2DFD for ; Thu, 3 Sep 2015 07:37:41 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB409.namprd05.prod.outlook.com (10.141.74.153) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 3 Sep 2015 14:37:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 3 Sep 2015 14:37:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Thu, 3 Sep 2015 14:37:39 +0000 From: Kent Watsen To: Rob Shakir , "netmod@ietf.org" Thread-Topic: [netmod] review of draft-openconfig-netmod-opstate-01 Thread-Index: AQHQ3tu8vk8YCUirU0+DLVhHvjJZNp4q5ZmA///FyAA= Date: Thu, 3 Sep 2015 14:37:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:muOSjfwANHmH/eCms9iEb9O2XBGVwbA7tl5uFy6B1K1p6xtoemhmy12SuExyHQIkrbnYlPdwl/Q/Fe0dMWFzrK3I7DeBqc5Q5f5ERdyBAaEWPy6W+MhWQzY8egp2RuoREnz0B49nA0/lotRT2iaocQ==; 24:zr58AGitB9IddyVZrpOQI0I7oNmSJsVzhj4KVMiuFibBIAa8hscdI46avV6PG48ugcbqXht0lBqhEKMdIkjy+XroecDt7LbBsm4IHaJ4EFY=; 20:g+LElzgBI0IsWRQqz0etJFZmh3LcS8FxvWHwI62eZ95GqXLesPmah/d573slirdutFm2KEXSwQ9NXew9mYchqg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0688BF9B46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(66066001)(5002640100001)(64706001)(83506001)(46102003)(5001860100001)(81156007)(101416001)(189998001)(5001770100001)(76176999)(4001350100001)(54356999)(5001830100001)(2950100001)(50986999)(2900100001)(92566002)(5001960100002)(4001540100001)(230783001)(99286002)(68736005)(36756003)(2501003)(122556002)(87936001)(62966003)(5007970100001)(86362001)(77156002)(10400500002)(102836002)(40100003)(5004730100002)(97736004)(105586002)(106116001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2015 14:37:39.1103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB409; 2:G68NFffhCsr9Qs/7wp//tMaiswyN34vBXV5H3qtyWrR1uNyPg8QJnhnNPu5h6M2kbd0bwh7QlPgYLIMyzToJ3aLR84jfOrtAmGdUGePD0rvlAM2IrRztYBd7hC0V0JML1UxYXroVH43RlYUCa/XpcfkCfdI9lPNGlT6hbfSdw0A=; 23:K/ht6X4big9h4liwDHYXl+K4JtjCCmK9s6/lQQ7tZuRuPjYsB4S5KVkfboDK2CupqRSUr9v4/N1ndL6aE3G2doKuiGae8XYSavOE8kLd8144QTf/jkj1KLfybzVE5Nk6+W3CZyYuVWCb5sgg2XDhovdrlonhG7oIeDm2YqhSeYaWS4pXnb7bG6icgQ1tqA+a X-OriginatorOrg: juniper.net Archived-At: Cc: "draft-openconfig-netmod-opstate@tools.ietf.org" Subject: Re: [netmod] review of draft-openconfig-netmod-opstate-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:37:43 -0000 [as a contributor] Hi Rob, >I don=B9t agree with this diagram. The applied configuration is essentiall= y >the current running state of the hardware. It cannot be directly changed >by a user, and hence it needs to be read-only and hence config false. Agreed that the applied config is read-only, but that doesn't mean the data tree has to be config false. For instance, in the draft submitted yesterday, this requirement is achieved by defining a read-only datastore. >operational: true is used to represent op-state that does not correspond >to any configuration (neither applied, nor intended), but represent >parameters that are related to protocol interactions, counters, etc. This >again is read-only. I'm unclear with the difference, how is it different than data modeled config false? >>Consider a system that has a single NMS that talks to all elements, and >>it is the *only* means of managing those elements. In general, that NMS >>knows what the state of the intended config is (it wrote it), if the >>system is synchronous then it also knows the state of the applied >>config. Therefore if it is polling, it is likely to want to only get the >>derived state data, which can be filtered on operational true. The >>intention of these statements is to impress the need on the reader to >>have a mechanism to poll only this data efficiently (if this is, indeed, >>to be polled). Okay, but there are other ways to enable a client to poll just the derived state (config false nodes). For instance, the draft posted yesterday introduces a operation to do this. K. From nobody Thu Sep 3 13:41:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90381B29EB; Thu, 3 Sep 2015 13:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKIItWkXRdch; Thu, 3 Sep 2015 13:41:03 -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 91CE41AC3CE; Thu, 3 Sep 2015 13:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6223; q=dns/txt; s=iport; t=1441312862; x=1442522462; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=u7GzUENBgirNp0do304f2EduhO/q3GoB3labWTfz1oY=; b=ajSCmhSEnJw/+uvwPtp8BsN+rZ//OwLTVbLx5nhX1HIS3lrZKs4uk8/p afk1haLRXl1ZeQ5vxE/01OjAjoOuGx+vyzx0En6YIkxpBSabEDlxbjsFu +16Ms1z7ghEOx+1ZigvOfL+KlBMgDaIXihIuQn6r86IHn4s8ESm3tqVQD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBAC7r+hV/xbLJq1dg29pgyS8KoV5AoIHAQEBAQEBgQALhCMBAQEEI1QBARAcAwECChYLAgIJAwIBAgE9CAYNBgIBAReIEw23IpRaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhHuEehEHBoJjgUMFjHiIWYUHh3CBSkaDbIJ8kXcmhAE9MwGJSwEBAQ X-IronPort-AV: E=Sophos;i="5.17,464,1437436800"; d="scan'208,217";a="604889611" 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; 03 Sep 2015 20:41:00 +0000 Received: from [10.61.98.198] (dhcp-10-61-98-198.cisco.com [10.61.98.198]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t83KexAw010013; Thu, 3 Sep 2015 20:40:59 GMT References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> To: "netmod@ietf.org" From: Robert Wilton X-Forwarded-Message-Id: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> Message-ID: <55E8B05A.3090903@cisco.com> Date: Thu, 3 Sep 2015 21:40:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080805080200030602000904" Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org Subject: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 20:41:05 -0000 This is a multi-part message in MIME format. --------------080805080200030602000904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I've posted a new experimental draft, that proposes a potential different solution for handling applied configuration, for possible discussion at next week's interim meeting on opstate. Comments before hand are welcome. Thanks, Rob -------- Forwarded Message -------- Subject: New Version Notification for draft-wilton-netmod-opstate-yang-00.txt Date: Thu, 3 Sep 2015 13:31:00 -0700 From: internet-drafts@ietf.org To: Robert Wilton , Robert Wilton A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt has been successfully submitted by Robert Wilton and posted to the IETF repository. Name: draft-wilton-netmod-opstate-yang Revision: 00 Title: "With-config-state" Capability for NETCONF/RESTCONF Document date: 2015-09-03 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt Status: https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/ Htmlized: https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00 Abstract: This document proposes a possible alternative solution for handling applied configuration state in YANG as described in draft-openconfig- netmod-opstate-01. The proposed solution, roughly modelled on the with-defaults NETCONF/RESTCONF capability, aims to meet the key requirements set out in draft-openconfig-netmod-opstate-01 without the need for YANG module authors to explicitly duplicate configuration nodes in both configuration and operational containers. This draft does not address the issue of co-location of configuration and operational state for interfaces, nor does it provide a NETCONF mechanism to retrieve operational data separately from configuration data. 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. The IETF Secretariat --------------080805080200030602000904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I've posted a new experimental draft, that proposes a potential different solution for handling applied configuration, for possible discussion at next week's interim meeting on opstate.

Comments before hand are welcome.

Thanks,
Rob


-------- Forwarded Message --------
Subject: New Version Notification for draft-wilton-netmod-opstate-yang-00.txt
Date: Thu, 3 Sep 2015 13:31:00 -0700
From: internet-drafts@ietf.org
To: Robert Wilton <rwilton@cisco.com>, Robert Wilton <rwilton@cisco.com> 


A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.

Name:		draft-wilton-netmod-opstate-yang
Revision:	00
Title:		"With-config-state" Capability for NETCONF/RESTCONF
Document date:	2015-09-03
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:       https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00


Abstract:
   This document proposes a possible alternative solution for handling
   applied configuration state in YANG as described in draft-openconfig-
   netmod-opstate-01.  The proposed solution, roughly modelled on the
   with-defaults NETCONF/RESTCONF capability, aims to meet the key
   requirements set out in draft-openconfig-netmod-opstate-01 without
   the need for YANG module authors to explicitly duplicate
   configuration nodes in both configuration and operational containers.
   This draft does not address the issue of co-location of configuration
   and operational state for interfaces, nor does it provide a NETCONF
   mechanism to retrieve operational data separately from configuration
   data.

                                                                                  


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.

The IETF Secretariat


--------------080805080200030602000904-- From nobody Thu Sep 3 14:50:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236101B3685 for ; Thu, 3 Sep 2015 14:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knV6u4GZFf6b for ; Thu, 3 Sep 2015 14:50:37 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 4FD871B36AF for ; Thu, 3 Sep 2015 14:50:37 -0700 (PDT) Received: by lbcjc2 with SMTP id jc2so1612058lbc.0 for ; Thu, 03 Sep 2015 14:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6lpHHGk2kd8TxuyZEbxMNfcRBZPyGQGEk1tTNKM6nV0=; b=jLXIYLNofFG0QQ9KU8oQDM6+R2YpXC8bYySAQc1XRnHKeZEZjTrakrxrs4bo99wU9d PLXj3MQpo5tEkRFmkHIrSKpjc/uzdYu0d5MhyyM8cQianoI1/d5zs80cdII3oIy+Rfwd UwXcs2AqDeStJ9vNdlh/WOh3eav3xUB6Ob/S1RvZw5iw2BY9wDK/PBFGb1vxEtWywy/a uhTlMw+UQYwwbPoT4wAi1YrRkZC3Bw2zU4C9OSmmrGwMESgOHK+qhT45dCyaxo0uq7w9 lwoKI4MSi6mdoodS9h3C1Dt2PQbxlaqQ77j1JH/65dlvY7j+WNNt5rksy+PwcQfW9KtP VSfw== X-Gm-Message-State: ALoCoQlf6q6lGiNRCcSi+KCIkDnR+bhtILNNdJXycS0EkQJKxm16QA9S/T0i8M2mVySAUXql5xCd MIME-Version: 1.0 X-Received: by 10.112.163.72 with SMTP id yg8mr147148lbb.82.1441317035593; Thu, 03 Sep 2015 14:50:35 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 3 Sep 2015 14:50:35 -0700 (PDT) In-Reply-To: <55E8B05A.3090903@cisco.com> References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> Date: Thu, 3 Sep 2015 14:50:35 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=089e0118366cea6849051edec55f Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 21:50:43 -0000 --089e0118366cea6849051edec55f Content-Type: text/plain; charset=UTF-8 On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton wrote: > Hi, > > I've posted a new experimental draft, that proposes a potential different > solution for handling applied configuration, for possible discussion at > next week's interim meeting on opstate. > > Comments before hand are welcome. > > This is better than the "config" and "state" containers at least. Multiple schema nodes to represent the same object in different states doubles the complexity of the module. Considering 97% + of devices don't need this stuff, that's just not worth 2X the cost. However, it is important that the schema be stable. The way an is parsed cannot really depend on an that was sent earlier. But a leaf like will either be represented as a leaf or as a container in the , depending on the parameter that was sent in the . I appreciate sec. 7. It is good to relate the solution back to the requirements (even if that list seems to be growing every week). I have not personally seen the problems in the requirements list. The delay between intended and applied is usually milliseconds, sometimes seconds. I don't agree that we need to diagnose line cards that are not plugged in. The operator should figure this out some other way (e.g. entity-mib). It is not clear how long this data will indicate 'in progress'. Most of the time, and will be the same. (This basically triples the size of a response) I don't see why any enum other than 'diff-cfg-only' would be used. This is how I would also expect the operation to work in Kent's draft. It would really help if you included the YANG module you want to standardize. There are a couple examples but no formal definition. Thanks, > Rob > Andy > > > -------- Forwarded Message -------- Subject: New Version Notification for > draft-wilton-netmod-opstate-yang-00.txt Date: Thu, 3 Sep 2015 13:31:00 > -0700 From: internet-drafts@ietf.org To: Robert Wilton > , Robert Wilton > > A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt > has been successfully submitted by Robert Wilton and posted to the > IETF repository. > > Name: draft-wilton-netmod-opstate-yang > Revision: 00 > Title: "With-config-state" Capability for NETCONF/RESTCONF > Document date: 2015-09-03 > Group: Individual Submission > Pages: 22 > URL: https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt > Status: https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/ > Htmlized: https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00 > > > Abstract: > This document proposes a possible alternative solution for handling > applied configuration state in YANG as described in draft-openconfig- > netmod-opstate-01. The proposed solution, roughly modelled on the > with-defaults NETCONF/RESTCONF capability, aims to meet the key > requirements set out in draft-openconfig-netmod-opstate-01 without > the need for YANG module authors to explicitly duplicate > configuration nodes in both configuration and operational containers. > This draft does not address the issue of co-location of configuration > and operational state for interfaces, nor does it provide a NETCONF > mechanism to retrieve operational data separately from configuration > data. > > > > > 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. > > The IETF Secretariat > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --089e0118366cea6849051edec55f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20
Hi,

I've posted a new experimental draft, that proposes a potential different solution for handling applied configuration, for possible discussion at next week's interim meeting on opstate.

Comments before hand are welcome.


This is better than the &quo= t;config" and "state" containers at least.
Multipl= e schema nodes to represent the same object in different states
d= oubles the complexity of the module. Considering 97% + of devices
don't need this stuff, that's just not worth 2X the cost.

However, it is important that the schema be stable.
<= div>The way an <rpc-reply> is parsed cannot really depend on an <r= pc> that
was sent earlier.=C2=A0 But a leaf like <mtu> w= ill either be represented as a leaf
or as a container in the <= rpc-reply>, depending on
the <with-config-state> paramet= er that was sent in the <rpc>.

I appreciate = sec. 7. It is good to relate the solution back to
the requirement= s (even if that list seems to be growing every week).

<= div>I have not personally seen the problems in the requirements list.
=
The delay between intended and applied is usually milliseconds, someti= mes seconds.
I don't agree that we need to diagnose line card= s that are not plugged in.
The operator should figure this out so= me other way (e.g. entity-mib).

It is not clear ho= w long this data will indicate 'in progress'.
Most of the= time, <cfg-intended> and <cfg-actual> will be the same.
<= div>(This basically triples the size of a <get-config> response)
I don't see why any enum other than 'diff-cfg-only' would= be used.
This is how I would also expect the <get-state> o= peration to work in Kent's draft.


It would really help if you included the YANG module you want to
standardize.=C2=A0 There are a couple examples but no formal definition.=


Thanks,
Rob


Andy
=
=C2=A0


-------- Forwarded Message --------
Subject: New Version Notification for draft-wilton-netmod-opstate-yang-00.txt
Date: Thu, 3 Sep 2015 13:31:00 -0700
From: internet-drafts@ietf.org
To: Robert Wilton <rwilton@cisco.com>, Robert Wilton <rw= ilton@cisco.com> 


A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.

Name:		draft-wilton-netmod-opstate-yang
Revision:	00
Title:		"With-config-state" Capability for NETCONF/RESTCONF
Document date:	2015-09-03
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/intern=
et-drafts/draft-wilton-netmod-opstate-yang-00.txt
Status:         https://datatracker.ietf.org/doc/draf=
t-wilton-netmod-opstate-yang/
Htmlized:       https://tools.ietf.org/html/draft-wilton=
-netmod-opstate-yang-00


Abstract:
   This document proposes a possible alternative solution for handling
   applied configuration state in YANG as described in draft-openconfig-
   netmod-opstate-01.  The proposed solution, roughly modelled on the
   with-defaults NETCONF/RESTCONF capability, aims to meet the key
   requirements set out in draft-openconfig-netmod-opstate-01 without
   the need for YANG module authors to explicitly duplicate
   configuration nodes in both configuration and operational containers.
   This draft does not address the issue of co-location of configuration
   and operational state for interfaces, nor does it provide a NETCONF
   mechanism to retrieve operational data separately from configuration
   data.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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


--089e0118366cea6849051edec55f-- From nobody Fri Sep 4 00:38:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBB1B3769; Fri, 4 Sep 2015 00:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7okVskPom0b; Fri, 4 Sep 2015 00:38:48 -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 BB3691B34A7; Fri, 4 Sep 2015 00:38:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 60C3D1026; Fri, 4 Sep 2015 09:38:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SWoeazAThLgo; Fri, 4 Sep 2015 09:38:45 +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; Fri, 4 Sep 2015 09:38:45 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0972B2004E; Fri, 4 Sep 2015 09:38:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N1gYU6Oe5jfC; Fri, 4 Sep 2015 09:38:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C2E320048; Fri, 4 Sep 2015 09:38:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BC4CA36F5761; Fri, 4 Sep 2015 09:38:35 +0200 (CEST) Date: Fri, 4 Sep 2015 09:38:34 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20150904073832.GB32036@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" , draft-openconfig-netmod-opstate@ietf.org References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E8B05A.3090903@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 07:38:49 -0000 Hm. Adding a parameter to get-config() that changes the encoding of data very fundamentally is somehow difficult to fall in love with. If you would have used meta-data, things would likely easier to like, e.g., instead of 9000 waiting Linecard 1 is not available using something like this 9000 would have made more sense to me from an encoding point of view. There might be issues with carrying actual config values in metadata in XML, I guess I like the actual datastore approach still a bit more (but perhaps having standard meta-data annotations providing additional information might actually be useful. /js On Thu, Sep 03, 2015 at 09:40:58PM +0100, Robert Wilton wrote: > Hi, > > I've posted a new experimental draft, that proposes a potential > different solution for handling applied configuration, for possible > discussion at next week's interim meeting on opstate. > > Comments before hand are welcome. > > Thanks, > Rob > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-wilton-netmod-opstate-yang-00.txt > Date: Thu, 3 Sep 2015 13:31:00 -0700 > From: internet-drafts@ietf.org > To: Robert Wilton , Robert Wilton > > > > A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt > has been successfully submitted by Robert Wilton and posted to the > IETF repository. > > Name: draft-wilton-netmod-opstate-yang > Revision: 00 > Title: "With-config-state" Capability for NETCONF/RESTCONF > Document date: 2015-09-03 > Group: Individual Submission > Pages: 22 > URL: > https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/ > Htmlized: > https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00 > > > Abstract: > This document proposes a possible alternative solution for handling > applied configuration state in YANG as described in draft-openconfig- > netmod-opstate-01. The proposed solution, roughly modelled on the > with-defaults NETCONF/RESTCONF capability, aims to meet the key > requirements set out in draft-openconfig-netmod-opstate-01 without > the need for YANG module authors to explicitly duplicate > configuration nodes in both configuration and operational containers. > This draft does not address the issue of co-location of configuration > and operational state for interfaces, nor does it provide a NETCONF > mechanism to retrieve operational data separately from configuration > data. > > > > > 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. > > The IETF Secretariat > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 4 01:26:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4F01A86E3 for ; Fri, 4 Sep 2015 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJR_8rgMN742 for ; Fri, 4 Sep 2015 01:26: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 8C4E51B3AB0 for ; Fri, 4 Sep 2015 01:26:54 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-60-55e955cccb95 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.06.29154.CC559E55; Fri, 4 Sep 2015 10:26:52 +0200 (CEST) Received: from [159.107.197.169] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.248.2; Fri, 4 Sep 2015 10:26:51 +0200 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: <55E955CB.30007@ericsson.com> Date: Fri, 4 Sep 2015 10:26:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010300040200080300080509" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje6Z0JehBgdW6VnMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHnXtrIXrBGs+LD9GHMD4zn+LkZODgkBE4nuqbfYIGwxiQv3 1gPZXBxCAkcZJbZvncEK4axhlPj57SMLSJWIgLrEzJ3rwTrYBIwkpvafB4sLC+hL7Jw5hb2L kYODV0BT4tR7E5Awi4CKROvEDcwgtqhAjETPrw1grbwCghInZz4Ba2UWCJBoWNYPViMkoCHx 8MJf1gmMvLOQlM1CUgZhW0jMnH+eEcKWl9j+dg5U3Fri5LlOqLiixJTuh+wQtqlEy/+pzAsY 2VcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBIbmwS2/rXYwHnzueIhRgINRiYdX4feLUCHW xLLiytxDjNIcLErivM1MD0KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLpef2wyd8UPA7Ov 9x2WTmP+dvAgt7vFWdZkge1q+ryzbPrLAhdJvF266j3znwW1/wUvaBXW6KuYHurn4Vql21yQ ZRynueGjrZeSmLjpBbPYyL43yV2fLc453F5p+0HmPft/yceaHjrTK+PV7iXtX/8rmnvS9KOG 8wJ/FiV8X6qxPSPR7MzJC0osxRmJhlrMRcWJAAQBNVAuAgAA Archived-At: Subject: [netmod] Name collision in embedded choice/case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 08:26:58 -0000 --------------010300040200080300080509 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, The attached module was accepted as valid by pyang and by the http://www.netconfcentral.org/ validator. IMHO it should be invalid as it seems to allow two a1 and two a2 definition inside choices desease and kongo. The operation 5 <\edit-config> would be abigious. Does the value 5 belong to the case pest or the case ebola? Opinions? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------010300040200080300080509 Content-Type: text/plain; charset="UTF-8"; name="rec2.yang" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rec2.yang" bW9kdWxlIHJlYzINCnsNCiAgIG5hbWVzcGFjZSAiaHR0cDovL3Jla3Vyc2VyYS5mZXR0IjsN CiAgIHByZWZpeCBmZXR0Ow0KICAgY29udGFpbmVyIGhvc3BpdGFsDQogICB7DQogICAgICBs ZWFmIGEwDQogICAgICB7DQogICAgICAgICB0eXBlIHVpbnQxNjsNCiAgICAgIH0NCiAgICAg IGNob2ljZSBkaXNlYXNlDQogICAgICB7DQogICAgICAgICBjYXNlIHBlc3QNCiAgICAgICAg IHsNCiAgICAgICAgICAgIGxlYWYgYTENCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg IHR5cGUgdWludDE2Ow0KICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAgICAgICAgY2Fz ZSBrb2xlcmENCiAgICAgICAgIHsNCiAgICAgICAgICAgIGxlYWYgYTINCiAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgIHR5cGUgdWludDE2Ow0KICAgICAgICAgICAgfQ0KICAgICAg ICAgfQ0KICAgICAgICAgY2FzZSBrb25nbw0KICAgICAgICAgew0KICAgICAgICAgICAgY2hv aWNlIGp1bmdsZS1kaXNlYXNlDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICBjYXNl IGVib2xhDQogICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICBsZWFmIGExDQog ICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICB0eXBlIHVpbnQxNjsN CiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg IGNhc2UgbWFyYnVyZw0KICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgbGVh ZiBhMg0KICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgdHlwZSB1 aW50MTY7DQogICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICB9DQogICAgICAg ICAgICB9DQogICAgICAgICB9DQogICAgICB9DQogICB9DQp9DQo= --------------010300040200080300080509-- From nobody Fri Sep 4 01:31:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574671B386D for ; Fri, 4 Sep 2015 01:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh2DU8LG8I_u for ; Fri, 4 Sep 2015 01:31:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5781B37FA for ; Fri, 4 Sep 2015 01:31:46 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 51CDD1CC0047 for ; Fri, 4 Sep 2015 10:31:47 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 04 Sep 2015 10:31:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] routing-cfg: interfaces and routing instances X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 08:31:48 -0000 Hi, one open issue regarding the routing-cfg document (where even the co-authors cannot reach agreement) is the assignment of interfaces to routing instances, see slides 7 and 8 in https://www.ietf.org/proceedings/93/slides/slides-93-netmod-6.pdf The discussion is only about configuration, in state data we already have links in both directions: interface -> routing instance and routing instance -> interfaces. For configuring the assignment, there are essentially two options: 1. A leaf-list of leafref type under rt:routing-instance containing references to interfaces assigned to the routing instance (this is the current solution in -19). 2. A leaf of leafref type under if:interface containing a reference to the routing instance to which the interface is assigned. I think the advantage of #1 is that it helps enforce two important constraints: A. Routing protocols, route filters etc. of a routing instance should refer only to interfaces assigned to the routing instance. B. Interfaces assigned to a routing instance should be L3. Constraint A can be represented via an XPath expression in both variants #1 and #2 but the point is that interfaces need to be referenced many times from a routing instance, e.g. every routing protocol instance typically has some interface configuration. It is then IMO more effective and cleaner to have just one set of references from rt:routing-instance to if:interface where constraint A is stated and validated. Other references from within the routing instance to interfaces would use the assigned interfaces under rt:routing-instance and constraint A is then trivially satisfied through containment hierarchy. With option #2 it would be necessary to add a corresponding "must" statement to every leafref pointing to if:interface. Constraint B is difficult to validate formally because layering information is not explicitly present in the flat if:interface list. But even then I believe it is cleaner to have a list of all interfaces assigned to a routing instance in one place rather than having this information scattered thoughout if:interface - it is easier to check that all these interfaces are in fact L3. Acee advocates option #2 because it is more logical to assign IP address space (which is done under if:interface) in conjuction with assigning the interface to a routing instance. Finally, let me note that either option is just a matter of internal data model organisation in that user interfaces can use the other alternative if their designers wish to do so - the mapping is actually quite easy. So please indicate your preference and add more arguments in favour of either option. We would like to have this issue finally resolved. Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Sep 4 01:44:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF01A066B for ; Fri, 4 Sep 2015 01:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_DA40N4kHz7 for ; Fri, 4 Sep 2015 01:44:50 -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 08E411A00B6 for ; Fri, 4 Sep 2015 01:44:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C84D5129E; Fri, 4 Sep 2015 10:44:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xZ0vgFXX7biZ; Fri, 4 Sep 2015 10:44:48 +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; Fri, 4 Sep 2015 10:44:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2239E2004E; Fri, 4 Sep 2015 10:44:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J-uWHI4TDkaS; Fri, 4 Sep 2015 10:44:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FB7220048; Fri, 4 Sep 2015 10:44:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0CFCE36F59A8; Fri, 4 Sep 2015 10:44:42 +0200 (CEST) Date: Fri, 4 Sep 2015 10:44:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150904084442.GA32303@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] routing-cfg: interfaces and routing instances X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 08:44:52 -0000 On Fri, Sep 04, 2015 at 10:31:44AM +0200, Ladislav Lhotka wrote: > > So please indicate your preference and add more arguments in favour of > either option. We would like to have this issue finally resolved. > I have no opinion what the "best" answer is but one dimension to consider might be access control. Does one of the two options lead to a simpler way to partition access rights for meaningful use cases? /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 Fri Sep 4 01:46:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C4C1A8A89 for ; Fri, 4 Sep 2015 01:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm3lfKnLnart for ; Fri, 4 Sep 2015 01:46:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45FD1A89AA for ; Fri, 4 Sep 2015 01:46:19 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 5C591181A6C; Fri, 4 Sep 2015 10:46:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441356378; bh=S9yPebMRLcwopVpga4ODg41Q9KpxFk2suQzrlVlPFFo=; h=From:Date:To; b=Oiq1GNI3jKaBk8rStjJuyKagW8p7//mdukpH97r7g1EIjImgpaW01NTCJ0+lquUQA VbmEk0mteYGnGQoU+sBwQ2HEpA4BAjDyQaBpC/zvVqWRKqQ07VQGcIGGEE0LNrbPrt RDPPy0ainfWKSYNgan56mcTYbeeRE3VuG7WlQIiY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <55E955CB.30007@ericsson.com> Date: Fri, 4 Sep 2015 10:46:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E704062-A030-4E0D-A324-84365EDF8D6A@nic.cz> References: <55E955CB.30007@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Name collision in embedded choice/case X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 08:46:21 -0000 > On 04 Sep 2015, at 10:26, Balazs Lengyel = wrote: >=20 > Hello, > The attached module was accepted as valid by pyang and by the = http://www.netconfcentral.org/ validator. IMHO it should be invalid as = it seems to allow two a1 and two a2 definition inside choices desease = and kongo. > The operation > > > 5 > > <\edit-config> > would be abigious. Does the value 5 belong to the case pest or the = case ebola? > Opinions? I agree, this is clearly invalid. Lada > regards Balazs >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Sep 4 03:11:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213D61B346A; Fri, 4 Sep 2015 03:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ6bSyVrcQ94; Fri, 4 Sep 2015 03:11:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42111B2DF9; Fri, 4 Sep 2015 03:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24410; q=dns/txt; s=iport; t=1441361477; x=1442571077; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+Kke2jwWUTKkqs8xvncKAYo34YmpIxH/xlDopfwImRM=; b=Gvzu1AoeRJhJsfuSNS+vMycfdGON7OFcX4FAwgMlnoAIFxfuodo+iuE3 +TPyDLCMr4+aH3Xbg7Jaif2ONV+dzm0196nCIayccv+Nh3wrNid4qMQmw 0dovX0U6N8JA5WeeLp04RLxmYMk2nHKbUW0A0FwmuGlIWYfmFPfJ7MT2S s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGAgAQbelV/xbLJq1dg3VpvVUBCYFtAQuFL0oCgXIUAQEBAQEBAYEKhCMBAQEDAQEBASBLCQEBBQsLEQMBAgEJFgEHAwICCQMCAQIBFR8JCAYNBgIBAReICwgNtg2UOQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R7hHoRBwaCY4FDBYcuhUmBLYQNgyCFB4IohUiBSkaDbIJ8I5FVJoJCgT89MwGJSgEBAQ X-IronPort-AV: E=Sophos;i="5.17,468,1437436800"; d="scan'208,217";a="611383940" 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; 04 Sep 2015 10:11:14 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t84ABELJ011123; Fri, 4 Sep 2015 10:11:14 GMT To: Andy Bierman References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> From: Robert Wilton Message-ID: <55E96E42.2070604@cisco.com> Date: Fri, 4 Sep 2015 11:11:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060708040909060104030809" Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 10:11:31 -0000 This is a multi-part message in MIME format. --------------060708040909060104030809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Thanks for the review and comments, please see inline ... On 03/09/2015 22:50, Andy Bierman wrote: > > > On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton > wrote: > > Hi, > > I've posted a new experimental draft, that proposes a potential > different solution for handling applied configuration, for > possible discussion at next week's interim meeting on opstate. > > Comments before hand are welcome. > > > This is better than the "config" and "state" containers at least. > Multiple schema nodes to represent the same object in different states > doubles the complexity of the module. Agreed. > Considering 97% + of devices > don't need this stuff, that's just not worth 2X the cost. Not sure that I agree with the the 97% figure, but I don't have any concrete data to go on ... > > However, it is important that the schema be stable. > The way an is parsed cannot really depend on an that > was sent earlier. But a leaf like will either be represented as > a leaf > or as a container in the , depending on > the parameter that was sent in the . Generally, I would prefer it if an could be processed independently of the request (e.g. perhaps by embedding the request data in the response). However, it seems to me that you already need to know the context of the request to be able to semantically process the reply. E.g. I would expect that you would need to know what the request is, what filters are in effect, when any of the get-default options are in effect (since that changes the meaning of the data returned for some config nodes). So, I appreciate that if can't be a generic parser cannot be used, then a client would need to perform a lookup of the request context before parsing the reply. But it doesn't feel like this is a particularly hard problem. > > I appreciate sec. 7. It is good to relate the solution back to > the requirements (even if that list seems to be growing every week). > > I have not personally seen the problems in the requirements list. Some Cisco devices (that I haven't directly worked with) use an eventual consistency configuration model, and would probably more naturally fit into a split intended/applied config model proposed by the Open Config group. Further, I suspect that more of the new developed devices may adopt this approach in future. > The delay between intended and applied is usually milliseconds, > sometimes seconds. For many of the smaller config changes that I agree that they might only take a second or two. But for large scale config changes (e.g. 1M+ lines of config) then it can take 1-30 minutes to apply the configuration and ensure that all of the hardware is programmed. For these systems, I can see that there is a benefit to be able to see exactly what configuration is in effect at a given point in time. I suspect that one of the reasons that the global Internet works so well is because the routing protocols adopt an eventual consistency model, e.g. the global routing table being in constant flux. So I can also certainly see the appeal of adopting an asynchronous eventual consistency configuration model where 10,000's of devices are being managed and the network is being constantly dynamically optimized for the demands being placed on it. > I don't agree that we need to diagnose line cards that are not plugged in. > The operator should figure this out some other way (e.g. entity-mib). OK, what about a linecard that has crashed, or failed to boot, or suffered a hardware failure? Ultimately, the operator (which in this scenario will probably be a machine) needs to able to correlate a failure back to the operation that it was trying to achieve in the first place. The related-state statement in Kent's draft helps here, but for an asynchronous configuration model there needs to be a way to indicate errors in applying that configuration that previously could have been returned as 's in the of the original request. > > It is not clear how long this data will indicate 'in progress'. > Most of the time, and will be the same. Agreed. > (This basically triples the size of a response) > I don't see why any enum other than 'diff-cfg-only' would be used. OK. > This is how I would also expect the operation to work in > Kent's draft. I may be misunderstanding Kent's draft (I'll send comments on it separately), but I read the operation as only returning "config false" nodes and hence doesn't help with the intended config vs applied config problem. > > > It would really help if you included the YANG module you want to > standardize. There are a couple examples but no formal definition. OK. I'll try and also write that up. My excuse is that I spent quite a lot of August on PTO and hence have only had a couple of days to write this idea up. Thanks again for the comments, Rob > > > Thanks, > Rob > > > > Andy > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-wilton-netmod-opstate-yang-00.txt > Date: Thu, 3 Sep 2015 13:31:00 -0700 > From: internet-drafts@ietf.org > To: Robert Wilton , > Robert Wilton > > > > A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt > has been successfully submitted by Robert Wilton and posted to the > IETF repository. > > Name: draft-wilton-netmod-opstate-yang > Revision: 00 > Title: "With-config-state" Capability for NETCONF/RESTCONF > Document date: 2015-09-03 > Group: Individual Submission > Pages: 22 > URL:https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt > Status:https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/ > Htmlized:https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00 > > > Abstract: > This document proposes a possible alternative solution for handling > applied configuration state in YANG as described in draft-openconfig- > netmod-opstate-01. The proposed solution, roughly modelled on the > with-defaults NETCONF/RESTCONF capability, aims to meet the key > requirements set out in draft-openconfig-netmod-opstate-01 without > the need for YANG module authors to explicitly duplicate > configuration nodes in both configuration and operational containers. > This draft does not address the issue of co-location of configuration > and operational state for interfaces, nor does it provide a NETCONF > mechanism to retrieve operational data separately from configuration > data. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available attools.ietf.org . > > The IETF Secretariat > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --------------060708040909060104030809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andy,

Thanks for the review and comments, please see inline ...

On 03/09/2015 22:50, Andy Bierman wrote:


On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton <rwilton@cisco.com> wrote:
Hi,

I've posted a new experimental draft, that proposes a potential different solution for handling applied configuration, for possible discussion at next week's interim meeting on opstate.

Comments before hand are welcome.


This is better than the "config" and "state" containers at least.


Multiple schema nodes to represent the same object in different states
doubles the complexity of the module.
Agreed.

Considering 97% + of devices
don't need this stuff, that's just not worth 2X the cost.

Not sure that I agree with the the 97% figure, but I don't have any concrete data to go on ...



However, it is important that the schema be stable.
The way an <rpc-reply> is parsed cannot really depend on an <rpc> that
was sent earlier.  But a leaf like <mtu> will either be represented as a leaf
or as a container in the <rpc-reply>, depending on
the <with-config-state> parameter that was sent in the <rpc>.
Generally, I would prefer it if an <rpc-reply> could be processed independently of the <rpc> request (e.g. perhaps by embedding the request data in the response).

However, it seems to me that you already need to know the context of the request to be able to semantically process the reply.
E.g. I would expect that you would need to know what the request is, what filters are in effect, when any of the get-default options are in effect (since that changes the meaning of the data returned for some config nodes).

So, I appreciate that if can't be a generic parser cannot be used, then a client would need to perform a lookup of the request context before parsing the reply.  But it doesn't feel like this is a particularly hard problem.



I appreciate sec. 7. It is good to relate the solution back to
the requirements (even if that list seems to be growing every week).

I have not personally seen the problems in the requirements list.
Some Cisco devices (that I haven't directly worked with) use an eventual consistency configuration model, and would probably more naturally fit into a split intended/applied config model proposed by the Open Config group.  Further, I suspect that more of the new developed devices may adopt this approach in future.


The delay between intended and applied is usually milliseconds, sometimes seconds.
For many of the smaller config changes that I agree that they might only take a second or two.

But for large scale config changes (e.g. 1M+ lines of config) then it can take 1-30 minutes to apply the configuration and ensure that all of the hardware is programmed.  For these systems, I can see that there is a benefit to be able to see exactly what configuration is in effect at a given point in time.

I suspect that one of the reasons that the global Internet works so well is because the routing protocols adopt an eventual consistency model, e.g. the global routing table being in constant flux.  So I can also certainly see the appeal of adopting an asynchronous eventual consistency configuration model where 10,000's of devices are being managed and the network is being constantly dynamically optimized for the demands being placed on it.


I don't agree that we need to diagnose line cards that are not plugged in.
The operator should figure this out some other way (e.g. entity-mib).
OK, what about a linecard that has crashed, or failed to boot, or suffered a hardware failure?

Ultimately, the operator (which in this scenario will probably be a machine) needs to able to correlate a failure back to the operation that it was trying to achieve in the first place.  The related-state statement in Kent's draft helps here, but for an asynchronous configuration model there needs to be a way to indicate errors in applying that configuration that previously could have been returned as <rpc-error>'s in the <rpc-reply> of the original <edit-config> request.



It is not clear how long this data will indicate 'in progress'.
Most of the time, <cfg-intended> and <cfg-actual> will be the same.
Agreed.

(This basically triples the size of a <get-config> response)
I don't see why any enum other than 'diff-cfg-only' would be used.
OK.

This is how I would also expect the <get-state> operation to work in Kent's draft.
I may be misunderstanding Kent's draft (I'll send comments on it separately), but I read the <get-state> operation as only returning "config false" nodes and hence doesn't help with the intended config vs applied config problem.



It would really help if you included the YANG module you want to
standardize.  There are a couple examples but no formal definition.
OK.  I'll try and also write that up.  My excuse is that I spent quite a lot of August on PTO and hence have only had a couple of days to write this idea up.

Thanks again for the comments,
Rob



Thanks,
Rob


Andy
 


-------- Forwarded Message --------
Subject: New Version Notification for draft-wilton-netmod-opstate-yang-00.txt
Date: Thu, 3 Sep 2015 13:31:00 -0700
From: internet-drafts@ietf.org
To: Robert Wilton <rwilton@cisco.com>, Robert Wilton <rwilton@cisco.com> 


A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.

Name:		draft-wilton-netmod-opstate-yang
Revision:	00
Title:		"With-config-state" Capability for NETCONF/RESTCONF
Document date:	2015-09-03
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:       https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00


Abstract:
   This document proposes a possible alternative solution for handling
   applied configuration state in YANG as described in draft-openconfig-
   netmod-opstate-01.  The proposed solution, roughly modelled on the
   with-defaults NETCONF/RESTCONF capability, aims to meet the key
   requirements set out in draft-openconfig-netmod-opstate-01 without
   the need for YANG module authors to explicitly duplicate
   configuration nodes in both configuration and operational containers.
   This draft does not address the issue of co-location of configuration
   and operational state for interfaces, nor does it provide a NETCONF
   mechanism to retrieve operational data separately from configuration
   data.

                                                                                  


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.

The IETF Secretariat



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



--------------060708040909060104030809-- From nobody Fri Sep 4 03:33:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BDF1A8F4D; Fri, 4 Sep 2015 03:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jjgxq6Fum2U; Fri, 4 Sep 2015 03:33:30 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE18E1A896B; Fri, 4 Sep 2015 03:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4546; q=dns/txt; s=iport; t=1441362810; x=1442572410; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Op0zEh8FR+WEix0OyL+uXnoPQY9mjRkKvP85M5hs1kQ=; b=kY4Ao/zUZOlDO+mEwVRmsuuFSF4en5XxHNmL00Gsa+PCMh/f9tFzj9vE gR95XVK2eTM02K+flIL9nTOcz9/NRIVT9LFJWbOWEWP3BPmZiHMqifYh9 r9FLE2utDyNsFxsthTWYAL/3/bxuA2oPuWFRwnWX4t/P3eK0e9Z2K58em k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGAgDDculV/xbLJq1TCoN1aaVVmAABCYFtDIUvSgKBchQBAQEBAQEBgQqEIwEBAQMBAQEBNTYJARELEQMBAgEJFg8JAwIBAgEVKAgGAQwGAgEBF4gLCA3KUAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R7hC5kBoQmAQSMd4hahQeHcIFKRoNsgnyReCaCQoE/PTMBiUoBAQE X-IronPort-AV: E=Sophos;i="5.17,468,1437436800"; d="scan'208";a="611384340" 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; 04 Sep 2015 10:33:27 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t84AXRFn017253; Fri, 4 Sep 2015 10:33:27 GMT To: "netmod@ietf.org" , draft-openconfig-netmod-opstate@ietf.org References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> <20150904073832.GB32036@elstar.local> From: Robert Wilton Message-ID: <55E97377.3060008@cisco.com> Date: Fri, 4 Sep 2015 11:33:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150904073832.GB32036@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 10:33:32 -0000 Hi Juergen, Thanks for the review and comments. Yes, when I originally thought of this idea I intended using XML attributes, but after discussion with a couple of colleagues, we saw a couple of issue with using them: 1) One of the desired requirements in draft-openconfig-netmod-opstate-01 (section 4.5 last paragraph) is to have a unique path to identify the intended cfg node vs the applied cfg node. I couldn't see how this could be solved with attributes. I'm also not sure whether the separate applied config data store solves this problem, although presumably a NMS could store all paths as a (datastore, path) pairing. 2) I wanted to be able to represent config nodes for configuration that are in the process of being deleted (i.e. applied but not intended), and wasn't convinced that this could be achieved cleanly using attributes. 3) There doesn't seem to be any standard encoding for attributes in JSON ... although of course this doesn't prevent attributes from being used in XML based encodings. Thanks, Rob On 04/09/2015 08:38, Juergen Schoenwaelder wrote: > Hm. Adding a parameter to get-config() that changes the encoding of > data very fundamentally is somehow difficult to fall in love with. > > If you would have used meta-data, things would likely easier to like, > e.g., instead of > > > 9000 > waiting > Linecard 1 is not available > > > using something like this > > > 9000 > > > would have made more sense to me from an encoding point of view. There > might be issues with carrying actual config values in metadata in XML, > I guess I like the actual datastore approach still a bit more (but > perhaps having standard meta-data annotations providing additional > information might actually be useful. > > /js > > On Thu, Sep 03, 2015 at 09:40:58PM +0100, Robert Wilton wrote: >> Hi, >> >> I've posted a new experimental draft, that proposes a potential >> different solution for handling applied configuration, for possible >> discussion at next week's interim meeting on opstate. >> >> Comments before hand are welcome. >> >> Thanks, >> Rob >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-wilton-netmod-opstate-yang-00.txt >> Date: Thu, 3 Sep 2015 13:31:00 -0700 >> From: internet-drafts@ietf.org >> To: Robert Wilton , Robert Wilton >> >> >> >> A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt >> has been successfully submitted by Robert Wilton and posted to the >> IETF repository. >> >> Name: draft-wilton-netmod-opstate-yang >> Revision: 00 >> Title: "With-config-state" Capability for NETCONF/RESTCONF >> Document date: 2015-09-03 >> Group: Individual Submission >> Pages: 22 >> URL: >> https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/ >> Htmlized: >> https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00 >> >> >> Abstract: >> This document proposes a possible alternative solution for handling >> applied configuration state in YANG as described in draft-openconfig- >> netmod-opstate-01. The proposed solution, roughly modelled on the >> with-defaults NETCONF/RESTCONF capability, aims to meet the key >> requirements set out in draft-openconfig-netmod-opstate-01 without >> the need for YANG module authors to explicitly duplicate >> configuration nodes in both configuration and operational containers. >> This draft does not address the issue of co-location of configuration >> and operational state for interfaces, nor does it provide a NETCONF >> mechanism to retrieve operational data separately from configuration >> data. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Sep 4 09:29:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB201B301D for ; Fri, 4 Sep 2015 09:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0o6cHk-Dpp0 for ; Fri, 4 Sep 2015 09:29:55 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 50BE41B2FE0 for ; Fri, 4 Sep 2015 09:29:55 -0700 (PDT) Received: by laeb10 with SMTP id b10so17230467lae.1 for ; Fri, 04 Sep 2015 09:29:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jFTRxTU1R6BOcPDrDscUtMduUa8s0TSW9dVMdkP4ZmY=; b=mcD6+LEQ1rusqZE/CFjy+8VRfNezYSPRUefWI6KPBDUl1zSRQshXfA39U1OuZinTnv mahVniJkdbNB5I2g3r9I2oMj+1scdZBOtPg2J1DaFt3l5KTMhRUhiHDA1J0lWtlkJQEU ZkakGXZJWnZuLUcdM1kc5/EK8NYRqfHpi4fHgM8juID2vt0dsoNVoKJvqyGyiFiu5W3Y u8uwIj1aZl1ShXVMMTNIUlJaMQ6ZNHWn9LTyskqV5p+z5eEZxHnHzbimQdVPThqLCHQD rq77v1/z1ilZfh+yCNQvSLKQaY/uqd4cKV7Ka1kUXkTx2YgrAatNdJNvZMhcAb3PFpdU DhlA== X-Gm-Message-State: ALoCoQlmCl/j2dwY65Iy4ISma2/9t8S5aCrXJWxwV/bs9NZwtUC6DKl4xpkNWYzBi2p/3LeoK4Tg MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr4465998laj.82.1441384193622; Fri, 04 Sep 2015 09:29:53 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 4 Sep 2015 09:29:53 -0700 (PDT) In-Reply-To: <20150901142936.GA60706@elstar.local> References: <20150901142936.GA60706@elstar.local> Date: Fri, 4 Sep 2015 09:29:53 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b5e4d89ad5051eee68a0 Archived-At: Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 16:29:57 -0000 --089e0158b5e4d89ad5051eee68a0 Content-Type: text/plain; charset=UTF-8 Hi, Is there a WEB page that lists all the upcoming virtual meetings? This would really help people remember without scanning lots of ietf-announce email. I have a issue request for next week. IMO the text for what an arbitrary "YANG tool" MUST, SHOULD, or MAY do with an extension-stmt is not clear and no consensus exists yet either. The specific use-case is the addition of an "ephemeral-stmt" as a sub-statement of the individual data-def-stmt types. I think Martin has suggested a solution that I want to expand and get into YANG 1.1. - A YANG tool MUST support the deviate-stmt and refine-stmt for external statements grouping shared-parms { // plain config parms w/ no ephemeral-stmt } container foo-config { uses shared-parms { refine parm1 { i2rs:ephemeral true; } refine parm3 { i2rs:ephemeral true; } } } I do not think the current ABNF and normative text supports external-stmts. A similar example can be made for an object not in a grouping, using "deviate add". However deviation-stmt is not allowed in any standard modules, so this is also a problem. IMO this is required to add new keywords to data nodes like 'ephemeral' or 'related-state'. Currently YANG 1.1 is not good enough to support the use of external statements in standards. Andy On Tue, Sep 1, 2015 at 7:29 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > attached are the minutes of the 2015-03-31 virtual interim meeting. > Please let me know if something needs fixing. > > You can find all the virtual interim meeting minutes next to the YANG > 1.1 issue list in the NETMOD WG subversion repository: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --089e0158b5e4d89ad5051eee68a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Is there a WEB page that lists all = the upcoming virtual meetings?
This would really help people reme= mber without scanning lots of ietf-announce
email.

=

I have a issue request for next week.
I= MO the text for what an arbitrary "YANG tool" MUST, SHOULD, or MA= Y
do with an extension-stmt is not clear and no consensus exists = yet either.

The specific use-case is the addition = of an "ephemeral-stmt" as a sub-statement
of the indivi= dual data-def-stmt types.

I think Martin has sugge= sted a solution that I want to expand and get into YANG 1.1.

=
=C2=A0 =C2=A0- A YANG tool MUST support the deviate-stmt and ref= ine-stmt for external statements

grouping shared-p= arms {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // =C2=A0plain config pa= rms w/ no ephemeral-stmt=C2=A0
}

=C2=A0 = container foo-config {
=C2=A0 =C2=A0 =C2=A0 uses shared-parms {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 refine parm1 {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs:ephemeral true;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 refine parm3 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0i2rs:ephemeral true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 }
= =C2=A0=C2=A0

I do not think the current ABNF and n= ormative text supports external-stmts.
A similar example can be m= ade for an object not in a grouping, using "deviate add".
However deviation-stmt is not allowed in any standard modules, so this
is also a problem.

IMO this is required t= o add new keywords to data nodes like 'ephemeral'
or '= ;related-state'. Currently YANG 1.1 is not good enough to support
=
the use of external statements in standards.

=
Andy

On Tue, Sep 1, 2015 at 7:29 AM, Juergen Schoen= waelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

attached are the minutes of the 2015-03-31 virtual interim meeting.
Please let me know if something needs fixing.

You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:

=C2=A0 =C2=A0 =C2=A0http://svn.tools.ietf.org/svn/w= g/netmod/yang-1.1/

/js

--
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/>

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


--089e0158b5e4d89ad5051eee68a0-- From nobody Fri Sep 4 09:55:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9E41B4753 for ; Fri, 4 Sep 2015 09:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSs9z_C9hXNy for ; Fri, 4 Sep 2015 09:55:06 -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 253B81B474C for ; Fri, 4 Sep 2015 09:55:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E3A4712AC; Fri, 4 Sep 2015 18:55:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yJcAYGN8K3z3; Fri, 4 Sep 2015 18:55:04 +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; Fri, 4 Sep 2015 18:55:04 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DAD720048; Fri, 4 Sep 2015 18:55:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dV0SXErffY2I; Fri, 4 Sep 2015 18:55:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20B6420053; Fri, 4 Sep 2015 18:55:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F24E936F5EBF; Fri, 4 Sep 2015 18:54:58 +0200 (CEST) Date: Fri, 4 Sep 2015 18:54:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150904165458.GB33792@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150901142936.GA60706@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 16:55:08 -0000 On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote: > Hi, > > Is there a WEB page that lists all the upcoming virtual meetings? > This would really help people remember without scanning lots of > ietf-announce email. > The official list of interim meetings is here: https://www.ietf.org/meeting/interim.html Yes, you have to search for NETMOD and no I am not aware of a nicer list directly linked to say the NETMOD WG pages (or even a calendar file). /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 Fri Sep 4 11:21:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7751ACCE9; Fri, 4 Sep 2015 11:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJeTxux7ecoo; Fri, 4 Sep 2015 11:21:04 -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 282AE1A1A60; Fri, 4 Sep 2015 11:21:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E5DE11352; Fri, 4 Sep 2015 20:21:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7aJewldYOE0T; Fri, 4 Sep 2015 20:21:01 +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; Fri, 4 Sep 2015 20:21:01 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 278522004E; Fri, 4 Sep 2015 20:21:01 +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 ai_brf5KvOVg; Fri, 4 Sep 2015 20:21:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96B0320048; Fri, 4 Sep 2015 20:20:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 13ED236F5FE4; Fri, 4 Sep 2015 20:20:57 +0200 (CEST) Date: Fri, 4 Sep 2015 20:20:57 +0200 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20150904182057.GB34053@elstar.local> Mail-Followup-To: Robert Wilton , "netmod@ietf.org" , draft-openconfig-netmod-opstate@ietf.org References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> <20150904073832.GB32036@elstar.local> <55E97377.3060008@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E97377.3060008@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 18:21:06 -0000 On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wilton wrote: > Hi Juergen, > > Thanks for the review and comments. > > Yes, when I originally thought of this idea I intended using XML > attributes, but after discussion with a couple of colleagues, we saw a > couple of issue with using them: > > 1) One of the desired requirements in draft-openconfig-netmod-opstate-01 > (section 4.5 last paragraph) is to have a unique path to identify the > intended cfg node vs the applied cfg node. I couldn't see how this > could be solved with attributes. I'm also not sure whether the separate > applied config data store solves this problem, although presumably a NMS > could store all paths as a (datastore, path) pairing. Yep, I do not agree with this requirement. Datastores are an architectural concept in both NETCONF and YANG and hence an NMS needs to understand what a datastore is. > 2) I wanted to be able to represent config nodes for configuration that > are in the process of being deleted (i.e. applied but not intended), and > wasn't convinced that this could be achieved cleanly using attributes. Yep. This may require some careful design. > 3) There doesn't seem to be any standard encoding for attributes in JSON > ... although of course this doesn't prevent attributes from being used > in XML based encodings. See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed JSON encoding. /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 Fri Sep 4 15:35:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170F01B35AD for ; Fri, 4 Sep 2015 15:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVEuVGgjBtn8 for ; Fri, 4 Sep 2015 15:35:16 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 9CEBE1B35A2 for ; Fri, 4 Sep 2015 15:35:15 -0700 (PDT) Received: by lbcjc2 with SMTP id jc2so18409987lbc.0 for ; Fri, 04 Sep 2015 15:35:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=EHrrmCosDYinwC88Gp3DDjcDNCwBNjfVHcqMp27z9T8=; b=S8CxBrp1Qc9acD5IQdqlCZ/Edgd1W0LfNBSy4/uzspvwec8b5KZFP6NEFvpa9PWIR6 KjJUTcCNFLuWTUu1hvPZiK+WQGSBsyZ2WXIYmvEpHzi0l4/TPOW0ICELUe4cHi4J1UX9 P5X5Auxu2NOFDtLxTpDalwfg53sT61BalJXB0b8G/WD3K/nt+dQTLmY71TO8DrZvGgk+ 5qw01mYS2eCPgbtK/4X6lUux4pRDaphTdrMwwxNDA5KEsgtOi+A/uQ2eR4kNUDl5l6Md if+o7dwQTcIa+b8bKSBDwu51J/I3FkGNvFy16RxjdwJc6OugyMTfSnXFK5F1u9hKNZqx vBrA== X-Gm-Message-State: ALoCoQkyQGrLbHlaNMoKL6L827FyFLeAlIQdknF/8XaSE9/1zb6jPjDCN4WTdM907Hp4FQRCKcwk MIME-Version: 1.0 X-Received: by 10.112.157.68 with SMTP id wk4mr5701595lbb.119.1441406113825; Fri, 04 Sep 2015 15:35:13 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 4 Sep 2015 15:35:13 -0700 (PDT) In-Reply-To: <20150904182057.GB34053@elstar.local> References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> <20150904073832.GB32036@elstar.local> <55E97377.3060008@cisco.com> <20150904182057.GB34053@elstar.local> Date: Fri, 4 Sep 2015 15:35:13 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Robert Wilton , "netmod@ietf.org" , draft-openconfig-netmod-opstate@ietf.org Content-Type: multipart/alternative; boundary=001a11c2ae0e645f18051ef383e6 Archived-At: Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 22:35:18 -0000 --001a11c2ae0e645f18051ef383e6 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 4, 2015 at 11:20 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wilton wrote: > > Hi Juergen, > > > > Thanks for the review and comments. > > > > Yes, when I originally thought of this idea I intended using XML > > attributes, but after discussion with a couple of colleagues, we saw a > > couple of issue with using them: > > > > 1) One of the desired requirements in draft-openconfig-netmod-opstate-01 > > (section 4.5 last paragraph) is to have a unique path to identify the > > intended cfg node vs the applied cfg node. I couldn't see how this > > could be solved with attributes. I'm also not sure whether the separate > > applied config data store solves this problem, although presumably a NMS > > could store all paths as a (datastore, path) pairing. > > Yep, I do not agree with this requirement. Datastores are an > architectural concept in both NETCONF and YANG and hence an NMS needs > to understand what a datastore is. > > +1 IMO is is extremely important that the instance-identifier for a data node be exactly the same in each datastore. This is much easier to manage than if the data is named differently, depending whether it is intended or actual. > 2) I wanted to be able to represent config nodes for configuration that > > are in the process of being deleted (i.e. applied but not intended), and > > wasn't convinced that this could be achieved cleanly using attributes. > > Yep. This may require some careful design. > > The same careful design is needed for pub/sub to identify deleted nodes in the delta. > > 3) There doesn't seem to be any standard encoding for attributes in JSON > > ... although of course this doesn't prevent attributes from being used > > in XML based encodings. > > See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed > JSON encoding. > > We have already implemented this draft, so if there are any problems that require changes, it would be good to know about it ASAP > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2ae0e645f18051ef383e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 4, 2015 at 11:20 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wil= ton wrote:
> Hi Juergen,
>
> Thanks for the review and comments.
>
> Yes, when I originally thought of this idea I intended using XML
> attributes, but after discussion with a couple of colleagues, we saw a=
> couple of issue with using them:
>
> 1) One of the desired requirements in draft-openconfig-netmod-opstate-= 01
> (section 4.5 last paragraph) is to have a unique path to identify the<= br> > intended cfg node vs the applied cfg node.=C2=A0 I couldn't see ho= w this
> could be solved with attributes.=C2=A0 I'm also not sure whether t= he separate
> applied config data store solves this problem, although presumably a N= MS
> could store all paths as a (datastore, path) pairing.

Yep, I do not agree with this requirement. Datastores are an
architectural concept in both NETCONF and YANG and hence an NMS needs
to understand what a datastore is.


+1

IMO is is = extremely important that the instance-identifier =C2=A0for a data node be
exactly the same in each datastore.=C2=A0 This is much easier to m= anage
than if the data is named differently, depending whether it= is
intended or actual.


<= br>
> 2) I wanted to be able to represent config nodes for configuration tha= t
> are in the process of being deleted (i.e. applied but not intended), a= nd
> wasn't convinced that this could be achieved cleanly using attribu= tes.

Yep. This may require some careful design.



The same careful design= is needed for pub/sub to identify deleted nodes
in the delta.

=C2=A0
> 3) There doesn't seem to be any standard encoding for attributes i= n JSON
> ... although of course this doesn't prevent attributes from being = used
> in XML based encodings.

See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed
JSON encoding.


We have already implemented this draft, so if there = are any problems
that require changes, it would be good to know a= bout it ASAP

=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/>

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

--001a11c2ae0e645f18051ef383e6-- From nobody Mon Sep 7 00:31:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148EE1B2C6F for ; Mon, 7 Sep 2015 00:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVnJo9-pD7hD for ; Mon, 7 Sep 2015 00:31:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 028811A1BEE for ; Mon, 7 Sep 2015 00:31:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id B4E751AE019A; Mon, 7 Sep 2015 09:31:27 +0200 (CEST) Date: Mon, 07 Sep 2015 09:31:27 +0200 (CEST) Message-Id: <20150907.093127.2206391057777456319.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150904165458.GB33792@elstar.local> References: <20150901142936.GA60706@elstar.local> <20150904165458.GB33792@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 07:31:32 -0000 Juergen Schoenwaelder wrote: > On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote: > > Hi, > > > > Is there a WEB page that lists all the upcoming virtual meetings? > > This would really help people remember without scanning lots of > > ietf-announce email. > > > > The official list of interim meetings is here: > > https://www.ietf.org/meeting/interim.html > > Yes, you have to search for NETMOD and no I am not aware of a nicer > list directly linked to say the NETMOD WG pages (or even a calendar > file). Hmm, I thought we're having a virtual interim on the opstate issue this thursday (2015-09-10), but it is not listed here. Maybe I missed something. Can the chairs clarify this? /martin From nobody Mon Sep 7 01:29:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0161A8838 for ; Mon, 7 Sep 2015 01:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q34qiuCRhFLY for ; Mon, 7 Sep 2015 01:29:19 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E624F1A1B3D for ; Mon, 7 Sep 2015 01:29:18 -0700 (PDT) Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id EDCE41AE019A; Mon, 7 Sep 2015 10:29:16 +0200 (CEST) Date: Mon, 07 Sep 2015 10:29:15 +0200 (CEST) Message-Id: <20150907.102915.1335619056987586585.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150901142936.GA60706@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 08:29:21 -0000 Hi, Andy Bierman wrote: > I have a issue request for next week. > IMO the text for what an arbitrary "YANG tool" MUST, SHOULD, or MAY > do with an extension-stmt is not clear and no consensus exists yet either. > > The specific use-case is the addition of an "ephemeral-stmt" as a > sub-statement > of the individual data-def-stmt types. > > I think Martin has suggested a solution that I want to expand and get into > YANG 1.1. > > - A YANG tool MUST support the deviate-stmt and refine-stmt for external > statements > > grouping shared-parms { > // plain config parms w/ no ephemeral-stmt > } > > container foo-config { > uses shared-parms { > refine parm1 { > i2rs:ephemeral true; > } > refine parm3 { > i2rs:ephemeral true; > } > } > } > > > I do not think the current ABNF and normative text supports external-stmts. I think the grammar is ok, but I agree normative text is missing. The grammar allows the example with refine i2rs:ephemeral true above. In our data models, we explicitly specify if an external statement is supported in 'refine' or not. [side node: we do this with a statement like this: extension actionpoint { ... tailf:use-in "rpc"; tailf:use-in "tailf:action"; tailf:use-in "refine"; tailf:substatement "tailf:opaque"; ... } ] > A similar example can be made for an object not in a grouping, using > "deviate add". I don't understand. Can you examplify? > However deviation-stmt is not allowed in any standard modules, so this > is also a problem. > > IMO this is required to add new keywords to data nodes like 'ephemeral' > or 'related-state'. Currently YANG 1.1 is not good enough to support > the use of external statements in standards. /martin From nobody Mon Sep 7 01:36:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39D1B2B1D; Mon, 7 Sep 2015 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX4JANRLTlvD; Mon, 7 Sep 2015 01:36:11 -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 D34DB1B2B4A; Mon, 7 Sep 2015 01:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12411; q=dns/txt; s=iport; t=1441614971; x=1442824571; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=JkaeGxFHv8Sl6c9PTaDHd6qpihiQP8YfEDONPn+z4+Q=; b=J2Q731l5Tx7ZPr1dbIG6NR5JNTo64gpF8GKXOgxuqu9tthVvGU+9kzye PmKxojxJjko0VFJX5SRNkHTve/wu7HzlGkozG4ZF1JCMLiscNySnEc7pn jWel2Ej9PyhrPSLqR9T8zfaunGFh+xM7HyJkH4qK2y6CQvAvE0w6DL0vs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DhBACaS+1V/xbLJq1UBwODd2mDJLwwAQmFL0oCgXMBAQEBAQGBC4QjAQEBAwEBAQEgSwYDAQEFCQIJAhAICRYIAwICCQMCAQIBCQwfEQYNBgIBAReICwgNlzadHZQDAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSGb4R7hC9NEAcSgleBQwWSMoMjjHqBTIcvI5FZJoJCgT89M4hJAQEB X-IronPort-AV: E=Sophos;i="5.17,484,1437436800"; d="scan'208,217";a="604953743" 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; 07 Sep 2015 08:36:08 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t878a8Ao021930; Mon, 7 Sep 2015 08:36:08 GMT To: Andy Bierman References: <20150903203100.16360.24076.idtracker@ietfa.amsl.com> <55E8B05A.3090903@cisco.com> <20150904073832.GB32036@elstar.local> <55E97377.3060008@cisco.com> <20150904182057.GB34053@elstar.local> From: Robert Wilton Message-ID: <55ED4C76.6060408@cisco.com> Date: Mon, 7 Sep 2015 09:36:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050105030501000309070800" Archived-At: Cc: draft-openconfig-netmod-opstate@ietf.org, "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-wilton-netmod-opstate-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 08:36:15 -0000 This is a multi-part message in MIME format. --------------050105030501000309070800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 04/09/2015 23:35, Andy Bierman wrote: > > > On Fri, Sep 4, 2015 at 11:20 AM, Juergen Schoenwaelder > > wrote: > > On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wilton wrote: > > Hi Juergen, > > > > Thanks for the review and comments. > > > > Yes, when I originally thought of this idea I intended using XML > > attributes, but after discussion with a couple of colleagues, we > saw a > > couple of issue with using them: > > > > 1) One of the desired requirements in > draft-openconfig-netmod-opstate-01 > > (section 4.5 last paragraph) is to have a unique path to > identify the > > intended cfg node vs the applied cfg node. I couldn't see how this > > could be solved with attributes. I'm also not sure whether the > separate > > applied config data store solves this problem, although > presumably a NMS > > could store all paths as a (datastore, path) pairing. > > Yep, I do not agree with this requirement. Datastores are an > architectural concept in both NETCONF and YANG and hence an NMS needs > to understand what a datastore is. > > > +1 > > IMO is is extremely important that the instance-identifier for a data > node be > exactly the same in each datastore. This is much easier to manage If datastores are the right solution for intended vs actual, then I completely agree that they should have the same path in both. > than if the data is named differently, depending whether it is > intended or actual. > > > > > 2) I wanted to be able to represent config nodes for > configuration that > > are in the process of being deleted (i.e. applied but not > intended), and > > wasn't convinced that this could be achieved cleanly using > attributes. > > Yep. This may require some careful design. > > > > The same careful design is needed for pub/sub to identify deleted nodes > in the delta. OOI, has any one proposed how this should be done yet, or is pub/sub not at that stage yet? > > > 3) There doesn't seem to be any standard encoding for attributes > in JSON > > ... although of course this doesn't prevent attributes from > being used > > in XML based encodings. > > See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed > JSON encoding. > > > We have already implemented this draft, so if there are any problems > that require changes, it would be good to know about it ASAP I just wasn't aware of this draft. I'll give it a read. In particular, I was reading ietf-netconf-restconf-06, section 4.8.9 on with-defaults, particularly the report-all-tagged option. I think that it might be helpful if the description of the "report-all-tagged" description also had a reference to draft-ietf-netmod-yang-metadata (or alternatively section 5.4) for the JSON encoding of the "default" attribute. Thanks, Rob > > /js > > > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --------------050105030501000309070800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 04/09/2015 23:35, Andy Bierman wrote:


On Fri, Sep 4, 2015 at 11:20 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wilton wrote:
> Hi Juergen,
>
> Thanks for the review and comments.
>
> Yes, when I originally thought of this idea I intended using XML
> attributes, but after discussion with a couple of colleagues, we saw a
> couple of issue with using them:
>
> 1) One of the desired requirements in draft-openconfig-netmod-opstate-01
> (section 4.5 last paragraph) is to have a unique path to identify the
> intended cfg node vs the applied cfg node.  I couldn't see how this
> could be solved with attributes.  I'm also not sure whether the separate
> applied config data store solves this problem, although presumably a NMS
> could store all paths as a (datastore, path) pairing.

Yep, I do not agree with this requirement. Datastores are an
architectural concept in both NETCONF and YANG and hence an NMS needs
to understand what a datastore is.


+1

IMO is is extremely important that the instance-identifier  for a data node be
exactly the same in each datastore.  This is much easier to manage

If datastores are the right solution for intended vs actual, then I completely agree that they should have the same path in both.


than if the data is named differently, depending whether it is
intended or actual.



> 2) I wanted to be able to represent config nodes for configuration that
> are in the process of being deleted (i.e. applied but not intended), and
> wasn't convinced that this could be achieved cleanly using attributes.

Yep. This may require some careful design.



The same careful design is needed for pub/sub to identify deleted nodes
in the delta.
OOI, has any one proposed how this should be done yet, or is pub/sub not at that stage yet?


 
> 3) There doesn't seem to be any standard encoding for attributes in JSON
> ... although of course this doesn't prevent attributes from being used
> in XML based encodings.

See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed
JSON encoding.


We have already implemented this draft, so if there are any problems
that require changes, it would be good to know about it ASAP
I just wasn't aware of this draft.  I'll give it a read.

In particular, I was reading ietf-netconf-restconf-06, section 4.8.9 on with-defaults, particularly the report-all-tagged option.  I think that it might be helpful if the description of the "report-all-tagged" description also had a reference to draft-ietf-netmod-yang-metadata (or alternatively section 5.4) for the JSON encoding of the "default" attribute.

Thanks,
Rob



 
/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/>

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


--------------050105030501000309070800-- From nobody Mon Sep 7 03:05:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54D01B4990 for ; Mon, 7 Sep 2015 03:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FssX9LzBIa2C for ; Mon, 7 Sep 2015 03:05:36 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2271D1B4987 for ; Mon, 7 Sep 2015 03:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8659; q=dns/txt; s=iport; t=1441620335; x=1442829935; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FlupGTVzDNZ88y5HVOA3+xiJOIntzntsE6fQ2aw5/kE=; b=SmAzdJ7noQ2etCrTa2qYr7sm52zbxBKKMOPKXeXLd5nWMvl3yXvb3OjX ZIIcbFI7WESN9KLdg6bUegaRabReawEBSV0L+b/I4f0O0ZGmwk5qMvnOv k8fgZCRcFoCX/0pi+lN6tBa3x4eQuSsXevRYdrqvez+127vHvBL5aTWrV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBAB+YO1V/xbLJq1eglaBIWm/YoV3AoFkEQEBAQEBAQGBCoQkAQEEeAEQCxgJFg8JAwIBAgFFBg0GAgEBiCoNyHsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhHuFDAeELAWVVYUKh3CBTIcvjhCDbCaEAT0zAYhIAQEB X-IronPort-AV: E=Sophos;i="5.17,484,1437436800"; d="scan'208,217";a="611438284" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 07 Sep 2015 10:05:32 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t87A5VVM025194; Mon, 7 Sep 2015 10:05:31 GMT To: Ladislav Lhotka References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <20150825.140102.2117420320519166894.mbj@tail-f.com> From: Robert Wilton Message-ID: <55ED6168.2070307@cisco.com> Date: Mon, 7 Sep 2015 11:05:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000605030909040804050401" Archived-At: Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 10:05:37 -0000 This is a multi-part message in MIME format. --------------000605030909040804050401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Lada, I've just take a quick look at your DNS model referenced below. For your containers under the choice rdata-content you have used must statements to enforce the constraint. E.g. ... |choice rdata-content { mandatory "true";| ... |container A { must "../../type = 'ianadns:A'";| I was wondering what the reason was that you choose to use must statements rather than equivalent when statements? The reason that I'm asking is that I had used when statements for a similar construct that I had used for VLANs encapsulation, and I guess I would normally choose a when statement out of preference over a must statement, hence the desire to understand the rationale for the alternative. Thanks, Rob On 26/08/2015 09:28, Ladislav Lhotka wrote: > Hi, > > I changed the DNS zone data model to use this pattern - it looks > good and works great: > > - module: > https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang > > - tree: > https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree > > Lada > > Martin Bjorklund writes: > >> Hi, >> >> I think this could work (thanks Robert; maybe this is what you >> meant!): >> >> container zones { >> list zone { >> ... >> list rrset { >> ... >> leaf type { >> type identityref { ... } >> } >> list rdata { >> key id; >> ... >> choice type-specific-params { >> mandatory true; >> // to be augmented with type-specific nodes >> } >> } >> } >> } >> } >> >> And then in another module: >> >> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" >> + "/type-specific-parameters" { >> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >> + "'TLSA')"; >> >> leaf certificate-usage { >> mandatory true; >> ... >> } >> } >> >> The empty mandatory choice formally tells the client that additional >> cases are expected. >> >> (If the empty choice looks fishy, it is probably often possible to >> define at least one case inline...) >> >> This pattern is nice to the client, since there is no way an >> additional augmenting module can break a working client. >> >> >> /martin >> --------------000605030909040804050401 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Lada,

I've just take a quick look at your DNS model referenced below. For your containers under the choice rdata-content you have used must statements to enforce the constraint.

E.g.

...
          choice rdata-content {
            mandatory "true";
...
            container A {
              must "../../type = 'ianadns:A'";


I was wondering what the reason was that you choose to use must statements rather than equivalent when statements?

The reason that I'm asking is that I had used when statements for a similar construct that I had used for VLANs encapsulation, and I guess I would normally choose a when statement out of preference over a must statement, hence the desire to understand the rationale for the alternative.

Thanks,
Rob


On 26/08/2015 09:28, Ladislav Lhotka wrote:
Hi,

I changed the DNS zone data model to use this pattern - it looks
good and works great:

- module:
  https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang
  
- tree:
  https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree

Lada

Martin Bjorklund <mbj@tail-f.com> writes:


Hi,

I think this could work (thanks Robert; maybe this is what you
meant!):

  container zones {
    list zone {
      ...
      list rrset {
        ...
        leaf type {
          type identityref { ... }
        }
        list rdata {
          key id;
          ...
          choice type-specific-params {
            mandatory true;
            // to be augmented with type-specific nodes
          }
        }
      }
    }
  }

And then in another module:

  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
        + "/type-specific-parameters" {
    when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
       + "'TLSA')";

    leaf certificate-usage {
      mandatory true;
      ...
    }
  }

The empty mandatory choice formally tells the client that additional
cases are expected.

(If the empty choice looks fishy, it is probably often possible to
define at least one case inline...)

This pattern is nice to the client, since there is no way an
additional augmenting module can break a working client.


/martin



    

    

  


--------------000605030909040804050401--


From nobody Mon Sep  7 03:53:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E112C1B366B for ; Mon,  7 Sep 2015 03:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPYAHhhFr-lo for ; Mon,  7 Sep 2015 03:52:58 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9071AD074 for ; Mon,  7 Sep 2015 03:52:57 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 6F2FC181A2C; Mon,  7 Sep 2015 12:52:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441623176; bh=dGFcnf1sdrVy6JL7TknH0QnS5ggXYMVMjGJTZdF/ne0=; h=From:Date:To; b=dUoxfZILwbRWxlHdKsDyd0vDOTCp5HG2PbQ/yqqkZvyHNfpr0m5XoTcBsujgWDgWm nBwP6IxyL5aZxI2C9KCyPPQXpovY7J02ig5OrJ6FZ9KJlKxAAsad2iYciHfBGMBKsT UqewEOa9i5i0iDN0g9BgZWD0V/fo4u9iZzNeWWNU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <55ED6168.2070307@cisco.com>
Date: Mon, 7 Sep 2015 12:52:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <845A02C2-136B-41D1-ABDE-7092E35FBF7C@nic.cz>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>  <20150825.140102.2117420320519166894.mbj@tail-f.com>  <55ED6168.2070307@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 10:53:00 -0000

Hi Rob,

I generally prefer must to when, except in augments, because it is IMO a =
much cleaner concept that also has analogies in standard XML schema =
languages. When manipulates the schema based on arbitrary values in an =
instance document (that is supposed to be validated with the schema), =
and because of that it requires extra rules and sometimes even temporary =
manipulation with the instance document to work correctly, see

=
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.5=


In contrast, must expressions are evaluated in the context of an =
instance document and there are no concerns about circular references, =
order of evaluation etc.

Lada

> On 07 Sep 2015, at 12:05, Robert Wilton  wrote:
>=20
> Hi Lada,
>=20
> I've just take a quick look at your DNS model referenced below.  For =
your containers under the choice rdata-content you have used must     =
statements to enforce the constraint.
>=20
> E.g.
>=20
> ...
>           choice rdata-content {
>             mandatory "true";
> ...
>             container A {
>               must "../../type =3D 'ianadns:A'";
>=20
>=20
> I was wondering what the reason was that you choose to use must =
statements rather than equivalent when statements?
>=20
> The reason that I'm asking is that I had used when statements for a =
similar construct that I had used for VLANs encapsulation, and I guess I =
would normally choose a when statement out of preference over a must =
statement, hence the desire to understand the rationale for the =
alternative.
>=20
> Thanks,
> Rob
> =20
>=20
> On 26/08/2015 09:28, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> I changed the DNS zone data model to use this pattern - it looks
>> good and works great:
>>=20
>> - module:
>>  =20
>> =
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.ya=
ng
>>=20
>>  =20
>> - tree:
>>  =20
>> =
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree
>>=20
>>=20
>> Lada
>>=20
>> Martin Bjorklund=20
>> 
>>  writes:
>>=20
>>=20
>>> Hi,
>>>=20
>>> I think this could work (thanks Robert; maybe this is what you
>>> meant!):
>>>=20
>>>   container zones {
>>>     list zone {
>>>       ...
>>>       list rrset {
>>>         ...
>>>         leaf type {
>>>           type identityref { ... }
>>>         }
>>>         list rdata {
>>>           key id;
>>>           ...
>>>           choice type-specific-params {
>>>             mandatory true;
>>>             // to be augmented with type-specific nodes
>>>           }
>>>         }
>>>       }
>>>     }
>>>   }
>>>=20
>>> And then in another module:
>>>=20
>>>   augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
>>>         + "/type-specific-parameters" {
>>>     when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>>>        + "'TLSA')";
>>>=20
>>>     leaf certificate-usage {
>>>       mandatory true;
>>>       ...
>>>     }
>>>   }
>>>=20
>>> The empty mandatory choice formally tells the client that additional
>>> cases are expected.
>>>=20
>>> (If the empty choice looks fishy, it is probably often possible to
>>> define at least one case inline...)
>>>=20
>>> This pattern is nice to the client, since there is no way an
>>> additional augmenting module can break a working client.
>>>=20
>>>=20
>>> /martin
>>>=20
>>>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Sep  7 03:59:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9E21B4D56 for ; Mon,  7 Sep 2015 03:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prYnGFBMWozX for ; Mon,  7 Sep 2015 03:59:25 -0700 (PDT)
Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F311B4D7E for ; Mon,  7 Sep 2015 03:59:25 -0700 (PDT)
Received: from jva2tc105.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-4.webex.com [64.68.121.239]) by sjmda10.webex.com (Postfix) with ESMTP id 584133A49 for ; Mon,  7 Sep 2015 10:59:25 +0000 (GMT)
Received: from jva2tc105.webex.com (localhost [127.0.0.1]) by jva2tc105.webex.com (Postfix) with ESMTP id 10803BFA40 for ; Mon,  7 Sep 2015 10:59:25 +0000 (GMT)
Date: Mon, 7 Sep 2015 10:59:25 +0000 (GMT)
From: NETMOD Working Group 
To: netmod@ietf.org
Message-ID: <1042906863.950.1441623565065.JavaMail.nobody@jva2tc105.webex.com>
MIME-Version: 1.0
Content-Type: multipart/Mixed;  boundary="----=_Part_948_1276235946.1441623565064"
X-Priority: 3
Importance: normal
Archived-At: 
Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: netmod-chairs@tools.ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 10:59:28 -0000

------=_Part_948_1276235946.1441623565064
Content-Type: multipart/Alternative; 
	boundary="----=_Part_949_630878186.1441623565064"

------=_Part_949_630878186.1441623565064
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: base64

CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl
YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCk1vbmRheSwgU2VwdGVtYmVyIDcsIDIwMTUK
NTowMCBwbSAgfCAgRXVyb3BlIFN1bW1lciBUaW1lIChCZXJsaW4sIEdNVCswMjowMCkgIHwgIDEg
aHIKCgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw
P01USUQ9bWZhMjM5ZjRkZDUxODhkY2ZhODNiOTE4YjJiNzYyOTgyCk1lZXRpbmcgbnVtYmVyOiA2
NDkgMjYwIDQ3MwpNZWV0aW5nIHBhc3N3b3JkOiBCaWVHaDRWaQoKDQpKT0lOIEJZIFBIT05FDQox
LTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUw
LTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0
OSAyNjAgNDczCgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApodHRwOi8vd3d3Lndl
YmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGlu
ZyB0byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ
RD1tMDdhODE4YjFkMjNkNTBkY2IyYWIzZDNkOTg4NWEyYTENCg0KCkNhbid0IGpvaW4gdGhlIG1l
ZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYv
bWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj
ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz
aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg
bWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2Vu
dCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNv
cmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4g
dGhlIHNlc3Npb24uCg==
------=_Part_949_630878186.1441623565064
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64

PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz
ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk
dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs
cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh
YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6
IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7
IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K
dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls
eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls
ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy
PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls
ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ
CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0
eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog
ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0
cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp
YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN
T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K
ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK
Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0
OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl
Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj
NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ
CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+TW9u
ZGF5LCBTZXB0ZW1iZXIgNywgMjAxNQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJ
PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+NTowMCBwbSZuYnNwOyZuYnNwO3wm
bmJzcDsmbmJzcDtFdXJvcGUgU3VtbWVyIFRpbWUgKEJlcmxpbiwgR01UKzAyOjAwKSZuYnNwOyZu
YnNwO3wmbmJzcDsmbmJzcDsxIGhyCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwv
dGFibGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0i
aGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9
IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8
dGQgc3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJCQkJCQk8YSBocmVm
PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZmEyMzlmNGRkNTE4OGRj
ZmE4M2I5MThiMmI3NjI5ODIiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7
Zm9udC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5Kb2luIFdlYkV4IG1l
ZXRpbmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJ
PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9y
dGFudCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZCBzdHlsZT0i
cGFkZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyOgoJCQkJCQkJCTwv
dGQ+CgkJCQkJCQkJPHRkPjY0OSAyNjAgNDczCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJ
CQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5n
IHBhc3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPkJpZUdoNFZpPC90ZD4KCQkJCQkJCTwvdHI+CgkJ
CQkJCTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48
dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRy
Pjx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3Ry
Pjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0Nh
bGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1h
cmdpbjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVt
YmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPkFjY2Vz
cyBjb2RlOiZuYnNwOzY0OSAyNjAgNDczPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+
PHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlv
bnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6
IzAwQUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90
YWJsZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxl
PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5
bGU9ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYv
ai5waHA/TVRJRD1tMDdhODE4YjFkMjNkNTBkY2IyYWIzZDNkOTg4NWEyYTEiIHN0eWxlPSJ0ZXh0
LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMg
bWVldGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0
ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz
cDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJm
b250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAg
ICAgQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndl
YmV4LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEz
cHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4K
ICAgICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4K
PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDox
MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJ
CQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJ
CQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2Ug
YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv
biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h
dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg
dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk
ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo
ZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJ
PC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4=
------=_Part_949_630878186.1441623565064--

------=_Part_948_1276235946.1441623565064
Content-Type: application/octet-stream;
	name="WebEx_Meeting.ics"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="WebEx_Meeting.ics"

QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg
MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP
TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw
MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G
RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6
U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF
UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx
MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM
SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q
QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049
Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y
ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDkwN1QxNzAwMDAKRFRFTkQ7VFpJRD0i
RXVyb3BlIFRpbWUiOjIwMTUwOTA3VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu
Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQxNjIzNTY0ClVJRDphODczMjAyNS1h
OTYwLTQyNTMtODA0OS03YmE4ZGRjYzhiYTYKRFRTVEFNUDoyMDE1MDkwN1QxNTAwMDBaCkRFU0NS
SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p
ZXRmL2oucGhwP01USUQ9bWNkNGY0MzUzOTE5Njg2ZGRmNGFiZWQ4YzdjOTQyZTFkXG5NZWV0aW5n
IG51bWJlcjogNjQ5IDI2MCA0NzNcbk1lZXRpbmcgcGFzc3dvcmQ6IEJpZUdoNFZpXG5cblxuSk9J
TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D
YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu
QWNjZXNzIGNvZGU6IDY0OSAyNjAgNDczXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u
czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu
XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw
czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug
bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y
bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg
YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv
biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk
byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp
dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU
WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP
TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl
eC5jb20vaWV0Zi9qLnBocD9NVElEPW1jZDRmNDM1MzkxOTY4NmRkZjRhYmVkOGM3Yzk0MmUxZCI+
PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l
ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ
WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U
PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg
RkFDRT0iYXJpYWwiPjY0OSAyNjAgNDczPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh
YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg
IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QmllR2g0Vmk8L0ZPTlQ+PC90ZD48L3RyPjwv
dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz
cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD
T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC
Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04
NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh
bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD
RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv
bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M
T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ5IDI2MCA0NzM8L0ZPTlQ+
Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz
dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs
Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv
Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG
QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo
dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw
QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+
Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q
T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz
IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi
ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g
Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj
aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp
c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz
aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB
U1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo=
------=_Part_948_1276235946.1441623565064--


From nobody Mon Sep  7 04:01:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A211B4DFD for ; Mon,  7 Sep 2015 04:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.259
X-Spam-Level: 
X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuPJP4k6tTO1 for ; Mon,  7 Sep 2015 04:01:45 -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 E59451B4DFA for ; Mon,  7 Sep 2015 04:01:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3D8C18DF; Mon,  7 Sep 2015 13:01:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qFlGkq14DxOe; Mon,  7 Sep 2015 13:01:42 +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; Mon,  7 Sep 2015 13:01:42 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98DA520053; Mon,  7 Sep 2015 13:01:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5RzaHK5Vt14X; Mon,  7 Sep 2015 13:01:41 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E98942004E; Mon,  7 Sep 2015 13:01:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 229253703D6E; Mon,  7 Sep 2015 13:01:35 +0200 (CEST)
Date: Mon, 7 Sep 2015 13:01:34 +0200
From: Juergen Schoenwaelder 
To: netmod-chairs@tools.ietf.org
Message-ID: <20150907110132.GA29605@elstar.local>
Mail-Followup-To: netmod-chairs@tools.ietf.org, netmod@ietf.org
References: <1042906863.950.1441623565065.JavaMail.nobody@jva2tc105.webex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1042906863.950.1441623565065.JavaMail.nobody@jva2tc105.webex.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 11:01:47 -0000

Hi,

we will use this etherpad to take notes:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-09-07?useMonospaceFont=true

/js

On Mon, Sep 07, 2015 at 10:59:25AM +0000, NETMOD Working Group wrote:
> 
> Hello,
> 
> NETMOD Working Group invites you to join this WebEx meeting.
> 
> 
> NETMOD YANG 1.1
> Monday, September 7, 2015
> 5:00 pm  |  Europe Summer Time (Berlin, GMT+02:00)  |  1 hr
> 
> 
> JOIN WEBEX MEETING
> https://ietf.webex.com/ietf/j.php?MTID=mfa239f4dd5188dcfa83b918b2b762982
> Meeting number: 649 260 473
> Meeting password: BieGh4Vi
> 
> 
> JOIN BY PHONE
> 1-877-668-4493 Call-in toll free number (US/Canada) 
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 649 260 473
> 
> Toll-free dialing restrictions: 
> http://www.webex.com/pdf/tollfree_restrictions.pdf
> 
> 
> Add this meeting to your calendar:
> https://ietf.webex.com/ietf/j.php?MTID=m07a818b1d23d50dcb2ab3d3d9885a2a1
> 
> 
> Can't join the meeting? Contact support here:
> https://ietf.webex.com/ietf/mc
> 
> 
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.


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


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep  7 04:40:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EAA1B4F95 for ; Mon,  7 Sep 2015 04:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bF_3hj2xT1G for ; Mon,  7 Sep 2015 04:40:39 -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 8E6521B4F92 for ; Mon,  7 Sep 2015 04:40: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 5570BFE2; Mon,  7 Sep 2015 13:40:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A6VzO9GdoTsY; Mon,  7 Sep 2015 13:40:37 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon,  7 Sep 2015 13:40:37 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67E4C20048; Mon,  7 Sep 2015 13:40:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XsZ_gn9DFbop; Mon,  7 Sep 2015 13:40:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C735B2004E; Mon,  7 Sep 2015 13:40:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 794D13703ED8; Mon,  7 Sep 2015 13:40:29 +0200 (CEST)
Date: Mon, 7 Sep 2015 13:40:29 +0200
From: Juergen Schoenwaelder 
To: Paul Borman 
Message-ID: <20150907114027.GD29605@elstar.local>
Mail-Followup-To: Paul Borman , Andy Bierman , "netmod@ietf.org" 
References:  <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] logical systems model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 11:40:41 -0000

On Wed, Sep 02, 2015 at 08:59:14AM -0700, Paul Borman wrote:
> It depends on if you want to be able to just use YANG for schemas, or if
> you want to force people to use another mechanism on top of YANG to make it
> flexible enough for complete schemas.
> 
> For example, an interfaces schema may end up with paths like (I am not
> using full prefixed YANG paths, so please don't be confused by that):
> 
> /interfaces/eth0/...
> 
> But, if you want to report everything about a device, you would probably
> want:
> 
> /device/interfaces/eth0/..
> /device/protocols/tcp/...
> 
> Now step back, you actually want to contain everything about all your
> devices:
> 
> /router1.me.com/interfaces/eth0/...
> /router2.me.com/interfaces/eth1/...

Instance identification does not really work by putting 'names' into
paths. Neither in NETCONF nor in RESTCONF. If your starting point is
based on wrong assumptions, then the conclusions may be wrong as well.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep  7 07:37:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB0A1B53AA for ; Mon,  7 Sep 2015 07:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYlECBZKHkOS for ; Mon,  7 Sep 2015 07:37:36 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E611B519F for ; Mon,  7 Sep 2015 07:37:36 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id DCAB11818A9; Mon,  7 Sep 2015 16:37:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441636654; bh=tff/CP3c1xjG8usCCDn23HF7+O0zvEiZS1mxQgTt1FY=; h=From:Date:To; b=brNu1TyxAzrr0HwbPQ99CNH7WuW85huJxEHqlBzzDvCYmE2and0ko23VuC/LeKH8j TK9+onOZPgqa7PU1cO1XB4jhYEHpObRSbmEMjNOcSh0CF72AHYO7j0AF2/GhVr5HIC +hpwuRpTvYz/GI2oi8wYKp9I6Re7dGrp4rJYREg8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150903.084621.2128646705679413229.mbj@tail-f.com>
Date: Mon, 7 Sep 2015 16:37:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <55E6F6D8.1060405@labn.net> <20150902.210313.942746255374334050.mbj@tail-f.com> <55E7593E.7020201@labn.net> <20150903.084621.2128646705679413229.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] logical systems model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 14:37:39 -0000

> On 03 Sep 2015, at 08:46, Martin Bjorklund  wrote:
>=20
> Lou Berger  wrote:
>> Martin,
>>=20
>> On 9/2/2015 3:03 PM, Martin Bjorklund wrote:
>>> If it was done with
>>> 'mount' instead of the proposed model in
>>> draft-rtgyangdt-rtgwg-device-model-00, it doesn't cost anything for
>>> the 99% (more?) of all systems that do not have this kind of logical
>>> systems, and data models would not have to augment the
>>> /device/logical-network-elements/logical-network-element path.
>>=20
>> This is a compelling point (at least to me).  Of course there's lots =
of
>> details to flush out to make this work, but seems like it's worth
>> exploring this approach in more detail.=20
>>=20
>> The initial set of issues I see were in an earlier e-mail:
>>=20
>> On 9/1/2015 9:45 AM, Lou Berger wrote:
>>> That said, there are some specifics that will need to be addressed =
to > use this approach: e.g. to quote: > Mounted data is "read-only" =
data.
>>> YANG-Mount does not extend towards RPCs that are defined as > part =
of
>> YANG modules whose contents is being mounted. > YANG-Mount does not
>> extend towards notifications. > Perhaps most of these limitations can =
be
>> relaxed for local mounts. > > Also handling when a device/server =
doesn't
>> support local mounts (or is > invalid) Lou
>=20
> If this is viewed as a way to incorporate the schema defined in
> another module, rather than tie it to run-time behavior, there is no
> need to make it read-only.

Right, this discussion is about an alternative method for assembling a =
schema from modular parts whereas the mount draft deals with mediating =
access to remote datastores, which is something very different.

Lada

>=20
> Further, with the addition of 'action' and inline notifications in
> YANG 1.1, we can make this handle RPCs and notifications at the
> top-level as well.  For example:
>=20
>  module system {
>    ...
>    rpc shutdown { ... }
>  }
>=20
>  module controller {
>    ...
>    list device {
>      key name;
>      leaf name { ... }
>      leaf addres { ... }
>=20
>      mount system;
>    }
>  }
>=20
> would behave similar (forgetting namespaces etc) to as if it was
> defined as:
>=20
>  module controller {
>    ...
>    list device {
>      key name;
>      leaf name { ... }
>      leaf addres { ... }
>=20
>      action shutdown { ... }
>    }
>  }
>=20
>=20
> Maybe we should try to find another term than 'mount',
> since it seems people think about the specific solution in
> draft-clemm-netmod-mount.  It might also be necessary to 'mount' parts
> of a module.
>=20
>=20
> /martin
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Sep  7 09:37:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EB91B486F for ; Mon,  7 Sep 2015 09:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X79I0br_jWRS for ; Mon,  7 Sep 2015 09:37:43 -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 CB1F71B5543 for ; Mon,  7 Sep 2015 09:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3979; q=dns/txt; s=iport; t=1441643862; x=1442853462; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Kkd/lJiYDwmlkRSrYe+6HUajLBlVlGNqsaBEh4Lf/VU=; b=EtR+b9LqK04MaJfLDNk7qQ/sk2pyFPsezBqlTIA4z6JSAXjLqM0q9njm aCEn3CtGNkXtANjcFYuJicezketvi0x995gvGGpS+3mKu3VnSHgeaiB2l uqe1OrNcUcgQfMcpKOQro0Jzvd/KwRiLHcI2HLjzCHoEJ2wNa2gT+bH+B 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcBAC6vO1V/xbLJq1dg3dpv2WFdwKBfAEBAQEBAYELhCQBAQQ4QAEQCxgJFg8JAwIBAgFFBg0GAgEBiCoNyQ8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhHuEQUsHhCwBBJIygyOFCoJthQOBTIcvjhCDbCaEAT0zAQGGfwIeBAOBIQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,485,1437436800"; d="scan'208";a="604963180"
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; 07 Sep 2015 16:37:40 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t87GbeFd022733; Mon, 7 Sep 2015 16:37:40 GMT
To: Ladislav Lhotka 
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>  <20150825.140102.2117420320519166894.mbj@tail-f.com>  <55ED6168.2070307@cisco.com> <845A02C2-136B-41D1-ABDE-7092E35FBF7C@nic.cz>
From: Robert Wilton 
Message-ID: <55EDBD56.4040801@cisco.com>
Date: Mon, 7 Sep 2015 17:37:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <845A02C2-136B-41D1-ABDE-7092E35FBF7C@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 16:37:46 -0000

Hi Lada,

Thanks for the explanation.

Initially I was concerned that there would be a higher server 
implementation cost of using a must statement over a when statement, but 
given that the container/leaves are under a choice statement then it 
seems that the must statement can presumably be implemented as 
efficiently as a when statement in this scenario.

Thanks,
Rob


On 07/09/2015 11:52, Ladislav Lhotka wrote:
> Hi Rob,
>
> I generally prefer must to when, except in augments, because it is IMO a much cleaner concept that also has analogies in standard XML schema languages. When manipulates the schema based on arbitrary values in an instance document (that is supposed to be validated with the schema), and because of that it requires extra rules and sometimes even temporary manipulation with the instance document to work correctly, see
>
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.5
>
> In contrast, must expressions are evaluated in the context of an instance document and there are no concerns about circular references, order of evaluation etc.
>
> Lada
>
>> On 07 Sep 2015, at 12:05, Robert Wilton  wrote:
>>
>> Hi Lada,
>>
>> I've just take a quick look at your DNS model referenced below.  For your containers under the choice rdata-content you have used must     statements to enforce the constraint.
>>
>> E.g.
>>
>> ...
>>            choice rdata-content {
>>              mandatory "true";
>> ...
>>              container A {
>>                must "../../type = 'ianadns:A'";
>>
>>
>> I was wondering what the reason was that you choose to use must statements rather than equivalent when statements?
>>
>> The reason that I'm asking is that I had used when statements for a similar construct that I had used for VLANs encapsulation, and I guess I would normally choose a when statement out of preference over a must statement, hence the desire to understand the rationale for the alternative.
>>
>> Thanks,
>> Rob
>>   
>>
>> On 26/08/2015 09:28, Ladislav Lhotka wrote:
>>> Hi,
>>>
>>> I changed the DNS zone data model to use this pattern - it looks
>>> good and works great:
>>>
>>> - module:
>>>    
>>> https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang
>>>
>>>    
>>> - tree:
>>>    
>>> https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree
>>>
>>>
>>> Lada
>>>
>>> Martin Bjorklund
>>> 
>>>   writes:
>>>
>>>
>>>> Hi,
>>>>
>>>> I think this could work (thanks Robert; maybe this is what you
>>>> meant!):
>>>>
>>>>    container zones {
>>>>      list zone {
>>>>        ...
>>>>        list rrset {
>>>>          ...
>>>>          leaf type {
>>>>            type identityref { ... }
>>>>          }
>>>>          list rdata {
>>>>            key id;
>>>>            ...
>>>>            choice type-specific-params {
>>>>              mandatory true;
>>>>              // to be augmented with type-specific nodes
>>>>            }
>>>>          }
>>>>        }
>>>>      }
>>>>    }
>>>>
>>>> And then in another module:
>>>>
>>>>    augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
>>>>          + "/type-specific-parameters" {
>>>>      when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>>>>         + "'TLSA')";
>>>>
>>>>      leaf certificate-usage {
>>>>        mandatory true;
>>>>        ...
>>>>      }
>>>>    }
>>>>
>>>> The empty mandatory choice formally tells the client that additional
>>>> cases are expected.
>>>>
>>>> (If the empty choice looks fishy, it is probably often possible to
>>>> define at least one case inline...)
>>>>
>>>> This pattern is nice to the client, since there is no way an
>>>> additional augmenting module can break a working client.
>>>>
>>>>
>>>> /martin
>>>>
>>>>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From nobody Mon Sep  7 09:50:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0376D1B5798 for ; Mon,  7 Sep 2015 09:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Qq-Z2Xdkze for ; Mon,  7 Sep 2015 09:50:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5849A1B5796 for ; Mon,  7 Sep 2015 09:50:50 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 854901813BC; Mon,  7 Sep 2015 18:50:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441644648; bh=aB0Bdfgl4N7jKg6adrAG3He51ZV/jUvD/vE0qiMjmnc=; h=From:Date:To; b=Zhm5n1rpAvKAKyW4LuJP8wYg1PerALuUUr/UHMZuay8NtuMjr8t+q5iZICpMGTTj+ igXYyfH9Pn+lj8z4OBFU5RLXE7iYRlwhr4MT4uchVSDUOLSKn+QnG4SKujkCCZ5bug wb+9C6GgygbOuUl38kbI496OZLJzd5OIjZzZPbGk=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <55EDBD56.4040801@cisco.com>
Date: Mon, 7 Sep 2015 18:50:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D7F575A-E3D7-4132-AFC2-96B39D01B06E@nic.cz>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>  <20150825.140102.2117420320519166894.mbj@tail-f.com>  <55ED6168.2070307@cisco.com> <845A02C2-136B-41D1-ABDE-7092E35FBF7C@nic.cz> <55EDBD56.4040801@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 16:50:53 -0000

> On 07 Sep 2015, at 18:37, Robert Wilton  wrote:
>=20
> Hi Lada,
>=20
> Thanks for the explanation.
>=20
> Initially I was concerned that there would be a higher server =
implementation cost of using a must statement over a when statement, but =
given that the container/leaves are under a choice statement then it =
seems that the must statement can presumably be implemented as =
efficiently as a when statement in this scenario.

Well, if =93when=94 was limited to the most common case like

container foo {
    when =93../type =3D =91foo=92=94;
}

then it would indeed be possible to have a more efficient (generic) =
implementation of =93when=94. But since it may contain essentially =
arbitrary XPath expressions, implementation cost of =93when=94 should be =
at least as high as that of =93must=94.

Lada

>=20
> Thanks,
> Rob
>=20
>=20
> On 07/09/2015 11:52, Ladislav Lhotka wrote:
>> Hi Rob,
>>=20
>> I generally prefer must to when, except in augments, because it is =
IMO a much cleaner concept that also has analogies in standard XML =
schema languages. When manipulates the schema based on arbitrary values =
in an instance document (that is supposed to be validated with the =
schema), and because of that it requires extra rules and sometimes even =
temporary manipulation with the instance document to work correctly, see
>>=20
>> =
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.5=

>>=20
>> In contrast, must expressions are evaluated in the context of an =
instance document and there are no concerns about circular references, =
order of evaluation etc.
>>=20
>> Lada
>>=20
>>> On 07 Sep 2015, at 12:05, Robert Wilton  wrote:
>>>=20
>>> Hi Lada,
>>>=20
>>> I've just take a quick look at your DNS model referenced below.  For =
your containers under the choice rdata-content you have used must     =
statements to enforce the constraint.
>>>=20
>>> E.g.
>>>=20
>>> ...
>>>           choice rdata-content {
>>>             mandatory "true";
>>> ...
>>>             container A {
>>>               must "../../type =3D 'ianadns:A'";
>>>=20
>>>=20
>>> I was wondering what the reason was that you choose to use must =
statements rather than equivalent when statements?
>>>=20
>>> The reason that I'm asking is that I had used when statements for a =
similar construct that I had used for VLANs encapsulation, and I guess I =
would normally choose a when statement out of preference over a must =
statement, hence the desire to understand the rationale for the =
alternative.
>>>=20
>>> Thanks,
>>> Rob
>>> =20
>>> On 26/08/2015 09:28, Ladislav Lhotka wrote:
>>>> Hi,
>>>>=20
>>>> I changed the DNS zone data model to use this pattern - it looks
>>>> good and works great:
>>>>=20
>>>> - module:
>>>>   =
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.ya=
ng
>>>>=20
>>>>   - tree:
>>>>   =
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree
>>>>=20
>>>>=20
>>>> Lada
>>>>=20
>>>> Martin Bjorklund
>>>> 
>>>>  writes:
>>>>=20
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I think this could work (thanks Robert; maybe this is what you
>>>>> meant!):
>>>>>=20
>>>>>   container zones {
>>>>>     list zone {
>>>>>       ...
>>>>>       list rrset {
>>>>>         ...
>>>>>         leaf type {
>>>>>           type identityref { ... }
>>>>>         }
>>>>>         list rdata {
>>>>>           key id;
>>>>>           ...
>>>>>           choice type-specific-params {
>>>>>             mandatory true;
>>>>>             // to be augmented with type-specific nodes
>>>>>           }
>>>>>         }
>>>>>       }
>>>>>     }
>>>>>   }
>>>>>=20
>>>>> And then in another module:
>>>>>=20
>>>>>   augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
>>>>>         + "/type-specific-parameters" {
>>>>>     when =
"derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>>>>>        + "'TLSA')";
>>>>>=20
>>>>>     leaf certificate-usage {
>>>>>       mandatory true;
>>>>>       ...
>>>>>     }
>>>>>   }
>>>>>=20
>>>>> The empty mandatory choice formally tells the client that =
additional
>>>>> cases are expected.
>>>>>=20
>>>>> (If the empty choice looks fishy, it is probably often possible to
>>>>> define at least one case inline...)
>>>>>=20
>>>>> This pattern is nice to the client, since there is no way an
>>>>> additional augmenting module can break a working client.
>>>>>=20
>>>>>=20
>>>>> /martin
>>>>>=20
>>>>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> .
>>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Sep  7 10:04:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3DB1B57BE for ; Mon,  7 Sep 2015 10:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JASF3xp_wp2q for ; Mon,  7 Sep 2015 10:04:54 -0700 (PDT)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 06CD01B57AA for ; Mon,  7 Sep 2015 10:04:54 -0700 (PDT)
Received: by lanb10 with SMTP id b10so54662863lan.3 for ; Mon, 07 Sep 2015 10:04:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ifAFr8gyKlm3YBj5yK84vB7MtY55Y2JfWr5Y4pttfWs=; b=HHGk/hAkneqvfM+uzar/ov0eDxKjh6QejB1QMWVVSAtMTcUrqKniq4PJwDSCLpHAZU ihReG+lCWVaVxJPWHKvJ+AKV9Uze09EwfpH4MpOho7oWjrSFagpRRt9rGi7cp1qWIoaL ARFMDK0sPS0cx85ua2W9huCBynWRmPYBzs2pzGXKplhcVraE6fDt+w+vQY/n4ruG3iHF w+bLZvcl9AFx+KOAE58Ivj8AmH7ubH3wwM4h5dPMnIloIYZOZ+pgq96hJQ1aVXsp7QCJ mB3PZ3v2ChgMq9HF1ZoBSc2YfsU7Q/kQzQoImV/rK93uYwr7CqDIzuLR5Inw0zJbaIA+ AUuw==
X-Gm-Message-State: ALoCoQnXpuKT57+RXtdrTxaO238TUzsg7+d91ofzRaNN2Mea0L8O5o2r+TJAbtRgLQide/i+tbDC
MIME-Version: 1.0
X-Received: by 10.112.161.232 with SMTP id xv8mr17813730lbb.123.1441645492128;  Mon, 07 Sep 2015 10:04:52 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 7 Sep 2015 10:04:51 -0700 (PDT)
In-Reply-To: <8D7F575A-E3D7-4132-AFC2-96B39D01B06E@nic.cz>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>  <20150825.140102.2117420320519166894.mbj@tail-f.com>  <55ED6168.2070307@cisco.com> <845A02C2-136B-41D1-ABDE-7092E35FBF7C@nic.cz> <55EDBD56.4040801@cisco.com> <8D7F575A-E3D7-4132-AFC2-96B39D01B06E@nic.cz>
Date: Mon, 7 Sep 2015 10:04:51 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c3c46c736ac8051f2b3f83
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 17:04:57 -0000

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

On Mon, Sep 7, 2015 at 9:50 AM, Ladislav Lhotka  wrote:

>
> > On 07 Sep 2015, at 18:37, Robert Wilton  wrote:
> >
> > Hi Lada,
> >
> > Thanks for the explanation.
> >
> > Initially I was concerned that there would be a higher server
> implementation cost of using a must statement over a when statement, but
> given that the container/leaves are under a choice statement then it seem=
s
> that the must statement can presumably be implemented as efficiently as a
> when statement in this scenario.
>
> Well, if =E2=80=9Cwhen=E2=80=9D was limited to the most common case like
>
> container foo {
>     when =E2=80=9C../type =3D =E2=80=98foo=E2=80=99=E2=80=9D;
> }
>
> then it would indeed be possible to have a more efficient (generic)
> implementation of =E2=80=9Cwhen=E2=80=9D. But since it may contain essent=
ially arbitrary
> XPath expressions, implementation cost of =E2=80=9Cwhen=E2=80=9D should b=
e at least as high
> as that of =E2=80=9Cmust=E2=80=9D.
>
>
when-stmt is much harder to implement correctly than must-stmt.

The use of 'must' vs. 'when' depends on which data structure is primary
and which is secondary.  must-stmt is for use in the primary data node.
It says "if I exist then you must pass this validation test".  when-stmt
is for secondary data structures.  It says "I exist if your settings pass
this test".



> Lada
>

Andy


>
> >
> > Thanks,
> > Rob
> >
> >
> > On 07/09/2015 11:52, Ladislav Lhotka wrote:
> >> Hi Rob,
> >>
> >> I generally prefer must to when, except in augments, because it is IMO
> a much cleaner concept that also has analogies in standard XML schema
> languages. When manipulates the schema based on arbitrary values in an
> instance document (that is supposed to be validated with the schema), and
> because of that it requires extra rules and sometimes even temporary
> manipulation with the instance document to work correctly, see
> >>
> >>
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.=
5
> >>
> >> In contrast, must expressions are evaluated in the context of an
> instance document and there are no concerns about circular references,
> order of evaluation etc.
> >>
> >> Lada
> >>
> >>> On 07 Sep 2015, at 12:05, Robert Wilton  wrote:
> >>>
> >>> Hi Lada,
> >>>
> >>> I've just take a quick look at your DNS model referenced below.  For
> your containers under the choice rdata-content you have used must
>  statements to enforce the constraint.
> >>>
> >>> E.g.
> >>>
> >>> ...
> >>>           choice rdata-content {
> >>>             mandatory "true";
> >>> ...
> >>>             container A {
> >>>               must "../../type =3D 'ianadns:A'";
> >>>
> >>>
> >>> I was wondering what the reason was that you choose to use must
> statements rather than equivalent when statements?
> >>>
> >>> The reason that I'm asking is that I had used when statements for a
> similar construct that I had used for VLANs encapsulation, and I guess I
> would normally choose a when statement out of preference over a must
> statement, hence the desire to understand the rationale for the alternati=
ve.
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>> On 26/08/2015 09:28, Ladislav Lhotka wrote:
> >>>> Hi,
> >>>>
> >>>> I changed the DNS zone data model to use this pattern - it looks
> >>>> good and works great:
> >>>>
> >>>> - module:
> >>>>
> https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.y=
ang
> >>>>
> >>>>   - tree:
> >>>>
> https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree
> >>>>
> >>>>
> >>>> Lada
> >>>>
> >>>> Martin Bjorklund
> >>>> 
> >>>>  writes:
> >>>>
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I think this could work (thanks Robert; maybe this is what you
> >>>>> meant!):
> >>>>>
> >>>>>   container zones {
> >>>>>     list zone {
> >>>>>       ...
> >>>>>       list rrset {
> >>>>>         ...
> >>>>>         leaf type {
> >>>>>           type identityref { ... }
> >>>>>         }
> >>>>>         list rdata {
> >>>>>           key id;
> >>>>>           ...
> >>>>>           choice type-specific-params {
> >>>>>             mandatory true;
> >>>>>             // to be augmented with type-specific nodes
> >>>>>           }
> >>>>>         }
> >>>>>       }
> >>>>>     }
> >>>>>   }
> >>>>>
> >>>>> And then in another module:
> >>>>>
> >>>>>   augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"
> >>>>>         + "/type-specific-parameters" {
> >>>>>     when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
> >>>>>        + "'TLSA')";
> >>>>>
> >>>>>     leaf certificate-usage {
> >>>>>       mandatory true;
> >>>>>       ...
> >>>>>     }
> >>>>>   }
> >>>>>
> >>>>> The empty mandatory choice formally tells the client that additiona=
l
> >>>>> cases are expected.
> >>>>>
> >>>>> (If the empty choice looks fishy, it is probably often possible to
> >>>>> define at least one case inline...)
> >>>>>
> >>>>> This pattern is nice to the client, since there is no way an
> >>>>> additional augmenting module can break a working client.
> >>>>>
> >>>>>
> >>>>> /martin
> >>>>>
> >>>>>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >> .
> >>
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon, Sep 7, 2015 at 9:50 AM, Ladislav Lhotka <<=
a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:


> On 07 Sep 2015, at 18:37, Robert Wilton <rwilton@cisco.com> wrote:

>

> Hi Lada,

>

> Thanks for the explanation.

>

> Initially I was concerned that there would be a higher server implemen=
tation cost of using a must statement over a when statement, but given that=
 the container/leaves are under a choice statement then it seems that the m=
ust statement can presumably be implemented as efficiently as a when statem=
ent in this scenario.



Well, if =E2=80=9Cwhen=E2=80=9D was limited to the most common case like


container foo {

=C2=A0 =C2=A0 when =E2=80=9C../type =3D =E2=80=98foo=E2=80=99=E2=80=9D;

}



then it would indeed be possible to have a more efficient (generic) impleme=
ntation of =E2=80=9Cwhen=E2=80=9D. But since it may contain essentially arb=
itrary XPath expressions, implementation cost of =E2=80=9Cwhen=E2=80=9D sho=
uld be at least as high as that of =E2=80=9Cmust=E2=80=9D.



when-stmt is much harder to implement =
correctly than must-stmt.

The use of 'must'=
; vs. 'when' depends on which data structure is primary
a=
nd which is secondary. =C2=A0must-stmt is for use in the primary data node.=

It says "if I exist then you must pass this validation test=
". =C2=A0when-stmt
is for secondary data structures.=C2=A0 I=
t says "I exist if your settings pass this test".

<=
/div>
=C2=A0

Lada

Andy
=C2=A0



>

> Thanks,

> Rob

>

>

> On 07/09/2015 11:52, Ladislav Lhotka wrote:

>> Hi Rob,

>>

>> I generally prefer must to when, except in augments, because it is=
 IMO a much cleaner concept that also has analogies in standard XML schema =
languages. When manipulates the schema based on arbitrary values in an inst=
ance document (that is supposed to be validated with the schema), and becau=
se of that it requires extra rules and sometimes even temporary manipulatio=
n with the instance document to work correctly, see

>>

>> https://tools.iet=
f.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.5

>>

>> In contrast, must expressions are evaluated in the context of an i=
nstance document and there are no concerns about circular references, order=
 of evaluation etc.

>>

>> Lada

>>

>>> On 07 Sep 2015, at 12:05, Robert Wilton <rwilton@cisco.com> wrote:

>>>

>>> Hi Lada,

>>>

>>> I've just take a quick look at your DNS model referenced b=
elow.=C2=A0 For your containers under the choice rdata-content you have use=
d must=C2=A0 =C2=A0 =C2=A0statements to enforce the constraint.

>>>

>>> E.g.

>>>

>>> ...

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice rdata-content {=


>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory "=
;true";

>>> ...

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container A {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must &qu=
ot;../../type =3D 'ianadns:A'";

>>>

>>>

>>> I was wondering what the reason was that you choose to use mus=
t statements rather than equivalent when statements?

>>>

>>> The reason that I'm asking is that I had used when stateme=
nts for a similar construct that I had used for VLANs encapsulation, and I =
guess I would normally choose a when statement out of preference over a mus=
t statement, hence the desire to understand the rationale for the alternati=
ve.

>>>

>>> Thanks,

>>> Rob

>>>

>>> On 26/08/2015 09:28, Ladislav Lhotka wrote:

>>>> Hi,

>>>>

>>>> I changed the DNS zone data model to use this pattern - it=
 looks

>>>> good and works great:

>>>>

>>>> - module:

>>>>=C2=A0 =C2=A0https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zone=
s.yang

>>>>

>>>>=C2=A0 =C2=A0- tree:

>>>>=C2=A0 =C2=A0=
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree=


>>>>

>>>>

>>>> Lada

>>>>

>>>> Martin Bjorklund

>>>> <mbj@tail-f.com&g=
t;

>>>>=C2=A0 writes:

>>>>

>>>>

>>>>> Hi,

>>>>>

>>>>> I think this could work (thanks Robert; maybe this is =
what you

>>>>> meant!):

>>>>>

>>>>>=C2=A0 =C2=A0container zones {

>>>>>=C2=A0 =C2=A0 =C2=A0list zone {

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0...

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0list rrset {

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf type {

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type identityr=
ef { ... }

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

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list rdata {

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key id;

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice type-sp=
ecific-params {

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandato=
ry true;

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// to b=
e augmented with type-specific nodes

>>>>>=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}

>>>>>

>>>>> And then in another module:

>>>>>

>>>>>=C2=A0 =C2=A0augment "/dnsz:zones/dnsz:zone/dnsz:r=
rset/dnsz:rdata"

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ "/type-specifi=
c-parameters" {

>>>>>=C2=A0 =C2=A0 =C2=A0when "derived-from-or-self(../=
dnsz:type,'iana-dns-parameters',"

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 + "'TLSA')&quo=
t;;

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0leaf certificate-usage {

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;

>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0...

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

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

>>>>>

>>>>> The empty mandatory choice formally tells the client t=
hat additional

>>>>> cases are expected.

>>>>>

>>>>> (If the empty choice looks fishy, it is probably often=
 possible to

>>>>> define at least one case inline...)

>>>>>

>>>>> This pattern is nice to the client, since there is no =
way an

>>>>> additional augmenting module can break a working clien=
t.

>>>>>

>>>>>

>>>>> /martin

>>>>>

>>>>>

>> --

>> Ladislav Lhotka, CZ.NIC Labs

>> PGP Key ID: E74E8C0C

>>

>>

>>

>>

>> .

>>

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c3c46c736ac8051f2b3f83--


From nobody Mon Sep  7 10:14:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAEE1B32DC for ; Mon,  7 Sep 2015 10:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.61
X-Spam-Level: 
X-Spam-Status: No, score=-11.61 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, J_CHICKENPOX_24=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTSbFpYvhcZm for ; Mon,  7 Sep 2015 10:14:01 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9941A906A for ; Mon,  7 Sep 2015 10:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18368; q=dns/txt; s=iport; t=1441646041; x=1442855641; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=0htsqPQrR2ar/d+EugGnEhjM7/XQ7Rf8V7pQVRVBDlc=; b=AJYa1FArRXkXtOYUr+tmooXI+7V+UGjYq9UTfcgdiD6S7MEq6HGWiDl+ ObEqAka0CpbOU67ULTG6njQqLm3g7QsZ6XA9ht46URa+e+FNZJH0yFbv5 8Ax050oYp6P97elklCsyo+sYxfOAMn6qv5CIMCSDTbIuwSTiw0ER6qrT0 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C/BACHxO1V/xbLJq1UCYN3aYMkukiBbQEJhS9KAoFqEgEBAQEBAQGBCoQjAQEBAwEBAQEgSwoBEAkCEQQBAQEJFggDAgIJAwIBAgEVHwkIBg0GAgEBF4gLCA2XbJ0dlAoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhHuEMBFLB4JpgUMFlVWMeoFMhy+OEINsJoIQHIFVPTOISQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,485,1437436800";  d="scan'208,217";a="611446386"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 07 Sep 2015 17:13:58 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t87HDwhj029952; Mon, 7 Sep 2015 17:13:58 GMT
To: Andy Bierman 
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com> 
From: Robert Wilton 
Message-ID: <55EDC5D7.2050407@cisco.com>
Date: Mon, 7 Sep 2015 18:13:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010101060505010500070000"
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 17:14:04 -0000

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

Hi Andy,

Picking up a slightly old thread after PTO ...

On 24/08/2015 22:50, Andy Bierman wrote:
>
>
> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton  > wrote:
>
>     Hi Randy,
>
>     On 24/08/2015 20:20, Randy Presuhn wrote:
>
>         Hi -
>
>             From: Ladislav Lhotka >
>             Sent: Aug 24, 2015 11:44 AM
>             To: Andy Bierman              >
>             Cc: "netmod@ietf.org "
>             >
>             Subject: Re: [netmod] Y26 again, sorry
>
>         ...
>
>                 YANG does not provide any mechanism to REQUIRE modules
>                 A and B
>                 to both be implemented on a server.  You may think it
>                 should, but
>                 currently the YANG conformance is for an individual
>                 module.
>
>             There are sections on conformance and conformance
>             announcement,
>             and they say nothing like this. In my view, the data model
>             comprises
>             *all* modules advertised by the server. I think your
>             interpretation
>             of conformance might be an extrapolation from SNMP/SMI
>             times, but,
>             for better or worse, it really has no support in the YANG
>             spec.
>
>         It sounds as though you might be talking past each other.
>         I believe part of Andy's point is that clients will need to deal
>         with servers that do not implement (and thus do not advertise)
>         the augmenting module.  But there's (I think) a more interesting
>         issue beneath this.
>
>         Let's start with module M.  Let's say M is for "modem" (to pick
>         an obsolete but widely understood resource).
>         Two different augmenting modules, F (for FSK - frequency
>         shift keying) and Q (for QAM - quadrature amplitude modulation)
>         are developed.  Let us say that F and Q are mutually incompatible.
>
>         A system with multiple Ms could well have both M+F and M+Q modems,
>         but (if we claim F & Q are incompatible) could not have M+F+Q.
>         If naked M is to be prohibited in systems (also) supporting F or Q
>         or both, we don't currently have a mechanism to do so.
>
>     Could this be achieved by augmenting from a choice statement?
>
>     M defines the choice statement but with no case statements.
>
>     F and Q both implement separate case statements that augment the
>     choice statement in M.  The case statements have containers which
>     hold the parameters related to F or Q.
>
>     M without F or Q is meaningless.
>     M+F or M+Q works, but the choice statement means that you cannot
>     have M+F+Q.
>
>
> nice solution
>
> This is perhaps the cleanest way to add mandatory nodes to a module.
> The old client will not attempt to create the new case.
>
> As I said before, I am OK with changing MUST NOT to SHOULD NOT
> add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
>
> Two conditions so far:
>
>     (1)  augment + when 
>
>     (2) augment choice with a new case-stmt
>
> (1) is hard to define, but not (2)

So, Lada is using (2) for DNS zones which works.  Does the Y26 text need 
to be updated to explicitly allow this, or is this implicitly allowed 
anyway?

Unfortunately (2) won't work for my model augmentation issue, of wanting 
to enforce that a sub-interface has to have a parent interface-ref.   As 
a recap, the yang from my interfaces-common draft is:

   augment "/if:interfaces/if:interface" {
     when "if:type = 'ianaift:l2vlan' or
           if:type = 'ianaift:atmSubInterface' or
           if:type = 'ianaift:frameRelay'"  {
       description
         "Any ianaift :types that represent sub-interfaces";
     }
     if-feature "sub-interfaces";
     description "Add a parent interface field to interfaces to model
                  sub-interfaces";
     leaf parent-interface {
       type if:interface-ref;
       /*
        * TODO - How to make this mandatory without using the
        * mandatory keyword.
        * - Current options appear to be:
        *   - Create a sub-interface container with presence.
        *   - Enforce the constraint with a must statement.
        */
       //mandatory true;
       description
         "This is the mandatory reference to the parent interface of
          this sub-interface.";
     }
   }


One suggestion that I've heard is based on a specific instance of your 
first condition above, where the when statement only uses identities 
defined by the same augmenting module:
I.e. don't use the existing "ianaift:l2vlan" for a VLAN sub-interface, 
but define a new interface type identity "vlan-sub" in my interface 
extensions module which would inherit from "iftype:l2vlan".   Similarly 
for atmSubInterface and frameRelay. Obviously, at the moment, this is 
not allowed, but potentially it could be, and it is still safe to 
existing clients (since they can't be using the new type).

However, I'm not really sure whether fragmenting the list of iftypes 
into separate modules would be a good idea ...

Thanks,
Rob


>
>     I can point you to a concrete example if it helps.
>
>     Thanks,
>     Rob
>
>
>
>
>
> Andy
>
>         Randy
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org 
>         https://www.ietf.org/mailman/listinfo/netmod
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>


--------------010101060505010500070000
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    Picking up a slightly old thread after PTO ...

    

    
On 24/08/2015 22:50, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Aug 24, 2015 at 2:24 PM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            
Hi
              Randy,

              

              On 24/08/2015 20:20, Randy Presuhn wrote:

              

                Hi -

                

                

                  From: Ladislav Lhotka <lhotka@nic.cz>

                  Sent: Aug 24, 2015 11:44 AM

                  To: Andy Bierman <andy@yumaworks.com>

                  Cc: "netmod@ietf.org"
                  <netmod@ietf.org>

                  Subject: Re: [netmod] Y26 again, sorry

                

                ...

                

                  

                    YANG does not provide any mechanism to REQUIRE 
                    modules A and B

                    to both be implemented on a server.  You may think
                    it should, but

                    currently the YANG conformance is for an individual
                    module.

                  

                  There are sections on conformance and conformance
                  announcement,

                  and they say nothing like this. In my view, the data
                  model comprises

                  *all* modules advertised by the server. I think your
                  interpretation

                  of conformance might be an extrapolation from SNMP/SMI
                  times, but,

                  for better or worse, it really has no support in the
                  YANG spec.

                

                It sounds as though you might be talking past each
                other.

                I believe part of Andy's point is that clients will need
                to deal

                with servers that do not implement (and thus do not
                advertise)

                the augmenting module.  But there's (I think) a more
                interesting

                issue beneath this.

                

                Let's start with module M.  Let's say M is for "modem"
                (to pick

                an obsolete but widely understood resource).

                Two different augmenting modules, F (for FSK - frequency

                shift keying) and Q (for QAM - quadrature amplitude
                modulation)

                are developed.  Let us say that F and Q are mutually
                incompatible.

                

                A system with multiple Ms could well have both M+F and
                M+Q modems,

                but (if we claim F & Q are incompatible) could not
                have M+F+Q.

                If naked M is to be prohibited in systems (also)
                supporting F or Q

                or both, we don't currently have a mechanism to do so.

              

              Could this be achieved by augmenting from a choice
              statement?

              

              M defines the choice statement but with no case
              statements.

              

              F and Q both implement separate case statements that
              augment the choice statement in M.  The case statements
              have containers which hold the parameters related to F or
              Q.

              

              M without F or Q is meaningless.

              M+F or M+Q works, but the choice statement means that you
              cannot have M+F+Q.

              

            

            


            

            
nice solution

            


            

            
This is perhaps the cleanest way to add mandatory nodes
              to a module.

            
The old client will not attempt to create the new case.

            


            

            
As I said before, I am OK with changing MUST NOT to
              SHOULD NOT

            
add mandatory nodes, and then add MAY when X, Y, Z
              conditions are met.

            
 

            


            

            
Two conditions so far:

            


            

            
    (1)  augment + when <new flag set that old
              client will not set>

            


            

            
    (2) augment choice with a new case-stmt

            


            

            
(1) is hard to define, but not (2)

          

        

      

    

    

    So, Lada is using (2) for DNS zones which works.  Does the Y26 text
    need to be updated to explicitly allow this, or is this implicitly
    allowed anyway?

    

    Unfortunately (2) won't work for my model augmentation issue, of
    wanting to enforce that a sub-interface has to have a parent
    interface-ref.   As a recap, the yang from my interfaces-common
    draft is:

    

      augment "/if:interfaces/if:interface" {

        when "if:type = 'ianaift:l2vlan' or 

              if:type = 'ianaift:atmSubInterface' or

              if:type = 'ianaift:frameRelay'"  {

          description

            "Any ianaift :types that represent sub-interfaces";

        }

        if-feature "sub-interfaces";

        description "Add a parent interface field to interfaces
      to model

                     sub-interfaces";

        leaf parent-interface {

          type if:interface-ref;

          /*

           * TODO - How to make this mandatory without using
      the

           * mandatory keyword.

           * - Current options appear to be:

           *   - Create a sub-interface container with
      presence.

           *   - Enforce the constraint with a must statement.

           */

          //mandatory true;

          description

            "This is the mandatory reference to the parent
      interface of

             this sub-interface.";

        }

      }

      

    

    One suggestion that I've heard is based on a specific instance of
    your first condition above, where the when statement only uses
    identities defined by the same augmenting module: 

    I.e. don't use the existing "ianaift:l2vlan" for a VLAN
    sub-interface, but define a new interface type identity "vlan-sub"
    in my interface extensions module which would inherit from
    "iftype:l2vlan".   Similarly for atmSubInterface and frameRelay. 
    Obviously, at the moment, this is not allowed, but potentially it
    could be, and it is still safe to existing clients (since they can't
    be using the new type).

    

    However, I'm not really sure whether fragmenting the list of iftypes
    into separate modules would be a good idea ...

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            

              I can point you to a concrete example if it helps.

              

              Thanks,

              Rob

              

              

              

                

              

            

            


            

            


            

            
Andy

            


            

            
 

            

              

                Randy

                

                _______________________________________________

                netmod mailing list

                netmod@ietf.org

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

                

              

              

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

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

            

          

          

        

      

    

    

  


--------------010101060505010500070000--


From nobody Mon Sep  7 10:41:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7345C1B58FB for ; Mon,  7 Sep 2015 10:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.922
X-Spam-Level: 
X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne1OMtCwUVsm for ; Mon,  7 Sep 2015 10:41:42 -0700 (PDT)
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 7E59D1B58F5 for ; Mon,  7 Sep 2015 10:41:41 -0700 (PDT)
Received: by laeb10 with SMTP id b10so56048611lae.1 for ; Mon, 07 Sep 2015 10:41:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vbbFjxObQ2SnpH2oY8iir7xEI1Wq7ZSgeohQv2G9diQ=; b=TmSI5HYyZ4M50ElA0uPiNmGdtI9BYXW1kb61oTDjPHeqwKKyfKwoK2F7cqXsmOZsM/ dTAMyA8XE2Wi7wljnaNtUsJ8fUoZwtosd8c8uMKihqSZVf9x54JpwqTIR5dbuV49CBoD A8KuIHvrIX/XKnPytlkPrQilLVEOtcUxXeOxFSGYURXKzJw8TMuiiXN/x6A3dO+6gnkV I42ObtgnfSMOsix7puvPkqUskUU8iOg2/EkWmqfiAHkINhsNlKtrg54KQlY1+ePdDDht q5Mwqba7vVFr6f9+4WxCJ2kl/ju0/MvLiHPcjS4dwGTFZyqTDe8WCc41HQBM0+a14Bti M7Gw==
X-Gm-Message-State: ALoCoQmRqKZ0XiInjVdN74anUCnpb6+OyNBELaFe1PXOUYRROdJX3llXreQPCEfrNjvqzb4FZb3E
MIME-Version: 1.0
X-Received: by 10.152.36.101 with SMTP id p5mr2843797laj.123.1441647699520; Mon, 07 Sep 2015 10:41:39 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 7 Sep 2015 10:41:39 -0700 (PDT)
In-Reply-To: <55EDC5D7.2050407@cisco.com>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com>
Date: Mon, 7 Sep 2015 10:41:39 -0700
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=089e0158b5bc058c1f051f2bc383
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Sep 2015 17:41:44 -0000

--089e0158b5bc058c1f051f2bc383
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 7, 2015 at 10:13 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Picking up a slightly old thread after PTO ...
>
> On 24/08/2015 22:50, Andy Bierman wrote:
>
>
>
> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton  wrote:
>
>> Hi Randy,
>>
>> On 24/08/2015 20:20, Randy Presuhn wrote:
>>
>>> Hi -
>>>
>>> From: Ladislav Lhotka 
>>>> Sent: Aug 24, 2015 11:44 AM
>>>> To: Andy Bierman 
>>>> Cc: "netmod@ietf.org" 
>>>> Subject: Re: [netmod] Y26 again, sorry
>>>>
>>> ...
>>>
>>>> YANG does not provide any mechanism to REQUIRE  modules A and B
>>>>> to both be implemented on a server.  You may think it should, but
>>>>> currently the YANG conformance is for an individual module.
>>>>>
>>>> There are sections on conformance and conformance announcement,
>>>> and they say nothing like this. In my view, the data model comprises
>>>> *all* modules advertised by the server. I think your interpretation
>>>> of conformance might be an extrapolation from SNMP/SMI times, but,
>>>> for better or worse, it really has no support in the YANG spec.
>>>>
>>> It sounds as though you might be talking past each other.
>>> I believe part of Andy's point is that clients will need to deal
>>> with servers that do not implement (and thus do not advertise)
>>> the augmenting module.  But there's (I think) a more interesting
>>> issue beneath this.
>>>
>>> Let's start with module M.  Let's say M is for "modem" (to pick
>>> an obsolete but widely understood resource).
>>> Two different augmenting modules, F (for FSK - frequency
>>> shift keying) and Q (for QAM - quadrature amplitude modulation)
>>> are developed.  Let us say that F and Q are mutually incompatible.
>>>
>>> A system with multiple Ms could well have both M+F and M+Q modems,
>>> but (if we claim F & Q are incompatible) could not have M+F+Q.
>>> If naked M is to be prohibited in systems (also) supporting F or Q
>>> or both, we don't currently have a mechanism to do so.
>>>
>> Could this be achieved by augmenting from a choice statement?
>>
>> M defines the choice statement but with no case statements.
>>
>> F and Q both implement separate case statements that augment the choice
>> statement in M.  The case statements have containers which hold the
>> parameters related to F or Q.
>>
>> M without F or Q is meaningless.
>> M+F or M+Q works, but the choice statement means that you cannot have
>> M+F+Q.
>>
>>
> nice solution
>
> This is perhaps the cleanest way to add mandatory nodes to a module.
> The old client will not attempt to create the new case.
>
> As I said before, I am OK with changing MUST NOT to SHOULD NOT
> add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
>
>
> Two conditions so far:
>
>     (1)  augment + when 
>
>     (2) augment choice with a new case-stmt
>
> (1) is hard to define, but not (2)
>
>
> So, Lada is using (2) for DNS zones which works.  Does the Y26 text need
> to be updated to explicitly allow this, or is this implicitly allowed
> anyway?
>
> Unfortunately (2) won't work for my model augmentation issue, of wanting
> to enforce that a sub-interface has to have a parent interface-ref.   As a
> recap, the yang from my interfaces-common draft is:
>



Your example shows the YANG conformance problems fairly well.
Clearly the IETF (and others) want to use advanced design patterns
in which conformance to the base module (M) is insufficient to describe
the actual API requirements.

YANG uses revision dates to identify versions.
There is no such thing as a major vs. minor revision.
I agree with Lada that it is possible to have major revision update
where the old clients should not be used anymore.

I already suggested relaxing the MUST NOT to a SHOULD NOT,
wrt/ adding mandatory nodes.


 Andy


>   augment "/if:interfaces/if:interface" {
>     when "if:type = 'ianaift:l2vlan' or
>           if:type = 'ianaift:atmSubInterface' or
>           if:type = 'ianaift:frameRelay'"  {
>       description
>         "Any ianaift :types that represent sub-interfaces";
>     }
>     if-feature "sub-interfaces";
>     description "Add a parent interface field to interfaces to model
>                  sub-interfaces";
>     leaf parent-interface {
>       type if:interface-ref;
>       /*
>        * TODO - How to make this mandatory without using the
>        * mandatory keyword.
>        * - Current options appear to be:
>        *   - Create a sub-interface container with presence.
>        *   - Enforce the constraint with a must statement.
>        */
>       //mandatory true;
>       description
>         "This is the mandatory reference to the parent interface of
>          this sub-interface.";
>     }
>   }
>
>
> One suggestion that I've heard is based on a specific instance of your
> first condition above, where the when statement only uses identities
> defined by the same augmenting module:
> I.e. don't use the existing "ianaift:l2vlan" for a VLAN sub-interface, but
> define a new interface type identity "vlan-sub" in my interface extensions
> module which would inherit from "iftype:l2vlan".   Similarly for
> atmSubInterface and frameRelay.  Obviously, at the moment, this is not
> allowed, but potentially it could be, and it is still safe to existing
> clients (since they can't be using the new type).
>
> However, I'm not really sure whether fragmenting the list of iftypes into
> separate modules would be a good idea ...
>
> Thanks,
> Rob
>
>
>
> I can point you to a concrete example if it helps.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>>
>
> Andy
>
>
>
>> Randy
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>

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




On Mon, Sep 7, 2015 at 10:13 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Picking up a slightly old thread after PTO ...

    

    
On 24/08/2015 22:50, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Aug 24, 2015 at 2:24 PM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            
Hi
              Randy,

              

              On 24/08/2015 20:20, Randy Presuhn wrote:

              

                Hi -

                

                

                  From: Ladislav Lhotka <lhotka@nic.cz>

                  Sent: Aug 24, 2015 11:44 AM

                  To: Andy Bierman <andy@yumaworks.com>

                  Cc: "netmod@ietf.org"
                  <=
netmod@ietf.org>

                  Subject: Re: [netmod] Y26 again, sorry

                

                ...

                

                  

                    YANG does not provide any mechanism to REQUIRE=C2=A0
                    modules A and B

                    to both be implemented on a server.=C2=A0 You may think
                    it should, but

                    currently the YANG conformance is for an individual
                    module.

                  

                  There are sections on conformance and conformance
                  announcement,

                  and they say nothing like this. In my view, the data
                  model comprises

                  *all* modules advertised by the server. I think your
                  interpretation

                  of conformance might be an extrapolation from SNMP/SMI
                  times, but,

                  for better or worse, it really has no support in the
                  YANG spec.

                

                It sounds as though you might be talking past each
                other.

                I believe part of Andy's point is that clients will nee=
d
                to deal

                with servers that do not implement (and thus do not
                advertise)

                the augmenting module.=C2=A0 But there's (I think) a mo=
re
                interesting

                issue beneath this.

                

                Let's start with module M.=C2=A0 Let's say M is for=
 "modem"
                (to pick

                an obsolete but widely understood resource).

                Two different augmenting modules, F (for FSK - frequency
                shift keying) and Q (for QAM - quadrature amplitude
                modulation)

                are developed.=C2=A0 Let us say that F and Q are mutually
                incompatible.

                

                A system with multiple Ms could well have both M+F and
                M+Q modems,

                but (if we claim F & Q are incompatible) could not
                have M+F+Q.

                If naked M is to be prohibited in systems (also)
                supporting F or Q

                or both, we don't currently have a mechanism to do so.<=
br>
              

              Could this be achieved by augmenting from a choice
              statement?

              

              M defines the choice statement but with no case
              statements.

              

              F and Q both implement separate case statements that
              augment the choice statement in M.=C2=A0 The case statements
              have containers which hold the parameters related to F or
              Q.

              

              M without F or Q is meaningless.

              M+F or M+Q works, but the choice statement means that you
              cannot have M+F+Q.

              

            

            


            

            
nice solution

            


            

            
This is perhaps the cleanest way to add mandatory nodes
              to a module.

            
The old client will not attempt to create the new case.
            


            

            
As I said before, I am OK with changing MUST NOT to
              SHOULD NOT

            
add mandatory nodes, and then add MAY when X, Y, Z
              conditions are met.

            
=C2=A0

            


            

            
Two conditions so far:

            


            

            
=C2=A0 =C2=A0 (1) =C2=A0augment + when <new flag set th=
at old
              client will not set>

            


            

            
=C2=A0 =C2=A0 (2) augment choice with a new case-stmt
            


            

            
(1) is hard to define, but not (2)

          

        

      

    

    

    So, Lada is using (2) for DNS zones which works.=C2=A0 Does the Y26 tex=
t
    need to be updated to explicitly allow this, or is this implicitly
    allowed anyway?

    

    Unfortunately (2) won't work for my model augmentation issue, of
    wanting to enforce that a sub-interface has to have a parent
    interface-ref.=C2=A0=C2=A0 As a recap, the yang from my interfaces-comm=
on
    draft is:



=

Your example shows the YANG conformance problems fairly well.
Clearly the IETF (and others) want to use advanced design patterns<=
/div>
in which conformance to the base module (M) is insufficient to de=
scribe
the actual API requirements.

YANG=
 uses revision dates to identify versions.
There is no such thing=
 as a major vs. minor revision.
I agree with Lada that it is poss=
ible to have major revision update
where the old clients should n=
ot be used anymore.

I already suggested relaxing t=
he MUST NOT to a SHOULD NOT,
wrt/ adding mandatory nodes.


=C2=A0Andy


    

    =C2=A0 augment "/if:interfaces/if:interface" {
    =C2=A0=C2=A0=C2=A0 when "if:type =3D 'ianaift:l2vlan&=
#39; or 

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if:type=
 =3D 'ianaift:atmSubInterface' or

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if:type=
 =3D 'ianaift:frameRelay'"=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 "Any ianaift :=
types that represent sub-interfaces";

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

    =C2=A0=C2=A0=C2=A0 if-feature "sub-interfaces";=


    =C2=A0=C2=A0=C2=A0 description "Add a parent interface fi=
eld to interfaces
      to model

    =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 sub-interfaces";

    =C2=A0=C2=A0=C2=A0 leaf parent-interface {

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type if:interface-ref;=


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /*

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * TODO - How to make this=
 mandatory without using
      the

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * mandatory keyword.=


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * - Current options appea=
r to be:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0=C2=A0 - Create a =
sub-interface container with
      presence.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0=C2=A0 - Enforce t=
he constraint with a must statement.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 */

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //mandatory true;

    =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 "This is the m=
andatory reference to the parent
      interface of

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this sub-inte=
rface.";

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

    =C2=A0 }

    =C2=A0 

    

    One suggestion that I've heard is based on a specific instance of
    your first condition above, where the when statement only uses
    identities defined by the same augmenting module: 

    I.e. don't use the existing "ianaift:l2vlan" for a VLAN
    sub-interface, but define a new interface type identity "vlan-sub&=
quot;
    in my interface extensions module which would inherit from
    "iftype:l2vlan".=C2=A0=C2=A0 Similarly for atmSubInterface an=
d frameRelay.=C2=A0
    Obviously, at the moment, this is not allowed, but potentially it
    could be, and it is still safe to existing clients (since they can'=
t
    be using the new type).

    

    However, I'm not really sure whether fragmenting the list of iftype=
s
    into separate modules would be a good idea ...

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            

              I can point you to a concrete example if it helps.

              

              Thanks,

              Rob

              

              

              

                

              

            

            


            

            


            

            
Andy

            


            

            
=C2=A0

            

              

                Randy

                

                _______________________________________________

                netmod mailing list

                netmod=
@ietf.org

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

                

              

              

              _______________________________________________

              netmod mailing list

              netmod@i=
etf.org

              https://www.ietf.org/mailman/listinfo/net=
mod

            

          

          

        

      

    

    

  






--089e0158b5bc058c1f051f2bc383--


From nobody Tue Sep  8 01:16:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7563C1A1BC3 for ; Tue,  8 Sep 2015 01:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_24=0.6, MANGLED_FORM=2.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_x4Z5lTknX3 for ; Tue,  8 Sep 2015 01:16:31 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BE2DA1B29A8 for ; Tue,  8 Sep 2015 01:16:30 -0700 (PDT)
Received: from localhost (unknown [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 7ECF21CC0181; Tue,  8 Sep 2015 10:16:27 +0200 (CEST)
From: Ladislav Lhotka 
To: Robert Wilton , Andy Bierman 
In-Reply-To: <55EDC5D7.2050407@cisco.com>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 08 Sep 2015 10:16:25 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 08:16:33 -0000

Robert Wilton  writes:

> Hi Andy,
>
> Picking up a slightly old thread after PTO ...
>
> On 24/08/2015 22:50, Andy Bierman wrote:
>>
>>
>> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton > > wrote:
>>
>>     Hi Randy,
>>
>>     On 24/08/2015 20:20, Randy Presuhn wrote:
>>
>>         Hi -
>>
>>             From: Ladislav Lhotka >
>>             Sent: Aug 24, 2015 11:44 AM
>>             To: Andy Bierman >             >
>>             Cc: "netmod@ietf.org "
>>             >
>>             Subject: Re: [netmod] Y26 again, sorry
>>
>>         ...
>>
>>                 YANG does not provide any mechanism to REQUIRE modules
>>                 A and B
>>                 to both be implemented on a server.  You may think it
>>                 should, but
>>                 currently the YANG conformance is for an individual
>>                 module.
>>
>>             There are sections on conformance and conformance
>>             announcement,
>>             and they say nothing like this. In my view, the data model
>>             comprises
>>             *all* modules advertised by the server. I think your
>>             interpretation
>>             of conformance might be an extrapolation from SNMP/SMI
>>             times, but,
>>             for better or worse, it really has no support in the YANG
>>             spec.
>>
>>         It sounds as though you might be talking past each other.
>>         I believe part of Andy's point is that clients will need to deal
>>         with servers that do not implement (and thus do not advertise)
>>         the augmenting module.  But there's (I think) a more interesting
>>         issue beneath this.
>>
>>         Let's start with module M.  Let's say M is for "modem" (to pick
>>         an obsolete but widely understood resource).
>>         Two different augmenting modules, F (for FSK - frequency
>>         shift keying) and Q (for QAM - quadrature amplitude modulation)
>>         are developed.  Let us say that F and Q are mutually incompatible.
>>
>>         A system with multiple Ms could well have both M+F and M+Q modems,
>>         but (if we claim F & Q are incompatible) could not have M+F+Q.
>>         If naked M is to be prohibited in systems (also) supporting F or Q
>>         or both, we don't currently have a mechanism to do so.
>>
>>     Could this be achieved by augmenting from a choice statement?
>>
>>     M defines the choice statement but with no case statements.
>>
>>     F and Q both implement separate case statements that augment the
>>     choice statement in M.  The case statements have containers which
>>     hold the parameters related to F or Q.
>>
>>     M without F or Q is meaningless.
>>     M+F or M+Q works, but the choice statement means that you cannot
>>     have M+F+Q.
>>
>>
>> nice solution
>>
>> This is perhaps the cleanest way to add mandatory nodes to a module.
>> The old client will not attempt to create the new case.
>>
>> As I said before, I am OK with changing MUST NOT to SHOULD NOT
>> add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
>>
>> Two conditions so far:
>>
>>     (1)  augment + when 
>>
>>     (2) augment choice with a new case-stmt
>>
>> (1) is hard to define, but not (2)
>
> So, Lada is using (2) for DNS zones which works.  Does the Y26 text need 
> to be updated to explicitly allow this, or is this implicitly allowed 
> anyway?

It is allowed in YANG 1.0.

>
> Unfortunately (2) won't work for my model augmentation issue, of wanting 
> to enforce that a sub-interface has to have a parent interface-ref.
> As

ietf-interfaces could also use the same mandatory choice pattern but
it seems too late now. This is an example why the strict module update rules
are counter-productive at this stage - instead if adopting the best current
practice we have to resort to kludges.

> a recap, the yang from my interfaces-common draft is:
>
>    augment "/if:interfaces/if:interface" {
>      when "if:type = 'ianaift:l2vlan' or
>            if:type = 'ianaift:atmSubInterface' or
>            if:type = 'ianaift:frameRelay'"  {
>        description
>          "Any ianaift :types that represent sub-interfaces";
>      }
>      if-feature "sub-interfaces";
>      description "Add a parent interface field to interfaces to model
>                   sub-interfaces";
>      leaf parent-interface {
>        type if:interface-ref;
>        /*
>         * TODO - How to make this mandatory without using the
>         * mandatory keyword.
>         * - Current options appear to be:
>         *   - Create a sub-interface container with presence.

... which doesn't make the parent-interface mandatory anyway.


>         *   - Enforce the constraint with a must statement.

Yes, but this design offers no good place for it, you'd need to use an
extra np-container and attach the must statement to it. 

>         */
>        //mandatory true;
>        description
>          "This is the mandatory reference to the parent interface of
>           this sub-interface.";
>      }
>    }
>
>
> One suggestion that I've heard is based on a specific instance of your 
> first condition above, where the when statement only uses identities 
> defined by the same augmenting module:
> I.e. don't use the existing "ianaift:l2vlan" for a VLAN sub-interface, 
> but define a new interface type identity "vlan-sub" in my interface 
> extensions module which would inherit from "iftype:l2vlan".   Similarly 
> for atmSubInterface and frameRelay. Obviously, at the moment, this is 
> not allowed, but potentially it could be, and it is still safe to 
> existing clients (since they can't be using the new type).

I think it would be best to make backward old-client compatibility a
general guideline rather than a hard language rule. Currently it is
enforced in some cases (augments, module update rules) but a mere
guideline in other cases (must statements, extensions, defaults).

Lada

>
> However, I'm not really sure whether fragmenting the list of iftypes 
> into separate modules would be a good idea ...
>
> Thanks,
> Rob
>
>
>>
>>     I can point you to a concrete example if it helps.
>>
>>     Thanks,
>>     Rob
>>
>>
>>
>>
>>
>> Andy
>>
>>         Randy
>>
>>         _______________________________________________
>>         netmod mailing list
>>         netmod@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     netmod@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep  8 01:50:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D197C1B3DBF for ; Tue,  8 Sep 2015 01:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.389
X-Spam-Level: 
X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_FORM=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_yYNvvgVxGp for ; Tue,  8 Sep 2015 01:50:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54B801B3DB5 for ; Tue,  8 Sep 2015 01:50:47 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C5E41AE047B; Tue,  8 Sep 2015 10:50:45 +0200 (CEST)
Date: Tue, 08 Sep 2015 10:50:44 +0200 (CEST)
Message-Id: <20150908.105044.1498048855200206331.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <55EDC5D7.2050407@cisco.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 08:50:49 -0000

Ladislav Lhotka  wrote:
> Robert Wilton  writes:
> 
> > Hi Andy,
> >
> > Picking up a slightly old thread after PTO ...
> >
> > On 24/08/2015 22:50, Andy Bierman wrote:
> >>
> >>
> >> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton  >> > wrote:
> >>
> >>     Hi Randy,
> >>
> >>     On 24/08/2015 20:20, Randy Presuhn wrote:
> >>
> >>         Hi -
> >>
> >>             From: Ladislav Lhotka >
> >>             Sent: Aug 24, 2015 11:44 AM
> >>             To: Andy Bierman  >>             >
> >>             Cc: "netmod@ietf.org "
> >>             >
> >>             Subject: Re: [netmod] Y26 again, sorry
> >>
> >>         ...
> >>
> >>                 YANG does not provide any mechanism to REQUIRE modules
> >>                 A and B
> >>                 to both be implemented on a server.  You may think it
> >>                 should, but
> >>                 currently the YANG conformance is for an individual
> >>                 module.
> >>
> >>             There are sections on conformance and conformance
> >>             announcement,
> >>             and they say nothing like this. In my view, the data model
> >>             comprises
> >>             *all* modules advertised by the server. I think your
> >>             interpretation
> >>             of conformance might be an extrapolation from SNMP/SMI
> >>             times, but,
> >>             for better or worse, it really has no support in the YANG
> >>             spec.
> >>
> >>         It sounds as though you might be talking past each other.
> >>         I believe part of Andy's point is that clients will need to deal
> >>         with servers that do not implement (and thus do not advertise)
> >>         the augmenting module.  But there's (I think) a more interesting
> >>         issue beneath this.
> >>
> >>         Let's start with module M.  Let's say M is for "modem" (to pick
> >>         an obsolete but widely understood resource).
> >>         Two different augmenting modules, F (for FSK - frequency
> >>         shift keying) and Q (for QAM - quadrature amplitude modulation)
> >>         are developed.  Let us say that F and Q are mutually incompatible.
> >>
> >>         A system with multiple Ms could well have both M+F and M+Q modems,
> >>         but (if we claim F & Q are incompatible) could not have M+F+Q.
> >>         If naked M is to be prohibited in systems (also) supporting F or Q
> >>         or both, we don't currently have a mechanism to do so.
> >>
> >>     Could this be achieved by augmenting from a choice statement?
> >>
> >>     M defines the choice statement but with no case statements.
> >>
> >>     F and Q both implement separate case statements that augment the
> >>     choice statement in M.  The case statements have containers which
> >>     hold the parameters related to F or Q.
> >>
> >>     M without F or Q is meaningless.
> >>     M+F or M+Q works, but the choice statement means that you cannot
> >>     have M+F+Q.
> >>
> >>
> >> nice solution
> >>
> >> This is perhaps the cleanest way to add mandatory nodes to a module.
> >> The old client will not attempt to create the new case.
> >>
> >> As I said before, I am OK with changing MUST NOT to SHOULD NOT
> >> add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
> >>
> >> Two conditions so far:
> >>
> >>     (1)  augment + when 
> >>
> >>     (2) augment choice with a new case-stmt
> >>
> >> (1) is hard to define, but not (2)
> >
> > So, Lada is using (2) for DNS zones which works.  Does the Y26 text need 
> > to be updated to explicitly allow this, or is this implicitly allowed 
> > anyway?
> 
> It is allowed in YANG 1.0.
> 
> >
> > Unfortunately (2) won't work for my model augmentation issue, of wanting 
> > to enforce that a sub-interface has to have a parent interface-ref.
> > As
> 
> ietf-interfaces could also use the same mandatory choice pattern but
> it seems too late now. This is an example why the strict module update rules
> are counter-productive at this stage - instead if adopting the best current
> practice we have to resort to kludges.

Can you explain what you would like to do with ietf-interfaces, and
why that is not allowed according to the upgrade rules?


/martin


From nobody Tue Sep  8 06:25:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0EC1B4939 for ; Tue,  8 Sep 2015 06:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.939
X-Spam-Level: *
X-Spam-Status: No, score=1.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MANGLED_FORM=2.3, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI_GOR2r6196 for ; Tue,  8 Sep 2015 06:25:05 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E694E1B4919 for ; Tue,  8 Sep 2015 06:25:04 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:b08b:d237:db0c:4f30] (unknown [IPv6:2001:1488:fffe:6:b08b:d237:db0c:4f30]) by mail.nic.cz (Postfix) with ESMTPSA id 8DFEA181747; Tue,  8 Sep 2015 15:25:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441718702; bh=IDXBmFhpbaJ9vq+pWeY8UABVZ34legi79Ub8t9NxHyA=; h=From:Date:To; b=HOKPbPaLKagrFxy/dz7ioz5ulY2FUfg8P53l4fi5Rw/OjHJWNMwHdfTAywR7/o/2d /pX86E244z4dqU5AhNZv9nBVgbRP/C930a5zb0ZZ0TTikelldsa8DoxUatv/HtTNdm EoDATfzyetXliocei8I9X48cmXupifkdfADfFV04=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150908.105044.1498048855200206331.mbj@tail-f.com>
Date: Tue, 8 Sep 2015 15:25:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <55EDC5D7.2050407@cisco.com>  <20150908.105044.1498048855200206331.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 13:25:07 -0000

> On 08 Sep 2015, at 10:50, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Robert Wilton  writes:
>>=20
>>> Hi Andy,
>>>=20
>>> Picking up a slightly old thread after PTO ...
>>>=20
>>> On 24/08/2015 22:50, Andy Bierman wrote:
>>>>=20
>>>>=20
>>>> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton >>> > wrote:
>>>>=20
>>>>    Hi Randy,
>>>>=20
>>>>    On 24/08/2015 20:20, Randy Presuhn wrote:
>>>>=20
>>>>        Hi -
>>>>=20
>>>>            From: Ladislav Lhotka >
>>>>            Sent: Aug 24, 2015 11:44 AM
>>>>            To: Andy Bierman >>>            >
>>>>            Cc: "netmod@ietf.org "
>>>>            >
>>>>            Subject: Re: [netmod] Y26 again, sorry
>>>>=20
>>>>        ...
>>>>=20
>>>>                YANG does not provide any mechanism to REQUIRE =
modules
>>>>                A and B
>>>>                to both be implemented on a server.  You may think =
it
>>>>                should, but
>>>>                currently the YANG conformance is for an individual
>>>>                module.
>>>>=20
>>>>            There are sections on conformance and conformance
>>>>            announcement,
>>>>            and they say nothing like this. In my view, the data =
model
>>>>            comprises
>>>>            *all* modules advertised by the server. I think your
>>>>            interpretation
>>>>            of conformance might be an extrapolation from SNMP/SMI
>>>>            times, but,
>>>>            for better or worse, it really has no support in the =
YANG
>>>>            spec.
>>>>=20
>>>>        It sounds as though you might be talking past each other.
>>>>        I believe part of Andy's point is that clients will need to =
deal
>>>>        with servers that do not implement (and thus do not =
advertise)
>>>>        the augmenting module.  But there's (I think) a more =
interesting
>>>>        issue beneath this.
>>>>=20
>>>>        Let's start with module M.  Let's say M is for "modem" (to =
pick
>>>>        an obsolete but widely understood resource).
>>>>        Two different augmenting modules, F (for FSK - frequency
>>>>        shift keying) and Q (for QAM - quadrature amplitude =
modulation)
>>>>        are developed.  Let us say that F and Q are mutually =
incompatible.
>>>>=20
>>>>        A system with multiple Ms could well have both M+F and M+Q =
modems,
>>>>        but (if we claim F & Q are incompatible) could not have =
M+F+Q.
>>>>        If naked M is to be prohibited in systems (also) supporting =
F or Q
>>>>        or both, we don't currently have a mechanism to do so.
>>>>=20
>>>>    Could this be achieved by augmenting from a choice statement?
>>>>=20
>>>>    M defines the choice statement but with no case statements.
>>>>=20
>>>>    F and Q both implement separate case statements that augment the
>>>>    choice statement in M.  The case statements have containers =
which
>>>>    hold the parameters related to F or Q.
>>>>=20
>>>>    M without F or Q is meaningless.
>>>>    M+F or M+Q works, but the choice statement means that you cannot
>>>>    have M+F+Q.
>>>>=20
>>>>=20
>>>> nice solution
>>>>=20
>>>> This is perhaps the cleanest way to add mandatory nodes to a =
module.
>>>> The old client will not attempt to create the new case.
>>>>=20
>>>> As I said before, I am OK with changing MUST NOT to SHOULD NOT
>>>> add mandatory nodes, and then add MAY when X, Y, Z conditions are =
met.
>>>>=20
>>>> Two conditions so far:
>>>>=20
>>>>    (1)  augment + when 
>>>>=20
>>>>    (2) augment choice with a new case-stmt
>>>>=20
>>>> (1) is hard to define, but not (2)
>>>=20
>>> So, Lada is using (2) for DNS zones which works.  Does the Y26 text =
need=20
>>> to be updated to explicitly allow this, or is this implicitly =
allowed=20
>>> anyway?
>>=20
>> It is allowed in YANG 1.0.
>>=20
>>>=20
>>> Unfortunately (2) won't work for my model augmentation issue, of =
wanting=20
>>> to enforce that a sub-interface has to have a parent interface-ref.
>>> As
>>=20
>> ietf-interfaces could also use the same mandatory choice pattern but
>> it seems too late now. This is an example why the strict module =
update rules
>> are counter-productive at this stage - instead if adopting the best =
current
>> practice we have to resort to kludges.
>=20
> Can you explain what you would like to do with ietf-interfaces, and
> why that is not allowed according to the upgrade rules?


list interface {
    key name;
    leaf name { =E2=80=A6 }
    leaf type { =E2=80=A6 }
    choice interface-parameters {
        mandatory true;
    }
}

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Sep  8 07:09:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DF81B4A51 for ; Tue,  8 Sep 2015 07:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.21
X-Spam-Level: 
X-Spam-Status: No, score=-12.21 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, MANGLED_FORM=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwS_VKXbucf7 for ; Tue,  8 Sep 2015 07:09:38 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC4B1B4A5D for ; Tue,  8 Sep 2015 07:09:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10829; q=dns/txt; s=iport; t=1441721378; x=1442930978; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=/atD0TCjV/jtKXUGbfwjEzaqXoa7ekSzFzABk3yNLJQ=; b=LJCGKgKErxKrPraz3rOqhIIZnVNCFc+UPMWBBx9F14nJqg4rJo5xXVBd lk/LgIQcWWHGBZrKkhk4Umjtn0HzY7pS8cjw5rdRhrgxYMl/hBaXW+5qv ODYNlv9dbYhIe8hSLuZgTqM6qfIt3hDf+2dJBedjn6dga5FT+FhmsxVCD g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BDAgDL6+5V/xbLJq1dg3dpvSoBCYdwAoFpFAEBAQEBAQGBCoQjAQEBBHgBEAsRBAEBAQkWCAcJAwIBAgE0CQgGAQwGAgEBF4gTym0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOEe4RBSweELAWVVYx6gUyHL44Qg2wmghAcgVU9M4hJAQEB
X-IronPort-AV: E=Sophos;i="5.17,490,1437436800";  d="scan'208,217";a="611468038"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 08 Sep 2015 14:09:25 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t88E9OOn018225; Tue, 8 Sep 2015 14:09:25 GMT
To: Ladislav Lhotka , Andy Bierman 
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com> 
From: Robert Wilton 
Message-ID: <55EEEC14.5000701@cisco.com>
Date: Tue, 8 Sep 2015 15:09:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040105060208090300000900"
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 14:09:40 -0000

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

Hi Lada,

On 08/09/2015 09:16, Ladislav Lhotka wrote:
> Robert Wilton  writes:
>
>> Hi Andy,
>>
>> Picking up a slightly old thread after PTO ...
>>
>> On 24/08/2015 22:50, Andy Bierman wrote:
>>>
>>> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton >> > wrote:
>>>
>>>      Hi Randy,
>>>
>>>      On 24/08/2015 20:20, Randy Presuhn wrote:
>>>
>>>          Hi -
>>>
>>>              From: Ladislav Lhotka >
>>>              Sent: Aug 24, 2015 11:44 AM
>>>              To: Andy Bierman >>              >
>>>              Cc: "netmod@ietf.org "
>>>              >
>>>              Subject: Re: [netmod] Y26 again, sorry
>>>
>>>          ...
>>>
>>>                  YANG does not provide any mechanism to REQUIRE modules
>>>                  A and B
>>>                  to both be implemented on a server.  You may think it
>>>                  should, but
>>>                  currently the YANG conformance is for an individual
>>>                  module.
>>>
>>>              There are sections on conformance and conformance
>>>              announcement,
>>>              and they say nothing like this. In my view, the data model
>>>              comprises
>>>              *all* modules advertised by the server. I think your
>>>              interpretation
>>>              of conformance might be an extrapolation from SNMP/SMI
>>>              times, but,
>>>              for better or worse, it really has no support in the YANG
>>>              spec.
>>>
>>>          It sounds as though you might be talking past each other.
>>>          I believe part of Andy's point is that clients will need to deal
>>>          with servers that do not implement (and thus do not advertise)
>>>          the augmenting module.  But there's (I think) a more interesting
>>>          issue beneath this.
>>>
>>>          Let's start with module M.  Let's say M is for "modem" (to pick
>>>          an obsolete but widely understood resource).
>>>          Two different augmenting modules, F (for FSK - frequency
>>>          shift keying) and Q (for QAM - quadrature amplitude modulation)
>>>          are developed.  Let us say that F and Q are mutually incompatible.
>>>
>>>          A system with multiple Ms could well have both M+F and M+Q modems,
>>>          but (if we claim F & Q are incompatible) could not have M+F+Q.
>>>          If naked M is to be prohibited in systems (also) supporting F or Q
>>>          or both, we don't currently have a mechanism to do so.
>>>
>>>      Could this be achieved by augmenting from a choice statement?
>>>
>>>      M defines the choice statement but with no case statements.
>>>
>>>      F and Q both implement separate case statements that augment the
>>>      choice statement in M.  The case statements have containers which
>>>      hold the parameters related to F or Q.
>>>
>>>      M without F or Q is meaningless.
>>>      M+F or M+Q works, but the choice statement means that you cannot
>>>      have M+F+Q.
>>>
>>>
>>> nice solution
>>>
>>> This is perhaps the cleanest way to add mandatory nodes to a module.
>>> The old client will not attempt to create the new case.
>>>
>>> As I said before, I am OK with changing MUST NOT to SHOULD NOT
>>> add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
>>>
>>> Two conditions so far:
>>>
>>>      (1)  augment + when 
>>>
>>>      (2) augment choice with a new case-stmt
>>>
>>> (1) is hard to define, but not (2)
>> So, Lada is using (2) for DNS zones which works.  Does the Y26 text need
>> to be updated to explicitly allow this, or is this implicitly allowed
>> anyway?
> It is allowed in YANG 1.0.

I was thinking that this would still fall foul of the RFC 6020 section 
7.15 rule:

    If the target node is in another module, then nodes added by the
    augmentation MUST NOT be mandatory nodes (seeSection 3.1 <#section-3.1>).


But presumably, this statement is only intended to refer to the top 
level nodes that are by added by the augmentation statement rather than 
all nodes that are being added (which the current wording seems to imply 
to me).

Thanks,
Rob


--------------040105060208090300000900
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Lada,

    

    
On 08/09/2015 09:16, Ladislav Lhotka
      wrote:

    

    

      
Robert Wilton <rwilton@cisco.com> writes:



      

        
Hi Andy,

Picking up a slightly old thread after PTO ...

On 24/08/2015 22:50, Andy Bierman wrote:


        

          

On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton <rwilton@cisco.com 
<mailto:rwilton@cisco.com>> wrote:

    Hi Randy,

    On 24/08/2015 20:20, Randy Presuhn wrote:

        Hi -

            From: Ladislav Lhotka <lhotka@nic.cz <mailto:lhotka@nic.cz>>
            Sent: Aug 24, 2015 11:44 AM
            To: Andy Bierman <andy@yumaworks.com
            <mailto:andy@yumaworks.com>>
            Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"
            <netmod@ietf.org <mailto:netmod@ietf.org>>
            Subject: Re: [netmod] Y26 again, sorry

        ...

                YANG does not provide any mechanism to REQUIRE modules
                A and B
                to both be implemented on a server.  You may think it
                should, but
                currently the YANG conformance is for an individual
                module.

            There are sections on conformance and conformance
            announcement,
            and they say nothing like this. In my view, the data model
            comprises
            *all* modules advertised by the server. I think your
            interpretation
            of conformance might be an extrapolation from SNMP/SMI
            times, but,
            for better or worse, it really has no support in the YANG
            spec.

        It sounds as though you might be talking past each other.
        I believe part of Andy's point is that clients will need to deal
        with servers that do not implement (and thus do not advertise)
        the augmenting module.  But there's (I think) a more interesting
        issue beneath this.

        Let's start with module M.  Let's say M is for "modem" (to pick
        an obsolete but widely understood resource).
        Two different augmenting modules, F (for FSK - frequency
        shift keying) and Q (for QAM - quadrature amplitude modulation)
        are developed.  Let us say that F and Q are mutually incompatible.

        A system with multiple Ms could well have both M+F and M+Q modems,
        but (if we claim F & Q are incompatible) could not have M+F+Q.
        If naked M is to be prohibited in systems (also) supporting F or Q
        or both, we don't currently have a mechanism to do so.

    Could this be achieved by augmenting from a choice statement?

    M defines the choice statement but with no case statements.

    F and Q both implement separate case statements that augment the
    choice statement in M.  The case statements have containers which
    hold the parameters related to F or Q.

    M without F or Q is meaningless.
    M+F or M+Q works, but the choice statement means that you cannot
    have M+F+Q.


nice solution

This is perhaps the cleanest way to add mandatory nodes to a module.
The old client will not attempt to create the new case.

As I said before, I am OK with changing MUST NOT to SHOULD NOT
add mandatory nodes, and then add MAY when X, Y, Z conditions are met.

Two conditions so far:

    (1)  augment + when <new flag set that old client will not set>

    (2) augment choice with a new case-stmt

(1) is hard to define, but not (2)


        

        
So, Lada is using (2) for DNS zones which works.  Does the Y26 text need 
to be updated to explicitly allow this, or is this implicitly allowed 
anyway?


      

      
It is allowed in YANG 1.0.

    

    

    I was thinking that this would still fall foul of the RFC 6020
    section 7.15 rule:

    

    
   If the target node is in another module, then nodes added by the
   augmentation MUST NOT be mandatory nodes (see Section 3.1).

    

    But presumably, this statement is only intended to refer to the top
    level nodes that are by added by the augmentation statement rather
    than all nodes that are being added (which the current wording seems
    to imply to me).

    

    Thanks,

    Rob

    

  


--------------040105060208090300000900--


From nobody Tue Sep  8 07:11:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6421B4A5D for ; Tue,  8 Sep 2015 07:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSeVQKNC9T16 for ; Tue,  8 Sep 2015 07:11:36 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5450F1B4AA8 for ; Tue,  8 Sep 2015 07:11:30 -0700 (PDT)
Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.262.15; Tue, 8 Sep 2015 14:11:28 +0000
Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.221]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.221]) with mapi id 15.01.0262.011; Tue, 8 Sep 2015 14:11:28 +0000
From: Kent Watsen 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting
Thread-Index: AQHQ6kBAYks95lEvP0q9a5Q+kmzibg==
Date: Tue, 8 Sep 2015 14:11:28 +0000
Message-ID: 
References: <20150901142936.GA60706@elstar.local>  <20150904165458.GB33792@elstar.local> <20150907.093127.2206391057777456319.mbj@tail-f.com>
In-Reply-To: <20150907.093127.2206391057777456319.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:RM80rSY/AR+GfGeqJHCCtvHCxcv5+FIo+JxahoOqInRfQvcYFrCeYIcRdEWSq9+9A9JLNKw4aSidDVPsgbC0WJTZTuyKXuPEZcWRqJxdaKCm9vSLNSnDrnLsUGRGjYrbcCf8QLhBDftit07tmeKq8g==; 24:iFRzdWBC52VCWqbTkxFkZbR8K7x9IUAy5yPBNLRvMcqvSxGvphqx2/JwG8/jRFCP4lqWU99qeTSK2xw7cyZBhbvCysNYuX7z2N5jhvVkAJQ=; 20:faZSEpSRFcQCcLAr/q+lv+JOThc7hE2oGNnpCSBJXZj8hQomhMDYcRJV9NACatfsWw6dKYONMMTVhEtP7952ig==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; 
x-forefront-prvs: 069373DFB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5423002)(24454002)(377454003)(46034005)(479174004)(377424004)(5002640100001)(68736005)(97736004)(76176999)(92566002)(19580395003)(102836002)(15975445007)(99286002)(106116001)(62966003)(64706001)(189998001)(11100500001)(66066001)(2950100001)(46102003)(50986999)(106356001)(4001540100001)(81156007)(105586002)(5007970100001)(19580405001)(4001350100001)(86362001)(5001960100002)(230783001)(36756003)(5001830100001)(87936001)(5001770100001)(101416001)(83506001)(2900100001)(122556002)(5004730100002)(54356999)(10400500002)(77156002)(93886004)(5001860100001)(2501003)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <92BA43D8B09B5B4EAB1E6949736D4C21@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2015 14:11:28.3374 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 14:11:42 -0000

On 9/7/15, 3:31 AM, "Martin Bjorklund"  wrote:

>Juergen Schoenwaelder  wrote:
>> On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote:
>> > Hi,
>> >=20
>> > Is there a WEB page that lists all the upcoming virtual meetings?
>> > This would really help people remember without scanning lots of
>> > ietf-announce email.
>> >
>>=20
>> The official list of interim meetings is here:
>>=20
>>     https://www.ietf.org/meeting/interim.html
>>=20
>> Yes, you have to search for NETMOD and no I am not aware of a nicer
>> list directly linked to say the NETMOD WG pages (or even a calendar
>> file).
>
>Hmm, I thought we're having a virtual interim on the opstate issue
>this thursday (2015-09-10), but it is not listed here.  Maybe I missed
>something.  Can the chairs clarify this?

There is an interim meeting planned for this Thursday the 10th on opstate.
 Tom sent a WebEx invite to the list, but didn't schedule it via the
meeting manager tool, which is why it doesn't show up in the URL above.
We hope to have this rectified shortly.

Kent



From nobody Tue Sep  8 08:01:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9D61B3884 for ; Tue,  8 Sep 2015 08:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHfKTjU_gSI5 for ; Tue,  8 Sep 2015 08:01:39 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 257C81B4B16 for ; Tue,  8 Sep 2015 08:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441724425; bh=pjWECzwXr4qjnTCrEHTMHB7r5QD7mNMRP1rvoRLt5nw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=eE7rCmLRJ7lXAKp6sJ74xOcCxNmOzyZwOGZy4cTrtJhon+GMLmtXC77wffZOXjVUM MajrSZUX00HlqlrskDxbZWo6O+xoIjgTIoqT8Avda3T8T2N8kpGzXHGTGbmI5b5RLh Q/to94rcHI/nSVzirLiIQ4WnRxeob4Kx1RUyJKIs=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Tue, 8 Sep 2015 11:00:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150901142936.GA60706@elstar.local>  <20150904165458.GB33792@elstar.local> <20150907.093127.2206391057777456319.mbj@tail-f.com> 
To: Kent Watsen 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 116, in=1525, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 15:01:45 -0000

> On Sep 8, 2015:10:11 AM, at 10:11 AM, Kent Watsen =
 wrote:
>=20
>=20
>=20
> On 9/7/15, 3:31 AM, "Martin Bjorklund"  wrote:
>=20
>> Juergen Schoenwaelder  wrote:
>>> On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote:
>>>> Hi,
>>>>=20
>>>> Is there a WEB page that lists all the upcoming virtual meetings?
>>>> This would really help people remember without scanning lots of
>>>> ietf-announce email.
>>>>=20
>>>=20
>>> The official list of interim meetings is here:
>>>=20
>>>    https://www.ietf.org/meeting/interim.html
>>>=20
>>> Yes, you have to search for NETMOD and no I am not aware of a nicer
>>> list directly linked to say the NETMOD WG pages (or even a calendar
>>> file).
>>=20
>> Hmm, I thought we're having a virtual interim on the opstate issue
>> this thursday (2015-09-10), but it is not listed here.  Maybe I =
missed
>> something.  Can the chairs clarify this?
>=20
> There is an interim meeting planned for this Thursday the 10th on =
opstate.
> Tom sent a WebEx invite to the list, but didn't schedule it via the
> meeting manager tool, which is why it doesn't show up in the URL =
above.
> We hope to have this rectified shortly.
>=20
> Kent

	I filed for that last week.  I posted the URL just now to this =
thread. I do not understand why the meeting does not appear in the =
interim tool view.

	=E2=80=94Tom


>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Sep  8 08:41:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F81B43CC for ; Tue,  8 Sep 2015 08:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKRf14yuXh0D for ; Tue,  8 Sep 2015 08:40:53 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 A1C3D1B42A2 for ; Tue,  8 Sep 2015 08:40:53 -0700 (PDT)
Received: by ykei199 with SMTP id i199so124533338yke.0 for ; Tue, 08 Sep 2015 08:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OAuDPptlTDufepzih3xH15cvUrwui4VxjwG0qy4sObc=; b=RfjGeZ8f9n5KCm0Chd5ctYyBJ8L6pcMf9NP6Hdd4qG9kSodQrUwVu5Ii2f/RHWHUux QVoCS7LF8N+EJeElqVjKwG2mdqi1trAU7ySZbSF1AUoOKfbew+iPUk/KrUIDPQFCPmLm vD4cc8z7onJgZ7Zs45+mBbQ8FRRrcFi3zm6lQYRGORJydcPfl4qZBSgRXlnX4H7sY/kK L1YqYvk0dZoNRbBr3PTLNJBCpA1aaFoj7w44ilrguEkuRH3hcePbPt7B9HmoMBMpEo3S k/BuSsx6HWgqrWtRTweJy3CadynVTmF3Qzq00sAU5t4f4SDFEWmgkTbd/kl3l/QZJRF7 kTxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OAuDPptlTDufepzih3xH15cvUrwui4VxjwG0qy4sObc=; b=R9lfL19V3cxvwLGZGMbXPqDGSRQtcvsP87d7p0DBihchIz1l2YL/1KNOn0htIQf/bd Xv4hb+G7zGeMBn2UZ/DmBSgVKe1Z3aknukHDTr2eNQfohPdXZDg96mB0GIicsSw3VCci 5w4rG4JczyY2hlru1QaubNml8sazUH/nXmQSAOAJwgAh8Um+Mzy2KkSFxrh5j5wtTm8C iyg3NR5MiNuXX6FUAWU30EaOKzDFNxoHhD6C+bR2kafc6OCvORQmGr0E5WuJDnoC8b0U PEGGFX867C7aY7qKI9SHOzyQ10ceVn6TCx7ZhsIj1xI9GepMOspSUoQTeJoS7d/gzojS gg/A==
X-Gm-Message-State: ALoCoQlNZbIKUB3hhhG6bZSHJf+CP4dCOz6Rk4XByPtUKS4OXOMY3LyCqzxIQ2vD0PApgHwnHfvp
MIME-Version: 1.0
X-Received: by 10.129.90.214 with SMTP id o205mr27827768ywb.32.1441726852730;  Tue, 08 Sep 2015 08:40:52 -0700 (PDT)
Received: by 10.31.170.195 with HTTP; Tue, 8 Sep 2015 08:40:52 -0700 (PDT)
In-Reply-To: <20150907114027.GD29605@elstar.local>
References:  <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <20150902.124254.850446502172825615.mbj@tail-f.com> <55E6F6D8.1060405@labn.net>   <20150907114027.GD29605@elstar.local>
Date: Tue, 8 Sep 2015 08:40:52 -0700
Message-ID: 
From: Paul Borman 
To: Juergen Schoenwaelder , Paul Borman ,  Andy Bierman , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114914b4ec17eb051f3e3084
Archived-At: 
Subject: Re: [netmod] logical systems model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 15:41:00 -0000

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

Instance identification does not really work by putting 'names' into
paths. Neither in NETCONF nor in RESTCONF. If your starting point is

> based on wrong assumptions, then the conclusions may be wrong as well.


XPATH has a mechanism for putting them in, but for demonstration the layout
of the tree it is much clearer to use the very standard idiom of normal
path names.  I believe I even pointed out that my path names were not in
the correct form, but that is irrelevant to the issue.

On Mon, Sep 7, 2015 at 4:40 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Sep 02, 2015 at 08:59:14AM -0700, Paul Borman wrote:
> > It depends on if you want to be able to just use YANG for schemas, or if
> > you want to force people to use another mechanism on top of YANG to make
> it
> > flexible enough for complete schemas.
> >
> > For example, an interfaces schema may end up with paths like (I am not
> > using full prefixed YANG paths, so please don't be confused by that):
> >
> > /interfaces/eth0/...
> >
> > But, if you want to report everything about a device, you would probably
> > want:
> >
> > /device/interfaces/eth0/..
> > /device/protocols/tcp/...
> >
> > Now step back, you actually want to contain everything about all your
> > devices:
> >
> > /router1.me.com/interfaces/eth0/...
> > /router2.me.com/interfaces/eth1/...
>
> Instance identification does not really work by putting 'names' into
> paths. Neither in NETCONF nor in RESTCONF. If your starting point is
> based on wrong assumptions, then the conclusions may be wrong as well.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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


Instance identification does not really work by putti=
ng 'names' into
paths. Neither in NETCONF nor in RESTCONF. If yo=
ur starting point is
based on wrong assumptions, then t=
he conclusions may be wrong as well.

XPATH=
 has a mechanism for putting them in, but for demonstration the layout of t=
he tree it is much clearer to use the very standard idiom of normal path na=
mes.=C2=A0 I believe I even pointed out that my path names were not in the =
correct form, but that is irrelevant to the issue.

On Mon, Sep 7, 2015 at 4:40 AM, Juergen Sc=
hoenwaelder <j.schoenwaelder@jacobs-university.de&g=
t; wrote:
On Wed, Sep 02, 2015 =
at 08:59:14AM -0700, Paul Borman wrote:

> It depends on if you want to be able to just use YANG for schemas, or =
if

> you want to force people to use another mechanism on top of YANG to ma=
ke it

> flexible enough for complete schemas.

>

> For example, an interfaces schema may end up with paths like (I am not=


> using full prefixed YANG paths, so please don't be confused by tha=
t):

>

> /interfaces/eth0/...

>

> But, if you want to report everything about a device, you would probab=
ly

> want:

>

> /device/interfaces/eth0/..

> /device/protocols/tcp/...

>

> Now step back, you actually want to contain everything about all your<=
br>
> devices:

>

> /router1.me.com/interfaces/eth0/...

> /router2.me.com/interfaces/eth1/...



Instance identification does not really work by putting 'names&#=
39; into

paths. Neither in NETCONF nor in RESTCONF. If your starting point is

based on wrong assumptions, then the conclusions may be wrong as well.



/js



--

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 | 28759 Br=
emen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt=
p://www.jacobs-university.de/>





--001a114914b4ec17eb051f3e3084--


From nobody Tue Sep  8 08:50:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C4B1B4B76 for ; Tue,  8 Sep 2015 08:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.311
X-Spam-Level: 
X-Spam-Status: No, score=-11.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, MANGLED_FORM=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn_6YVk5kVzV for ; Tue,  8 Sep 2015 08:49:49 -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 285061B39C6 for ; Tue,  8 Sep 2015 08:48:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5530; q=dns/txt; s=iport; t=1441727338; x=1442936938; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vTW3RZed3MrcS7Ar9+FPGOeWGzF8V92xHXtzJqqOMa4=; b=L96oSlGeNWS0KbQenrAasCgxIpIeftUbkcS9B+/zAB/KF+R+obagSNv4 3TYZ9iqzLHiXEtR0WGFoJPaNN7Ya8fwtzFfb+FtuvODDmYfNsuQY0MEgg QBU6I5c6qY33J7ToeXtX/H57Sre4zbjy9aVYlwUEQk4x/dEUxc0Ffehoz c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DVBABbAu9V/xbLJq1dhGCDJMIAAoIBAQEBAQEBgQuEIwEBAQMBIw8BBTwEARALEQQBAQECAgUWCAMCAgkDAgECATQJCAYBDAYCAQEXiAsItyKUAQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIoVRg3aBBYRBSweCaYFDAQSMd4hejHqBTIcviUeESYNsJoIQHIFVPTOISQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="scan'208";a="604987653"
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; 08 Sep 2015 15:48:56 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t88Fmtx8010312; Tue, 8 Sep 2015 15:48:56 GMT
To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= 
References:  <55EDC5D7.2050407@cisco.com>  <20150908.105044.1498048855200206331.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: <55EF0367.4010301@cisco.com>
Date: Tue, 8 Sep 2015 16:48:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 15:49:52 -0000

On 08/09/2015 14:25, Ladislav Lhotka wrote:
>> On 08 Sep 2015, at 10:50, Martin Bjorklund  wrote:
>>
>> Ladislav Lhotka  wrote:
>>> Robert Wilton  writes:
>>>
>>>> Hi Andy,
>>>>
>>>> Picking up a slightly old thread after PTO ...
>>>>
>>>> On 24/08/2015 22:50, Andy Bierman wrote:
>>>>>
>>>>> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton >>>> > wrote:
>>>>>
>>>>>     Hi Randy,
>>>>>
>>>>>     On 24/08/2015 20:20, Randy Presuhn wrote:
>>>>>
>>>>>         Hi -
>>>>>
>>>>>             From: Ladislav Lhotka >
>>>>>             Sent: Aug 24, 2015 11:44 AM
>>>>>             To: Andy Bierman >>>>             >
>>>>>             Cc: "netmod@ietf.org "
>>>>>             >
>>>>>             Subject: Re: [netmod] Y26 again, sorry
>>>>>
>>>>>         ...
>>>>>
>>>>>                 YANG does not provide any mechanism to REQUIRE modules
>>>>>                 A and B
>>>>>                 to both be implemented on a server.  You may think it
>>>>>                 should, but
>>>>>                 currently the YANG conformance is for an individual
>>>>>                 module.
>>>>>
>>>>>             There are sections on conformance and conformance
>>>>>             announcement,
>>>>>             and they say nothing like this. In my view, the data model
>>>>>             comprises
>>>>>             *all* modules advertised by the server. I think your
>>>>>             interpretation
>>>>>             of conformance might be an extrapolation from SNMP/SMI
>>>>>             times, but,
>>>>>             for better or worse, it really has no support in the YANG
>>>>>             spec.
>>>>>
>>>>>         It sounds as though you might be talking past each other.
>>>>>         I believe part of Andy's point is that clients will need to deal
>>>>>         with servers that do not implement (and thus do not advertise)
>>>>>         the augmenting module.  But there's (I think) a more interesting
>>>>>         issue beneath this.
>>>>>
>>>>>         Let's start with module M.  Let's say M is for "modem" (to pick
>>>>>         an obsolete but widely understood resource).
>>>>>         Two different augmenting modules, F (for FSK - frequency
>>>>>         shift keying) and Q (for QAM - quadrature amplitude modulation)
>>>>>         are developed.  Let us say that F and Q are mutually incompatible.
>>>>>
>>>>>         A system with multiple Ms could well have both M+F and M+Q modems,
>>>>>         but (if we claim F & Q are incompatible) could not have M+F+Q.
>>>>>         If naked M is to be prohibited in systems (also) supporting F or Q
>>>>>         or both, we don't currently have a mechanism to do so.
>>>>>
>>>>>     Could this be achieved by augmenting from a choice statement?
>>>>>
>>>>>     M defines the choice statement but with no case statements.
>>>>>
>>>>>     F and Q both implement separate case statements that augment the
>>>>>     choice statement in M.  The case statements have containers which
>>>>>     hold the parameters related to F or Q.
>>>>>
>>>>>     M without F or Q is meaningless.
>>>>>     M+F or M+Q works, but the choice statement means that you cannot
>>>>>     have M+F+Q.
>>>>>
>>>>>
>>>>> nice solution
>>>>>
>>>>> This is perhaps the cleanest way to add mandatory nodes to a module.
>>>>> The old client will not attempt to create the new case.
>>>>>
>>>>> As I said before, I am OK with changing MUST NOT to SHOULD NOT
>>>>> add mandatory nodes, and then add MAY when X, Y, Z conditions are met.
>>>>>
>>>>> Two conditions so far:
>>>>>
>>>>>     (1)  augment + when 
>>>>>
>>>>>     (2) augment choice with a new case-stmt
>>>>>
>>>>> (1) is hard to define, but not (2)
>>>> So, Lada is using (2) for DNS zones which works.  Does the Y26 text need
>>>> to be updated to explicitly allow this, or is this implicitly allowed
>>>> anyway?
>>> It is allowed in YANG 1.0.
>>>
>>>> Unfortunately (2) won't work for my model augmentation issue, of wanting
>>>> to enforce that a sub-interface has to have a parent interface-ref.
>>>> As
>>> ietf-interfaces could also use the same mandatory choice pattern but
>>> it seems too late now. This is an example why the strict module update rules
>>> are counter-productive at this stage - instead if adopting the best current
>>> practice we have to resort to kludges.
>> Can you explain what you would like to do with ietf-interfaces, and
>> why that is not allowed according to the upgrade rules?
>
> list interface {
>      key name;
>      leaf name { … }
>      leaf type { … }
>      choice interface-parameters {
>          mandatory true;
>      }
> }

I'm not sure that it helps for my sub-interface parent leaf problem, 
since I would ideally like the same parent-if-ref leaf to exist for 
multiple if:types (e.g. Frame, ATM, VLANs) with the same namespace. But 
unless VLANs  + ATM + Frame Relay are all defined in the same module 
(which wouldn't seem a very natural thing to do) then they would end up 
in different namespaces, and hence not be so usable.

Thanks,
Rob


>
> Lada
>
>>
>> /martin
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From nobody Tue Sep  8 10:14:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739641B4FED for ; Tue,  8 Sep 2015 10:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwOjdH4QEYrw for ; Tue,  8 Sep 2015 10:14:00 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453B61B4F3E for ; Tue,  8 Sep 2015 10:14:00 -0700 (PDT)
Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.262.15; Tue, 8 Sep 2015 17:13:56 +0000
Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.221]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.221]) with mapi id 15.01.0262.011; Tue, 8 Sep 2015 17:13:56 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: NomCom 2015: Call for nominations
Thread-Index: AQHQ6lm+Ft20vgOhHEOLuXQqQrJ6ZA==
Date: Tue, 8 Sep 2015 17:13:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; BN1PR05MB454; 5:cXZ0fbnMJUhY4G5y5ggfN4nCF0+U7DdeqUJRjOhlahogptGJFyeVmglhiOmkWY8w3BawYKD8ohb7zDTscrcHjLOiKadLph30nBzc6y7GCicq+GghgObgQXomvjK9ktrGKPdDme9E5LAuyAKVlGJAMg==; 24:p2F34Dm/ZB5MRKFvmh7ZFfD2vR3QVTism6jPoioSZSQWwiizgqI34p1OcUHj6hljsoGji+gt++jZvEfXActbzscBecX11s7P/bwNmsIJTEo=; 20:xW6AwKAIqJ40uCFC2Si76rf/1aIkcyhGTj+upX0YE6E4ScH0V66byNhrCSG6EV8OzxcegPgahr4dM2QWpCGW8A==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; 
x-forefront-prvs: 069373DFB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(40764003)(24454002)(377454003)(479174004)(68736005)(5002640100001)(97736004)(92566002)(107886002)(19580395003)(102836002)(15975445007)(106116001)(62966003)(189998001)(64706001)(99286002)(66066001)(11100500001)(50986999)(46102003)(110136002)(81156007)(106356001)(105586002)(4001540100001)(5007970100001)(19580405001)(86362001)(5001960100002)(4001350100001)(450100001)(36756003)(87936001)(5001830100001)(54356999)(83506001)(122556002)(5004730100002)(2351001)(10400500002)(77156002)(2900100001)(5001860100001)(101416001)(2501003)(40100003)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <68BB6A01371740489D4C5B0B1594FBDC@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2015 17:13:56.5635 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454
Archived-At: 
Subject: [netmod] FW: NomCom 2015: Call for nominations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 17:14:02 -0000

All,

Please see below the Call for Nominations from NomCom 2015. Please help
NomCom and the IETF community by proposing the best candidates for the
open positions. This is important for the IETF and the industry.

Thanks!
Kent




On 9/8/15, 3:11 AM, "Benoit Claise"  wrote:

>Dear OPS chairs,
>
>Please make sure your WG/community is aware of (the importance of) this
>message.
>
>Regards, Benoit
>
>-------- Forwarded Message --------
>Subject: 	NomCom 2015: Call for nominations
>Date: 	Wed, 26 Aug 2015 03:13:13 -0700
>From: 	NomCom Chair 2015 
>Reply-To: 	ietf@ietf.org, nomcom15@ietf.org
>To: 	IETF Announcement List 
>CC: 	ietf@ietf.org
>
>
>
>The 2015-16 Nominating Committee (Nomcom) is seeking nominations from
>now until October 8, 2015. The open positions being considered by this
>year's Nomcom can be found at the end of this email and also on this
>year's Nomcom website:
>
>https://datatracker.ietf.org/nomcom/2015/
>
>Nominations may be made by selecting the Nominate link at the top of
>the Nomcom 2015 home page, or by visiting the following URL:
>
>https://datatracker.ietf.org/nomcom/2015/nominate/
>
>   {Note that nominations made using the web tool require an ietf.org
>    datatracker account. You can create a datatracker ietf.org account
>    if you don't have one already by visiting the following URL:
>    https://datatracker.ietf.org/accounts/create/  }
>
>If you are unable to use the web form, nominations may instead be made
>by email tonomcom15@ietf.org. If using email, please include the word
>"Nominate" in the Subject and indicate in the email who is being
>nominated, their email address (to confirm acceptance of the
>nomination), and the position for which you are making the nomination.
>If you are nominating someone other than yourself, please tell us if
>we may tell the nominee that you were the one who made the nomination.
>If you wish to nominate someone via email for more than one position,
>please use separate emails to do so.
>
>Self-nomination is welcome!
>
>NomCom 2015-16 will follow the policy for "Open Disclosure of Willing
>Nominees" described in BCP 10/RFC 7437.  As stated in RFC 7437: "The
>list of nominees willing to be considered for positions under review
>in the current Nomcom cycle is not confidential". Willing nominees for
>each position will be listed in a publicly accessible way - anyone
>with a datatracker account may access the lists.  Additionally, the
>nomination form asks if we may share your own name with the
>nominee. In all other ways, the confidentiality requirements of BCP10
>remain in effect.  All feedback and all Nomcom deliberations will
>remain confidential and will not be disclosed.
>
>There is a field on the form you can mark in order to allow the Nomcom
>to tell the nominee that you were the one who made the
>nomination. This is a new thing this year, and it defaults to =B3no=B2 -
>we won=B9t tell. After the nomination cycle, we will evaluate the result
>of this and recommend whether the next Nomcom should do something
>different.
>
>In order to ensure time to collect sufficient community feedback about
>each of the willing nominees, nominations must be received by the
>Nomcom on or before October 8, 2015.
>
>Please submit your nominations as early as possible for the sake of
>your nominees. Note that nominations should not wait for management
>permission, as it is easier to decline the nomination than put one in
>late.  We have set the questionnaire submission deadline for October
>15, 2015.
>
>The Nomcom appoints individuals to fill the open slots on the IAOC,
>the IAB, and the IESG. The list of people and posts whose terms end
>with the March 2016 IETF meeting, and thus the positions for which
>this Nomcom is responsible, follows:
>
>IAB:
>* Mary Barnes
>* Joe Hildebrand
>* Ted Hardie
>* Erik Nordmark
>* Brian Trammell
>* Mark Blanchet
>
>IESG:
>- Alissa Cooper, ART
>- Barry Leiba, ART
>- Brian Haberman, Internet (*)
>- Benoit Claise, O&M
>- Alia Atlas, Routing
>- Kathleen Moriarty, Security
>- Martin Stiemerling, Transport (*)
>
>*- have indicated that they do not intend to accept a
>renomination. This information is always up to date on
>https://datatracker.ietf.org/nomcom/2015/
>
>Please be resourceful in identifying possible candidates for these
>positions, as developing our talent is a very crucial requirement for
>the IETF, and also, please consider accepting a nomination.  You'll
>find extensive information about specific positions, developed by the
>IAB, IESG, and IAOC, under individual tabs at:
>
>   https://datatracker.ietf.org/nomcom/2015/requirements/
>
>In addition to nominations, the Nomcom seeks community input on the
>positions themselves.  We need and welcome the community's views and
>input on the jobs within each organization. If you have ideas on the
>positions' responsibilities (more, less, different), please let us
>know.
>
>Please send suggestions and feedback about this tonomcom15@ietf.org.
>
>Thank you for your help in identifying qualified nominees!
>
>Harald Alvestrand
>Nomcom Chair 2015-16
>nomcom-chair-2015@ietf.org,hta+nomcom@alvestrand.no
>


From nobody Tue Sep  8 10:47:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DC41A9241 for ; Tue,  8 Sep 2015 10:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.761
X-Spam-Level: 
X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_25=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o0y6s6Ggj0U for ; Tue,  8 Sep 2015 10:47:54 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F080A1A892B for ; Tue,  8 Sep 2015 10:47:53 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 267F6180A66; Tue,  8 Sep 2015 19:47:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441734471; bh=h61BvMlM1M2ysCWy+8bGLbw7d4Oqc41J/FjA7ZZcz3Q=; h=From:Date:To; b=bKaCtXHc8tLEcnjTucJ09LPkMuyIYkMaiNJBgVTgvheQzHG8scMMBxr7Q4rznln/m xvdawpfw6QGpOS+gU/pDAE6RtwWUmVWQEkw8Q/xn8YhFtOOQQQKTXVBCzss4873wod EiQgMfv/0MGAmME9WzK9w1lYWzfd1Kh7WN0hQQGo=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <55EF0367.4010301@cisco.com>
Date: Tue, 8 Sep 2015 19:47:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <13D9FE67-44AE-4410-AB7D-3F5B71961834@nic.cz>
References:  <55EDC5D7.2050407@cisco.com>  <20150908.105044.1498048855200206331.mbj@tail-f.com>  <55EF0367.4010301@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Sep 2015 17:47:56 -0000

> On 08 Sep 2015, at 17:48, Robert Wilton  wrote:
>=20
>=20
>=20
> On 08/09/2015 14:25, Ladislav Lhotka wrote:
>>> On 08 Sep 2015, at 10:50, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>> Robert Wilton  writes:
>>>>=20
>>>>> Hi Andy,
>>>>>=20
>>>>> Picking up a slightly old thread after PTO ...
>>>>>=20
>>>>> On 24/08/2015 22:50, Andy Bierman wrote:
>>>>>>=20
>>>>>> On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton >>>>> > wrote:
>>>>>>=20
>>>>>>    Hi Randy,
>>>>>>=20
>>>>>>    On 24/08/2015 20:20, Randy Presuhn wrote:
>>>>>>=20
>>>>>>        Hi -
>>>>>>=20
>>>>>>            From: Ladislav Lhotka >
>>>>>>            Sent: Aug 24, 2015 11:44 AM
>>>>>>            To: Andy Bierman >>>>>            >
>>>>>>            Cc: "netmod@ietf.org "
>>>>>>            >
>>>>>>            Subject: Re: [netmod] Y26 again, sorry
>>>>>>=20
>>>>>>        ...
>>>>>>=20
>>>>>>                YANG does not provide any mechanism to REQUIRE =
modules
>>>>>>                A and B
>>>>>>                to both be implemented on a server.  You may think =
it
>>>>>>                should, but
>>>>>>                currently the YANG conformance is for an =
individual
>>>>>>                module.
>>>>>>=20
>>>>>>            There are sections on conformance and conformance
>>>>>>            announcement,
>>>>>>            and they say nothing like this. In my view, the data =
model
>>>>>>            comprises
>>>>>>            *all* modules advertised by the server. I think your
>>>>>>            interpretation
>>>>>>            of conformance might be an extrapolation from SNMP/SMI
>>>>>>            times, but,
>>>>>>            for better or worse, it really has no support in the =
YANG
>>>>>>            spec.
>>>>>>=20
>>>>>>        It sounds as though you might be talking past each other.
>>>>>>        I believe part of Andy's point is that clients will need =
to deal
>>>>>>        with servers that do not implement (and thus do not =
advertise)
>>>>>>        the augmenting module.  But there's (I think) a more =
interesting
>>>>>>        issue beneath this.
>>>>>>=20
>>>>>>        Let's start with module M.  Let's say M is for "modem" (to =
pick
>>>>>>        an obsolete but widely understood resource).
>>>>>>        Two different augmenting modules, F (for FSK - frequency
>>>>>>        shift keying) and Q (for QAM - quadrature amplitude =
modulation)
>>>>>>        are developed.  Let us say that F and Q are mutually =
incompatible.
>>>>>>=20
>>>>>>        A system with multiple Ms could well have both M+F and M+Q =
modems,
>>>>>>        but (if we claim F & Q are incompatible) could not have =
M+F+Q.
>>>>>>        If naked M is to be prohibited in systems (also) =
supporting F or Q
>>>>>>        or both, we don't currently have a mechanism to do so.
>>>>>>=20
>>>>>>    Could this be achieved by augmenting from a choice statement?
>>>>>>=20
>>>>>>    M defines the choice statement but with no case statements.
>>>>>>=20
>>>>>>    F and Q both implement separate case statements that augment =
the
>>>>>>    choice statement in M.  The case statements have containers =
which
>>>>>>    hold the parameters related to F or Q.
>>>>>>=20
>>>>>>    M without F or Q is meaningless.
>>>>>>    M+F or M+Q works, but the choice statement means that you =
cannot
>>>>>>    have M+F+Q.
>>>>>>=20
>>>>>>=20
>>>>>> nice solution
>>>>>>=20
>>>>>> This is perhaps the cleanest way to add mandatory nodes to a =
module.
>>>>>> The old client will not attempt to create the new case.
>>>>>>=20
>>>>>> As I said before, I am OK with changing MUST NOT to SHOULD NOT
>>>>>> add mandatory nodes, and then add MAY when X, Y, Z conditions are =
met.
>>>>>>=20
>>>>>> Two conditions so far:
>>>>>>=20
>>>>>>    (1)  augment + when 
>>>>>>=20
>>>>>>    (2) augment choice with a new case-stmt
>>>>>>=20
>>>>>> (1) is hard to define, but not (2)
>>>>> So, Lada is using (2) for DNS zones which works.  Does the Y26 =
text need
>>>>> to be updated to explicitly allow this, or is this implicitly =
allowed
>>>>> anyway?
>>>> It is allowed in YANG 1.0.
>>>>=20
>>>>> Unfortunately (2) won't work for my model augmentation issue, of =
wanting
>>>>> to enforce that a sub-interface has to have a parent =
interface-ref.
>>>>> As
>>>> ietf-interfaces could also use the same mandatory choice pattern =
but
>>>> it seems too late now. This is an example why the strict module =
update rules
>>>> are counter-productive at this stage - instead if adopting the best =
current
>>>> practice we have to resort to kludges.
>>> Can you explain what you would like to do with ietf-interfaces, and
>>> why that is not allowed according to the upgrade rules?
>>=20
>> list interface {
>>     key name;
>>     leaf name { =E2=80=A6 }
>>     leaf type { =E2=80=A6 }
>>     choice interface-parameters {
>>         mandatory true;
>>     }
>> }
>=20
> I'm not sure that it helps for my sub-interface parent leaf problem, =
since I would ideally like the same parent-if-ref leaf to exist for =
multiple if:types (e.g. Frame, ATM, VLANs) with the same namespace. But =
unless VLANs  + ATM + Frame Relay are all defined in the same module =
(which wouldn't seem a very natural thing to do) then they would end up =
in different namespaces, and hence not be so usable.

This could probably be done by defining an interface type as kind of =
superclass for all interface types that need parent-if-ref and then =
derive all concrete interface types (Frame Relay, ATM, VLANs) from it. A =
corresponding augment then would be, e.g.,

augment =E2=80=9C/if:interfaces/if:interface/if:interface-parameters/=E2=80=
=9C {
    when =E2=80=9Cderived-from(../if:type, =E2=80=98mymod=E2=80=99, =
=E2=80=98child-interface=E2=80=99)=E2=80=9D;
    container child-interface {
        leaf parent-if-ref {=E2=80=A6}
    }
}

Concrete interface types could then add specific nodes by augmenting the =
child-interface container.

Lada

>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>> /martin
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> .

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Sep  8 23:16:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721921B3FE1 for ; Tue,  8 Sep 2015 23:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoiceKhfAMZA for ; Tue,  8 Sep 2015 23:16:30 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEAE1B3FD7 for ; Tue,  8 Sep 2015 23:16:30 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2C2441CC0181 for ; Wed,  9 Sep 2015 08:16:26 +0200 (CEST)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: 
References: 
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 09 Sep 2015 08:16:26 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] data tree
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 06:16:32 -0000

Hi,

Andy argued that the proposed new definition of data tree looks like it
is a big tree containing everything, so here is another try,
improvements are welcome:

o data tree: An instantiated tree of any data modeled with YANG, i.e.,
  one of: configuration, state data, combined configuration and state
  data, RPC input, RPC output, notification.

Lada

Ladislav Lhotka  writes:

>
>   OLD
>
>      o  data tree: The instantiated tree of configuration and state data
> 	on a device.
>
>   NEW
>
>      o data tree: The instantiated tree of configuration, state data,
>        combined configuration and state data, RPC input or output, or
>        notification.
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep  8 23:28:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116C91A9154 for ; Tue,  8 Sep 2015 23:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlqaDUm6iVk3 for ; Tue,  8 Sep 2015 23:28:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 928FF1A1BC6 for ; Tue,  8 Sep 2015 23:28:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EAD81AE0703; Wed,  9 Sep 2015 08:28:11 +0200 (CEST)
Date: Wed, 09 Sep 2015 08:28:10 +0200 (CEST)
Message-Id: <20150909.082810.104733136913643670.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] data tree
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 06:28:14 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> Andy argued that the proposed new definition of data tree looks like it
> is a big tree containing everything, so here is another try,
> improvements are welcome:
> 
> o data tree: An instantiated tree of any data modeled with YANG, i.e.,
>   one of: configuration, state data, combined configuration and state
>   data, RPC input, RPC output, notification.

Looks good to me, with s/RPC/RPC or action/g


/martin


From nobody Tue Sep  8 23:35:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C631B3884 for ; Tue,  8 Sep 2015 23:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvD786r7YVWX for ; Tue,  8 Sep 2015 23:35:19 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8B11B385C for ; Tue,  8 Sep 2015 23:35:19 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:c9c5:e353:c6f1:8aa0] (unknown [IPv6:2001:718:1a02:1:c9c5:e353:c6f1:8aa0]) by mail.nic.cz (Postfix) with ESMTPSA id 0B281181742 for ; Wed,  9 Sep 2015 08:35:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441780517; bh=3q4+rUN+EoRZ9JKtZjjnte3WbNqVc/vMdPwstovTMUk=; h=From:Date:To; b=kEgdZrE4YCdh/K/ongR+8+HYIbFN0NXOtxAQ3HRcXCqZco6wTdlzlIP5guomjPX/h CxZol9Vi9qUZdAJsgBx6cA8mkCtkW+Zr7Ah2oKGbZGeeE25PT1uDo0fxE7NakH7zLz EsyVF2MMnVDkrU8XvE8dEBiiY/Xo1zagfuYHiNCc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150909.082810.104733136913643670.mbj@tail-f.com>
Date: Wed, 9 Sep 2015 08:35:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20150909.082810.104733136913643670.mbj@tail-f.com>
To: NETMOD Working Group 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] data tree
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 06:35:20 -0000

> On 09 Sep 2015, at 08:28, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> Andy argued that the proposed new definition of data tree looks like =
it
>> is a big tree containing everything, so here is another try,
>> improvements are welcome:
>>=20
>> o data tree: An instantiated tree of any data modeled with YANG, =
i.e.,
>>  one of: configuration, state data, combined configuration and state
>>  data, RPC input, RPC output, notification.
>=20
> Looks good to me, with s/RPC/RPC or action/g

Sure, I forgot about actions. Also, do we want to make provisions for =
using YANG outside this narrow scope, as it has been already done a few =
times? If so, we could change

s/i.e., one of:/for example/

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep  9 02:15:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128671B2BA9 for ; Wed,  9 Sep 2015 02:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVN7ZjyRBMSV for ; Wed,  9 Sep 2015 02:14:52 -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 72B081B2B96 for ; Wed,  9 Sep 2015 02:14:52 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C08A41402 for ; Wed,  9 Sep 2015 11:14:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pKwzfeuSG8qt for ; Wed,  9 Sep 2015 11:14:49 +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 for ; Wed,  9 Sep 2015 11:14:49 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4523E20053 for ; Wed,  9 Sep 2015 11:14:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eI6dQppxRwJO; Wed,  9 Sep 2015 11:14:47 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9942B2004E; Wed,  9 Sep 2015 11:14:47 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 000E13705374; Wed,  9 Sep 2015 11:14:41 +0200 (CEST)
Date: Wed, 9 Sep 2015 11:14:40 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20150909091440.GA34260@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] minutes of the NETMOD 2015-09-07 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 09:14:59 -0000

--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached are the minutes of the 2015-09-07 virtual interim meeting.
Please let me know if something needs fixing.

You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         

--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="netmod-2015-09-07-minutes.txt"

=============================================================
NETCONF Data Modeling Language WG (netmod)
20th YANG 1.1 Virtual Interim
Monday, September 7th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  AB = Andy Bierman
  G? = Gert ?
  IB = Ignas Bagdonas
  JS = Juergen Schoenwaelder
  LL = Ladislav Lhotka
  MB = Martin Bjorklund

* Data tree definition update (Martin, Lada)

  See Lada's email concerning the different uses of data tree.
  
  MB: I have done already most of the edits, but not yet checked in.
  AB: The new definition combines multiple different trees into one.
  LL: The wording may not be good enough, we should make it clear that
      a "," really means "or".

* Extension statements and deviate-stmt / refine-stmt (Andy)

  It seems groupings do not really anticipate extensions from an ABNF
  point of view.
	
  MB: I think the grammar is not the problem. But there is clearly
      text missing and also not all statements can be refined (you
      can't refine the type of a leaf for example).
  AB: Properties like config true/false are often introduced when a
      grouping is used instead of having this hardwired in groupings.
  AB: Groupings are somewhat fragile, you can't easily move them
      around, there are likely guidelines missing for groupings.
  MB: I propose to add text that extension statements can be added
      using a refine but the extension statement must define the rules.
  MB: If you define an ephemeral statement, then the definition of the
      statement must provide the details how it can be used.
  LL: Shall we have restrictions on what an extension can do and what
      it cannot do?
  AB: There is the understanding of the annotation statement and then
      there is the understanding of a specific defined annotation.
  MB: It is difficult to define rules that make sure
      extensions/annotations are backwards compatible.
  AB: The usage must be client initiated and how you do that depends on
      the specific circumstances.
  MB: There is already text in the language extension section:
	
	Care must be taken when defining extensions so that modules that use
	the extensions are meaningful also for applications that do not
	support the extensions.
	
  AB: I will work on good and bad extension examples and incorporate the
      text in the guidelines update.
  MB: I can help with that.
  LL: I will check that there is similar text in the metadata document.
  MB: I will add text concerning the refinements.

* Data tree ordering (Lada)

  LL: Is the data tree fundamentally unordered?
  MB: Yes, the ordering is in the encoding parts.
  
  Action: LL to check whether his comments have been resolved in the
          svn version.
	
* Title of the document (Martin)

  MB: Shall we remove "for the Network Configuration Protocol
      (NETCONF)" from the title?
  AB: I am concerned about people that want to use YANG for protocols
      they do not talk about and they may even want to change YANG.
  MB: The idea is to shorten the title and to leave it for the
      introduction to explain what YANG was designed for.
  JS: I am fine with a short title as long as there is clear text
      about the purpose of YANG and its applicability in the text.

* Coexistence issue - allow version 1 modules to import version 1.1 modules? (Martin)

  MB: It should be fine for a version 1.1 module to import from an
      version 1 module.
  MB: What about allowing version 1 modules to import from 1.1 modules?
  JS: What happens if a version 1 module augments an action defined in
      a version 1.1 module?
  MB: But how do we update inet-types.yang to 1.1?
  JS: Version 1 modules can keep using version 1 inet-types.yang until
      they want to use something present only in a newer revision.
  LL: But what about import without revision?
  LL: Submit an errata that a version 1 module can only import version 1 modules.
  MB: How would this be advertised in the yang library?
  MB: A (in 1) imports yang-types, B (in 1.1) imports yang-types,
      yang-types exists in version 1 and 1.1 - which version will be
      advertised?
  AB: It will have to be the latest.
  AB: I suggested that a version 1 module is parsed as a 1.1 module in
      a mixed implementation and then you are fine to import a 1.1 module.
  LL: I am fine with an automatic promotion.
  MB: What about relaxing the rules only for modules that predate YANG 1.1?
  AB: The server is going to have only one version, especially for configuration.
  
  Action: MB will start a thread on the mailing list and if needed we
          continue this discussion next Monday.

--+HP7ph2BbKc20aGI--


From nobody Wed Sep  9 08:25:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C991B3CCB for ; Wed,  9 Sep 2015 08:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfqKN3wpFWUP for ; Wed,  9 Sep 2015 08:25:32 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5D51B3C5F for ; Wed,  9 Sep 2015 08:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2779; q=dns/txt; s=iport; t=1441812326; x=1443021926; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=45YSGpWk0IYD4E5/fVKIv99r/LApJEe4rvPRBC9I5UU=; b=Ea7kEbHkVOi8ttq2qs0yknY3zG8hU/YHvmmuqdoWXeZdcqCNmvnFF6Wt 3ZCfakySGCm9s3BCQSu7dKtT4QYijNSprzMy7Zq6jDBGbUe2lyR2X+xut +P6ajFKIeyBOvlLI/wRckRfuHyK1lmVootZ9/5m2vOZSg2mhSCJpXLxGg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DMBABjTvBV/xbLJq1TCogEvyiCVgKCBAEBAQEBAYELhCQBAQQOFUITARALBBQJFgsCAgkDAgECAUUGDQgBAYgqtgOUOAEBAQEBAQEBAQEBAQEBAQEBAQEZhnOEe4QvXQeCaYFDBZIzgyOMeoFMhy+JSIRJg2wmhAE9iHwBAQE
X-IronPort-AV: E=Sophos;i="5.17,496,1437436800";  d="scan'208,217";a="606898375"
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; 09 Sep 2015 15:25:24 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t89FPOfc008973; Wed, 9 Sep 2015 15:25:24 GMT
To: Andy Bierman 
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com> 
From: Robert Wilton 
Message-ID: <55F04F64.7090607@cisco.com>
Date: Wed, 9 Sep 2015 16:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040604070807050109010905"
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 15:25:33 -0000

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

Hi Andy,

On 07/09/2015 18:41, Andy Bierman wrote:
>
> Your example shows the YANG conformance problems fairly well.
> Clearly the IETF (and others) want to use advanced design patterns
> in which conformance to the base module (M) is insufficient to describe
> the actual API requirements.
>
> YANG uses revision dates to identify versions.
> There is no such thing as a major vs. minor revision.
> I agree with Lada that it is possible to have major revision update
> where the old clients should not be used anymore.
>
> I already suggested relaxing the MUST NOT to a SHOULD NOT,
> wrt/ adding mandatory nodes.
I support that - it seems to strike the right pragmatic balance to me.

Thanks,
Rob


--------------040604070807050109010905
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Andy,

    

    
On 07/09/2015 18:41, Andy Bierman
      wrote:

    

    

      
      


        

          

            
Your example shows the YANG conformance problems fairly
              well.

            
Clearly the IETF (and others) want to use advanced
              design patterns

            
in which conformance to the base module (M) is
              insufficient to describe

            
the actual API requirements.

            


            

            
YANG uses revision dates to identify versions.

            
There is no such thing as a major vs. minor revision.

            
I agree with Lada that it is possible to have major
              revision update

            
where the old clients should not be used anymore.

            


            

            
I already suggested relaxing the MUST NOT to a SHOULD
              NOT,

            
wrt/ adding mandatory nodes.

          

        

      

    

    I support that - it seems to strike the right pragmatic balance to
    me.

    

    Thanks,

    Rob

    

  


--------------040604070807050109010905--


From nobody Wed Sep  9 11:56:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E01B2D02 for ; Wed,  9 Sep 2015 11:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9BJbYQN7FJS for ; Wed,  9 Sep 2015 11:56:40 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3551A871F for ; Wed,  9 Sep 2015 11:56:40 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 801BD180C6F; Wed,  9 Sep 2015 20:56:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441824998; bh=X+uUfDht8etLM4/o7uOr3bqZwPfYvb/PDY23gYjB63g=; h=From:Date:To; b=PLLivhyXo8d95gXtBypG+ZC5CuHraO+ljGcNVut2kJAp/SW/m//K/3IvdgkJwI3d3 iZ0TMk/vATEoJ7BNSCczVwOXAHyzsf3KOdNHOMe1KB0dMb9EqiRuyxwD8oJ2C2JmZm RGXoM2rMEFMdXIVYeEeA6Gt8zZyplSlM9Lg1DIUo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <55F04F64.7090607@cisco.com>
Date: Wed, 9 Sep 2015 20:56:42 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <9028ECD0-ED85-416D-AF47-634ED648349E@nic.cz>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com>  <55F04F64.7090607@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 18:56:42 -0000

> On 09 Sep 2015, at 17:25, Robert Wilton  wrote:
> 
> Hi Andy,
> 
> On 07/09/2015 18:41, Andy Bierman wrote:
>> 
>> Your example shows the YANG conformance problems fairly well.
>> Clearly the IETF (and others) want to use advanced design patterns
>> in which conformance to the base module (M) is insufficient to describe
>> the actual API requirements.
>> 
>> YANG uses revision dates to identify versions.
>> There is no such thing as a major vs. minor revision.
>> I agree with Lada that it is possible to have major revision update
>> where the old clients should not be used anymore.
>> 
>> I already suggested relaxing the MUST NOT to a SHOULD NOT,
>> wrt/ adding mandatory nodes.
> I support that - it seems to strike the right pragmatic balance to me.

I support that, too.

Lada

> 
> Thanks,
> Rob
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep  9 12:10:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A25E1B4076 for ; Wed,  9 Sep 2015 12:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u69EP7GoxxTy for ; Wed,  9 Sep 2015 12:10:48 -0700 (PDT)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 BC55F1B4060 for ; Wed,  9 Sep 2015 12:10:46 -0700 (PDT)
Received: by lamp12 with SMTP id p12so13148063lam.0 for ; Wed, 09 Sep 2015 12:10:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F4QruHAj1GWyIfCh1jOvD3+Gf1NGoCAmp+M4Imn+Wto=; b=YKRcBZE6+3vcPx14g2Ee/VddTH7RZIS/A7eD/1evY4LeAWxVi3qARcdVD3iyMGE9Pi jP8wHorGpQn7fFM4uLZYzXpzTJZUhgyfYziDVXqg6GC9cZo4K/sj7xJ6mi8cv4Lw6Ryv SB1acrRATyh3ZbTVlkhBzEsSiCuXCRLt6oE6CTcoxRaqp+DeFFPRiby/u49sRRxXXYKg ikTfPRGbeJWxU316HO6wZjj1VPEX6gce5EFKKCwVN1GGi49vr6iM+d4Yc/PRg8CgTgEP oLYb5dC8CNoU+CniZYrLt4g3WrzmjbpDqng3aK0J8Phl8TSSkLS1l3Axab27N+RXoZWh 3I3A==
X-Gm-Message-State: ALoCoQm6OknGG+ZQvVnf/gctRsYDHE+DhD41KXa3OmWeU44JVLJhv01TIXx4evUrHXbmZ/Q6VDS8
MIME-Version: 1.0
X-Received: by 10.152.36.200 with SMTP id s8mr3330203laj.119.1441825844820; Wed, 09 Sep 2015 12:10:44 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 9 Sep 2015 12:10:44 -0700 (PDT)
In-Reply-To: <9028ECD0-ED85-416D-AF47-634ED648349E@nic.cz>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com>  <55F04F64.7090607@cisco.com> <9028ECD0-ED85-416D-AF47-634ED648349E@nic.cz>
Date: Wed, 9 Sep 2015 12:10:44 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0160a9ca4f1807051f553d02
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 19:10:50 -0000

--089e0160a9ca4f1807051f553d02
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 9, 2015 at 11:56 AM, Ladislav Lhotka  wrote:

>
> > On 09 Sep 2015, at 17:25, Robert Wilton  wrote:
> >
> > Hi Andy,
> >
> > On 07/09/2015 18:41, Andy Bierman wrote:
> >>
> >> Your example shows the YANG conformance problems fairly well.
> >> Clearly the IETF (and others) want to use advanced design patterns
> >> in which conformance to the base module (M) is insufficient to describe
> >> the actual API requirements.
> >>
> >> YANG uses revision dates to identify versions.
> >> There is no such thing as a major vs. minor revision.
> >> I agree with Lada that it is possible to have major revision update
> >> where the old clients should not be used anymore.
> >>
> >> I already suggested relaxing the MUST NOT to a SHOULD NOT,
> >> wrt/ adding mandatory nodes.
> > I support that - it seems to strike the right pragmatic balance to me.
>
> I support that, too.
>
>

I don't think it really addresses the design pattern very well.

You want to claim that M and Q are both being developed at the same time,
so it's OK that Q adds mandatory nodes to M.  YANG has no such rule.
YANG says a server can implement M and never implement Q.
YANG says a server may implement M and then add Q in a future release.
These conformance mechanisms do not align with your expectations
of how YANG can/should be used.



> Lada
>
>
Andy


> >
> > Thanks,
> > Rob
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Wed, Sep 9, 2015 at 11:56 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 09 Sep 2015, at 17:25, Robert Wilton <rwilton@cisco.com> wrote:

>

> Hi Andy,

>

> On 07/09/2015 18:41, Andy Bierman wrote:

>>

>> Your example shows the YANG conformance problems fairly well.

>> Clearly the IETF (and others) want to use advanced design patterns=


>> in which conformance to the base module (M) is insufficient to des=
cribe

>> the actual API requirements.

>>

>> YANG uses revision dates to identify versions.

>> There is no such thing as a major vs. minor revision.

>> I agree with Lada that it is possible to have major revision updat=
e

>> where the old clients should not be used anymore.

>>

>> I already suggested relaxing the MUST NOT to a SHOULD NOT,

>> wrt/ adding mandatory nodes.

> I support that - it seems to strike the right pragmatic balance to me.=




I support that, too.




I don't think it re=
ally addresses the design pattern very well.

You w=
ant to claim that M and Q are both being developed at the same time,
<=
div>so it's OK that Q adds mandatory nodes to M.=C2=A0 YANG has no such=
 rule.
YANG says a server can implement M and never implement Q.<=
/div>
YANG says a server may implement M and then add Q in a future rel=
ease.
These conformance mechanisms do not align with your expecta=
tions
of how YANG can/should be used.

=
=C2=A0

Lada



Andy
=C2=A0

>

> Thanks,

> Rob

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--089e0160a9ca4f1807051f553d02--


From nobody Wed Sep  9 13:16:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EEF1B3C15 for ; Wed,  9 Sep 2015 13:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.51
X-Spam-Level: 
X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhtzTEe4cTDh for ; Wed,  9 Sep 2015 13:16:07 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCB01B3C09 for ; Wed,  9 Sep 2015 13:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19406; q=dns/txt; s=iport; t=1441829765; x=1443039365; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=MF1VNdc8s4OrjAZnZCJv+hOJjz+A1ixQEnbYSMdA01c=; b=WmXOL/pjGFxvwDot/TSbM0vXIiSxFqh6P5B8dRwp2YTwCAckcU/nAmZN n5u4HbQSQqtlOQn1hAYt9KtbhIO48Ur4zaEjEjfRpvahRD54AdCNwxkRn PVDx3VxKuUiwTgOosydcYzI9er3lSQ6t+EF9PE8QfhSCOeFyCBuiYSg3h 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BUAAASk/BV/xbLJq1DFwOCVoEhab0oAQ10BXQBC4UtSgKBehQBAQEBAQEBgQqEJAEBAgIBAQFjCAYEDwILIQsEBwUKCQMCAQIBCQwvAQMEDAYCAQEXiBMNO7smjmEBAQEBAQEEAQEBAQEBAQEBGQSGb4R7gT0Bgwo0FxIHhBMFlVaFCoU/gjGBTBUxg22CfCONboNsJoIQDQ8Wb1E8MwGISAEBAQ
X-IronPort-AV: E=Sophos;i="5.17,498,1437436800";  d="scan'208,217";a="611504634"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Sep 2015 20:16:03 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t89KG2PK015346; Wed, 9 Sep 2015 20:16:03 GMT
To: netmod-chairs@tools.ietf.org, netmod@ietf.org
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com>
From: Benoit Claise 
Message-ID: <55F09386.4030509@cisco.com>
Date: Wed, 9 Sep 2015 22:16:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55C4CCEC.4020209@cisco.com>
Content-Type: multipart/alternative; boundary="------------070404080306040304090800"
Archived-At: 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 20:16:09 -0000

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

Dear all,

There is a lot of passionate debates around YANG these days, which shows 
how important YANG became.

After the last IETF meeting, the openconfig group requested a call with me.
During that call, these operators re-explained their problem to me.

Let me decompose this into three parts, and again set the stage for this 
interim meeting tomorrow.

1. The problem statement.
When a group of operators come to the IETF with a problem, we should 
take this seriously and embrace it. In other words, nobody can dispute 
the operators problem statement.

2. The requirements.
If there are still clarifications needed around the requirements in 
draft-openconfig-netmod-opstate-01 section 4, or around the requirement 
that the YANG models need some sort of hierarchy 
(draft-openconfig-netmod-model-structure), like for the routing models, 
... tomorrow interim meeting is your chance, or between now and then on 
the mailing list.

3. The solution:
There are actually 3 different solutions for the operational state.
3.1 draft-openconfig-netmod-opstate-01, whose version 00 has already 
been presented/discussed
3.2 draft-kwatsen-netmod-opstate, not yet presented
3.3 draft-wilton-netmod-opstate-yang, not yet presented
Come prepared, and have read those drafts in advance.
This interim meeting should be about comparing solutions around the 
operational state solutions.

We also need understand whether solving those requirements within the 
context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or 
draft-wilton-netmod-opstate-yang) is satisfactory.

Regards, Benoit (OPS AD)
> Dear all,
>
> Let me set the stage for this future interim.
>
> First of (and let me repeat), I'm happy that the operators gathered 
> and collectively worked on YANG models and related requirements.
>
> The previous two interim meetings in June on the openconfig issues 
> (draft-openconfig-netmod-opstate-01 
>  and 
> draft-openconfig-netmod-model-structure-00 
> ) 
> were successful in the sense that the requirements are now understood.
>
> Unfortunately, some key players were not in Prague and we could not 
> finalize the discussion.
> How to represent the operational state is one important guidance from 
> RFC 6087bis that we must be providing to all existing and future YANG 
> models (and not only in the IETF).
>
> We need to bring closure on that topic, and this is the plan for that 
> interim meeting in September.
>
> http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has 
> been updated. Please comment on this version.
> Also, any alternate proposals must be prepared for that interim in 
> September. They must be prepared with the same level of rigour as 
> draft-openconfig-netmod-opstate., i.e. must have the same level of 
> details.
>
> In the meeting in September, the goal is to take a decision.
>
> Regards, Benoit (OPS AD)
>
>> Hello,
>> NETMOD Working Group invites you to join this WebEx meeting.
>>
>> *NETMOD Interm meeting on OpenConfig*
>> Thursday, September 10, 2015
>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
>>
>> *Join WebEx meeting* 
>>  
>>
>>
>> Meeting number: 	645 732 277
>> Meeting password: 	1234
>>
>> *Join by phone*
>> *1-877-668-4493* Call-in toll free number (US/Canada)
>> *1-650-479-3208* Call-in toll number (US/Canada)
>> Access code: 645 732 277
>> Toll-free calling restrictions 
>> 
>>
>> Add this meeting 
>>  
>> to your calendar.
>>
>> Can't join the meeting? Contact support. 
>> 
>>
>> IMPORTANT NOTICE: Please note that this WebEx service allows audio 
>> and other information sent during the session to be recorded, which 
>> may be discoverable in a legal matter. By joining this session, you 
>> automatically consent to such recordings. If you do not consent to 
>> being recorded, discuss your concerns with the host or do not join 
>> the session.
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
Dear all,

      

      There is a lot of passionate debates around YANG these days, which
      shows how important YANG became.

      

      After the last IETF meeting, the openconfig group requested a call
      with me.

      During that call, these operators re-explained their problem to
      me.

      

      Let me decompose this into three parts, and again set the stage
      for this interim meeting tomorrow. 

      

      1. The problem statement. 

      When a group of operators come to the IETF with a problem, we
      should take this seriously and embrace it. In other words, nobody
      can dispute the operators problem statement. 

      

      2. The requirements. 

      If there are still clarifications needed around the requirements
      in draft-openconfig-netmod-opstate-01 section 4, or around the
      requirement that the YANG models need some sort of hierarchy
      (draft-openconfig-netmod-model-structure), like for the routing
      models, ... tomorrow interim meeting is your chance, or between
      now and then on the mailing list.

      

      3. The solution: 

      There are actually 3 different solutions for the operational
      state.

      3.1 draft-openconfig-netmod-opstate-01, whose version 00 has
      already been presented/discussed

      3.2 draft-kwatsen-netmod-opstate, not yet presented

      3.3 draft-wilton-netmod-opstate-yang, not yet presented

      Come prepared, and have read those drafts in advance.

      This interim meeting should be about comparing solutions around
      the operational state solutions.

      

      We also need understand whether solving those requirements within
      the context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or
      draft-wilton-netmod-opstate-yang) is satisfactory.

      

      Regards, Benoit (OPS AD)

    

    

      
      
Dear all,

        

        Let me set the stage for this future interim.

        

        First of (and let me repeat), I'm happy that the operators
        gathered and collectively worked on YANG models and related
        requirements.

        

        The previous two interim meetings in June on the openconfig
        issues (draft-openconfig-netmod-opstate-01
        and draft-openconfig-netmod-model-structure-00)
        were successful in the sense that the requirements are now
        understood.

        

        Unfortunately, some key players were not in Prague and we could
        not finalize the discussion.

        How to represent the operational state is one important guidance
        from RFC 6087bis that we must be providing to all existing and
        future YANG models (and not only in the IETF). 

        

        We need to bring closure on that topic, and this is the plan for
        that interim meeting in September.

        

        http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/
        has been updated. Please comment on this version.

        Also, any alternate proposals must be prepared for that interim
        in September. They must be prepared with the same level of
        rigour as draft-openconfig-netmod-opstate., i.e. must have the
        same level of details.

        

        In the meeting in September, the goal is to take a decision. 

        

        Regards, Benoit (OPS AD)

        

      

      

        
        
        

          
            

              
                

                  
                    

                      
                        

                          
                            

                               Hello, 
                            

                            

                              
                                NETMOD Working Group invites you to join
                                this WebEx meeting. 
                            

                          
                        

                        

                          
                            

                              
                            

                          
                        

                        

                          
                            

                              
                                NETMOD Interm meeting on OpenConfig
                              
                            

                            

                              Thursday, September 10, 2015 
                            

                            

                              11:00 am|Eastern Daylight Time
                                (New York, GMT-04:00)|1 hr 
                            

                          
                        

                        

                          
                            

                              
                            

                          
                        

                        

                          
                            

                              
                                 Join
                                    WebEx meeting  
                            

                          
                        

                        

                          
                            

                               Meeting
                                number: 
                              645 732 277 
                            

                            

                              Meeting
                                password:
                              1234
                            

                          
                        

                        

                          
                            

                              
                            

                          
                        

                        

                          
                            

                              Join by
                                  phone
                            

                            

                              1-877-668-4493Call-in toll
                                free number (US/Canada)
                            

                            

                              1-650-479-3208Call-in toll
                                number (US/Canada)
                            

                            

                              Access code:645 732 277
                            

                            

                              Toll-free
                                  calling restrictions
                            

                          
                        

                        

                          
                            

                              
                            

                          
                        

                        

                          
                            

                              Add this meeting
                                to your calendar.
                            

                          
                        

                        

                          
                            

                              
                            

                          
                        

                        

                          
                            

                               Can't join the
                                meeting? 
                                  Contact support. 
                            

                          
                        

                        

                          
                            

                              
                            

                          
                        

                        

                          
                            

                              
                                IMPORTANT NOTICE: Please note that this
                                WebEx service allows audio and other
                                information sent during the session to
                                be recorded, which may be discoverable
                                in a legal matter. By joining this
                                session, you automatically consent to
                                such recordings. If you do not consent
                                to being recorded, discuss your concerns
                                with the host or do not join the
                                session.
                            

                          
                        

                      		
                    

                  
                

              		
            

          
        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------070404080306040304090800--


From nobody Wed Sep  9 13:44:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0D91B43B5 for ; Wed,  9 Sep 2015 13:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7563HeKb3yt for ; Wed,  9 Sep 2015 13:44:29 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0A81B43AD for ; Wed,  9 Sep 2015 13:44:25 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:1572:ed1f:1ddd:bab1] (unknown [IPv6:2a01:5e0:29:ffff:1572:ed1f:1ddd:bab1]) by mail.nic.cz (Postfix) with ESMTPSA id AD3B6180A1D; Wed,  9 Sep 2015 22:44:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441831463; bh=Oehono6ud6ZWq1aMi4EsA/OauD0ciilM6kk0j84VVmY=; h=From:Date:To; b=WyhlbnbfGLuyXhxfU3zWCVpoQkIGoe6FNYxxjQ3Y8Aa2k+kBVtpHF2/MieLdnhaM4 FJenNxJClGEWtDEi/bAQNIraa7rDvDKVlJEp86J4/wfdyEcLKx6VPHKFKaxNslhFf1 Z1Ck1x2KSI53tbfkNrbUaiPr/fOb5wln0Q0M2ZRM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 9 Sep 2015 22:44:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0982C3A5-7FF6-4A8E-875C-1057AD0E96D1@nic.cz>
References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com>  <55EDC5D7.2050407@cisco.com>  <55F04F64.7090607@cisco.com> <9028ECD0-ED85-416D-AF47-634ED648349E@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 20:44:31 -0000

> On 09 Sep 2015, at 21:10, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, Sep 9, 2015 at 11:56 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 09 Sep 2015, at 17:25, Robert Wilton  wrote:
> >
> > Hi Andy,
> >
> > On 07/09/2015 18:41, Andy Bierman wrote:
> >>
> >> Your example shows the YANG conformance problems fairly well.
> >> Clearly the IETF (and others) want to use advanced design patterns
> >> in which conformance to the base module (M) is insufficient to =
describe
> >> the actual API requirements.
> >>
> >> YANG uses revision dates to identify versions.
> >> There is no such thing as a major vs. minor revision.
> >> I agree with Lada that it is possible to have major revision update
> >> where the old clients should not be used anymore.
> >>
> >> I already suggested relaxing the MUST NOT to a SHOULD NOT,
> >> wrt/ adding mandatory nodes.
> > I support that - it seems to strike the right pragmatic balance to =
me.
>=20
> I support that, too.
>=20
>=20
>=20
> I don't think it really addresses the design pattern very well.
>=20
> You want to claim that M and Q are both being developed at the same =
time,
> so it's OK that Q adds mandatory nodes to M.  YANG has no such rule.
> YANG says a server can implement M and never implement Q.
> YANG says a server may implement M and then add Q in a future release.
> These conformance mechanisms do not align with your expectations
> of how YANG can/should be used.

There seems to be an impedance mismatch between us at this point. You =
are saying that a server can implement ietf-interfaces only. That=E2=80=99=
s correct but the server implementor can easily see that it doesn=E2=80=99=
t make much sense because nothing very useful can be done with it. So =
what?

It is similar to the situation before OS software packages were =
introduced: One had to know (or read in the documentation, or later in =
the output of a configure script) that package X needs either Y or Z to =
work correctly, and install one of them beforehand. It was more =
laborious but one could make things work even then.

It would be great to have a formalism that allows for stating that =
module M requires Q, but I think multi-module data models can be =
designed and effectively used without it.

Issue Y26 is about something else, namely allowing an augmenting module =
Q to introduce mandatory nodes, and if the server advertises both M and =
Q, the client should get the message that the nodes from Q are =
mandatory.

The formulation =E2=80=9CA module SHOULD NOT augment another with =
mandatory nodes=E2=80=9D is indeed an acceptable compromise - nodes that =
positively need to be mandatory can be tagged as =E2=80=9Cmandatory =
true=E2=80=9D.

Lada

>=20
> =20
> Lada
>=20
>=20
> Andy
> =20
> >
> > Thanks,
> > Rob
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep  9 14:28:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE91B2B94 for ; Wed,  9 Sep 2015 14:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPP90eTuzpVA for ; Wed,  9 Sep 2015 14:28:53 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DFF1A884B for ; Wed,  9 Sep 2015 14:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2109; q=dns/txt; s=iport; t=1441834133; x=1443043733; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=fckz//sGVUauF1/r2yuZ3+uMdn1hQpS8u1pxU7CiyOE=; b=Q6JAo7szsG2mGgtD7ILmTd3lp68JHPrkat2yf3vhadjHL0IMjCvWorUJ dj4PjhXoQEvhgD6EHjo0L6WOPm53WzmaqYXoVg7S7EpCEqI+ynxjaP0HJ mzr3ht5ZS87Awblrqpy0f0iaujbWPegkrnwQIVVM9G4d6cYK8ms0EKU3W A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DIAQCRo/BV/xbLJq1dhGC9KAENh3ACgXwUAQEBAQEBAYEKhCQBAQQ4PBULEAgJJQ8CRgYBDAYCAQEXiBPLCgEBAQEBAQEBAgEBAQEBARyGc4R7hROELAEElVaMeoFMhDOCfJF9JoQCPDOISQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,499,1437436800"; d="scan'208";a="611505578"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Sep 2015 21:28:51 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t89LSoDw029029; Wed, 9 Sep 2015 21:28:50 GMT
To: Andy Bierman , "netmod@ietf.org" 
References: <20150807063205.GA75724@elstar.local> <55C4D1AD.8070402@cisco.com> <20150807155712.GA255@elstar.local>  <20150809075020.GA4480@elstar.local>
From: Benoit Claise 
Message-ID: <55F0A495.905@cisco.com>
Date: Wed, 9 Sep 2015 23:28:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150809075020.GA4480@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 21:28:55 -0000

[sorry for the delay. August vacation]

See in-line.
> On Fri, Aug 07, 2015 at 09:22:41AM -0700, Andy Bierman wrote:
>> On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>>> Lets please not mix YANG 1.1 work with other discussions at this point
>>> in time.
>>>
>>>
>> I would really like the WG and IESG to decide how YANG is going to be
>> updated to support ephemeral state and operational state.
>>
>> It seems there are many documents waiting on YANG 1.1, yet
>> only 1 or 2 actually use anything from YANG 1.1.
>>
>> If YANG 1.0 is not being deprecated then I do not see
>> any reason to link documents to YANG 1.1 unless they
>> actually use it.
>>
>> Is the plan to start work on YANG 1.2 before YANG 1.1 is even published?
>> If so, then say so.  Let's not pretend YANG is stable
>> or that all new improvements after YANG 1.1 are going to be
>> done with extension hacks.
>>
>> If the IESG and the WG had a development plan for this work,
>> it might help vendors decide when and what to support.
>>
> I can't speak for the IESG, I can't speak for the WG - the WG has to
> speak first.
>
> My personal goal is to complete YANG 1.1 with the feature set that we
> all worked on hard during that last year. I believe in the value of
> finishing something.
I would support this.

Regards, Benoit
> The alternative is to keep YANG 1.1 a moving
> target for at least another year to come (and likely even longer, who
> knows which wishes comes next and how long it takes to settle all the
> semantic issues with ephemeral state).
>
> Since the solution direction for ephemeral state is not even set yet
> (and ephemeral state might not even be a feature that every
> NETCONF/RESTCONF implementation may choose to support), I would rather
> work with YANG extensions as long as possible (and if not possible,
> consider alternatives such as YANG 1.2 once we 'understand the
> edits'). At this stage, my personal preference is to finish YANG 1.1
> with the feature set that we have now.
>
> /js
>


From nobody Wed Sep  9 14:40:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78961B478E for ; Wed,  9 Sep 2015 14:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.978
X-Spam-Level: 
X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3tIwid1o3Lq for ; Wed,  9 Sep 2015 14:40:47 -0700 (PDT)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 698241B478B for ; Wed,  9 Sep 2015 14:40:46 -0700 (PDT)
Received: by laeb10 with SMTP id b10so16108070lae.1 for ; Wed, 09 Sep 2015 14:40:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fOoM8yS2+1i+JqWqGh/4yjO3cmfqvAR8N+1qKRrhJvc=; b=GtqS0/CMxT/nA6vxYjR5dMjk6OYe6r/8vueuiazq5JXf8pXe9/sb0tad0YgJZHZg6q vcLBQ3bHMcQuNw72hlZtS65g46hzwJhPstMjomA0Xae4Nl9uI01gD0WlnJxzPKPPn5LR EmmfmWdUxU5+YXS0WPpJ3vR0Tg8BxMJwsj+cwz4iq1voLrMRYR+TqEIoie21eKG09pWJ Cz1V28gka7/v1Lotx09VYWplh+DW3U1bOmnfU/uiTFOz0Man00Jz+4IQWPP+oA8nFTlb fBsYy0w3+0tch5MJg6fpXhls29N4ThydPmP6hgWNIBkVkO9phEzMwA0XhKw5pz+zsYuv xI1g==
X-Gm-Message-State: ALoCoQnMB7e8m5soFETS0nK34jXcREb8g5SwgnCW2ctjlsSxRozedbgHcpWP0MAXu6J8p6HgQxbM
MIME-Version: 1.0
X-Received: by 10.112.161.232 with SMTP id xv8mr31260389lbb.123.1441834844435;  Wed, 09 Sep 2015 14:40:44 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 9 Sep 2015 14:40:44 -0700 (PDT)
In-Reply-To: <55F09386.4030509@cisco.com>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com>
Date: Wed, 9 Sep 2015 14:40:44 -0700
Message-ID: 
From: Andy Bierman 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=001a11c3c46cba557b051f5755a9
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 21:40:54 -0000

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

On Wed, Sep 9, 2015 at 1:16 PM, Benoit Claise  wrote:

> Dear all,
>
> There is a lot of passionate debates around YANG these days, which shows
> how important YANG became.
>
> After the last IETF meeting, the openconfig group requested a call with me.
> During that call, these operators re-explained their problem to me.
>
> Let me decompose this into three parts, and again set the stage for this
> interim meeting tomorrow.
>
> 1. The problem statement.
> When a group of operators come to the IETF with a problem, we should take
> this seriously and embrace it. In other words, nobody can dispute the
> operators problem statement.
>
> 2. The requirements.
> If there are still clarifications needed around the requirements in
> draft-openconfig-netmod-opstate-01 section 4, or around the requirement
> that the YANG models need some sort of hierarchy
> (draft-openconfig-netmod-model-structure), like for the routing models, ...
> tomorrow interim meeting is your chance, or between now and then on the
> mailing list.
>
>

My concern with the problem statement and the requirements in sec. 4 is
that they focus
on very large systems, yet these problems do not exist on small systems.
YANG is being considered in the CORE WG.  If and when the CoMI charter
addition
is approved then YANG will need to support constrained devices.

Common modules like ietf-interfaces need to scale well.  IMO the authors
of RFC 7223 did a great job of not imposing any requirements that assume
use-cases or platform resources.  All common modules need to be
designed the same way.

I have yet to hear a number wrt/ how many seconds or minutes does it
usually take
for intended config to become active config?  What percentage of all
devices that
use YANG have this problem?  How fast is the data expected to change while
the client is polling it?  The solution should not impact systems that do
not have
these problems that appear to be related to the very large or complex
configurations.

Andy



> 3. The solution:
> There are actually 3 different solutions for the operational state.
> 3.1 draft-openconfig-netmod-opstate-01, whose version 00 has already been
> presented/discussed
> 3.2 draft-kwatsen-netmod-opstate, not yet presented
> 3.3 draft-wilton-netmod-opstate-yang, not yet presented
> Come prepared, and have read those drafts in advance.
> This interim meeting should be about comparing solutions around the
> operational state solutions.
>
> We also need understand whether solving those requirements within the
> context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or
> draft-wilton-netmod-opstate-yang) is satisfactory.
>
> Regards, Benoit (OPS AD)
>
> Dear all,
>
> Let me set the stage for this future interim.
>
> First of (and let me repeat), I'm happy that the operators gathered and
> collectively worked on YANG models and related requirements.
>
> The previous two interim meetings in June on the openconfig issues (
> draft-openconfig-netmod-opstate-01
>  and
> draft-openconfig-netmod-model-structure-00
> )
> were successful in the sense that the requirements are now understood.
>
> Unfortunately, some key players were not in Prague and we could not
> finalize the discussion.
> How to represent the operational state is one important guidance from RFC
> 6087bis that we must be providing to all existing and future YANG models
> (and not only in the IETF).
>
> We need to bring closure on that topic, and this is the plan for that
> interim meeting in September.
>
> http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has been
> updated. Please comment on this version.
> Also, any alternate proposals must be prepared for that interim in
> September. They must be prepared with the same level of rigour as
> draft-openconfig-netmod-opstate., i.e. must have the same level of details.
>
> In the meeting in September, the goal is to take a decision.
>
> Regards, Benoit (OPS AD)
>
> Hello, NETMOD Working Group invites you to join this WebEx meeting.   *NETMOD
> Interm meeting on OpenConfig* Thursday, September 10, 2015 11:00
> am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr   *Join WebEx
> meeting*
>  Meeting
> number: 645 732 277 Meeting password: 1234   *Join by phone*
> *1-877-668-4493* Call-in toll free number (US/Canada) *1-650-479-3208* Call-in
> toll number (US/Canada) Access code: 645 732 277 Toll-free calling
> restrictions    Add
> this meeting
> 
> to your calendar.   Can't join the meeting? Contact support.
>    IMPORTANT NOTICE: Please note that
> this WebEx service allows audio and other information sent during the
> session to be recorded, which may be discoverable in a legal matter. By
> joining this session, you automatically consent to such recordings. If you
> do not consent to being recorded, discuss your concerns with the host or do
> not join the session.
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Wed, Sep 9, 2015 at 1:16 PM, Benoit Claise <bclaise@cisco.com&g=
t; wrote:

 =20
   =20
 =20
  

    
Dear all,

      

      There is a lot of passionate debates around YANG these days, which
      shows how important YANG became.

      

      After the last IETF meeting, the openconfig group requested a call
      with me.

      During that call, these operators re-explained their problem to
      me.

      

      Let me decompose this into three parts, and again set the stage
      for this interim meeting tomorrow. 

      

      1. The problem statement. 

      When a group of operators come to the IETF with a problem, we
      should take this seriously and embrace it. In other words, nobody
      can dispute the operators problem statement. 

      

      2. The requirements. 

      If there are still clarifications needed around the requirements
      in draft-openconfig-netmod-opstate-01 section 4, or around the
      requirement that the YANG models need some sort of hierarchy
      (draft-openconfig-netmod-model-structure), like for the routing
      models, ... tomorrow interim meeting is your chance, or between
      now and then on the mailing list.

      


My co=
ncern with the problem statement and the requirements in sec. 4 is that the=
y focus
on very large systems, yet these problems do not exist on=
 small systems.
YANG is being considered in the CORE WG.=C2=A0 If=
 and when the CoMI charter addition
is approved then YANG will ne=
ed to support constrained devices.

Common modules =
like ietf-interfaces need to scale well.=C2=A0 IMO the authors
of=
 RFC 7223 did a great job of not imposing any requirements that assume
use-cases or platform resources.=C2=A0 All common modules need to be<=
/div>
designed the same way.

I have yet to hea=
r a number wrt/ how many seconds or minutes does it usually take
=
for intended config to become active config?=C2=A0 What percentage of all d=
evices that
use YANG have this problem?=C2=A0 How fast is the dat=
a expected to change while
the client is polling it?=C2=A0 The so=
lution should not impact systems that do not have
these problems =
that appear to be related to the very large or complex configurations.

Andy

=C2=A0

      3. The solution: 

      There are actually 3 different solutions for the operational
      state.

      3.1 draft-openconfig-netmod-opstate-01, whose version 00 has
      already been presented/discussed

      3.2 draft-kwatsen-netmod-opstate, not yet presented

      3.3 draft-wilton-netmod-opstate-yang, not yet presented

      Come prepared, and have read those drafts in advance.

      This interim meeting should be about comparing solutions around
      the operational state solutions.

      

      We also need understand whether solving those requirements within
      the context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or
      draft-wilton-netmod-opstate-yang) is satisfactory.

      

      Regards, Benoit (OPS AD)

    

    

     =20
      
Dear all,

        

        Let me set the stage for this future interim.

        

        First of (and let me repeat), I'm happy that the operators
        gathered and collectively worked on YANG models and related
        requirements.

        

        The previous two interim meetings in June on the openconfig
        issues (draft-openconfig-netmod-opstate-01
        and draft-openconfig-netmod-model-struc=
ture-00)
        were successful in the sense that the requirements are now
        understood.

        

        Unfortunately, some key players were not in Prague and we could
        not finalize the discussion.

        How to represent the operational state is one important guidance
        from RFC 6087bis that we must be providing to all existing and
        future YANG models (and not only in the IETF). 

        

        We need to bring closure on that topic, and this is the plan for
        that interim meeting in September.

        

        http://datatracker.ietf.org/doc/draft-openconfi=
g-netmod-opstate/
        has been updated. Please comment on this version.

        Also, any alternate proposals must be prepared for that interim
        in September. They must be prepared with the same level of
        rigour as draft-openconfig-netmod-opstate., i.e. must have the
        same level of details.

        

        In the meeting in September, the goal is to take a decision. 

        

        Regards, Benoit (OPS AD)

        

      

      

       =20
       =20
        

          
            

              
                

                  
                    

                      
                        

                          
                            

                               Hello, 
                            

                            

                              
                                NETMOD Working Group invites you to join
                                this WebEx meeting. 
                            

                          
                        

                        

                          
                            

                              =C2=A0
                            

                          
                        

                        

                          
                            

                              
                                NETMOD Interm meeting on OpenConfig
                              
                            

                            

                              Thursday, September 10, 2015 
                            

                            

                              11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Eastern =
Daylight Time
                                (New York, GMT-04:00)=C2=A0=C2=A0|=C2=A0=C2=
=A01 hr 
                            

                          
                        

                        

                          
                            

                              =C2=A0
                            

                          
                        

                        

                          
                            

                              
                                 Join
                                    WebEx meeting  
                            

                          
                        

                        

                          
                            

                               Meeting
                                number: 
                              645 732 277 
                            

                            

                              Meeting
                                password:
                              1234
                            

                          
                        

                        

                          
                            

                              =C2=A0
                            

                          
                        

                        

                          
                            

                              Join by
                                  phone
                            

                            

                              1-877-668-4493=C2=A0Call-in toll
                                free number (US/Canada)
                            

                            

                              1-650-479-3208=C2=A0Call-in toll
                                number (US/Canada)
                            

                            

                              Access code:=C2=A0645 732 277
                            

                            

                              Toll-free
                                  calling restrictions
                            

                          
                        

                        

                          
                            

                              =C2=A0
                            

                          
                        

                        

                          
                            

                              A=
dd this meeting
                                to your calendar.
                            

                          
                        

                        

                          
                            

                              =C2=A0
                            

                          
                        

                        

                          
                            

                               Can't join the
                                meeting? 
                                  Contact support. 
                            

                          
                        

                        

                          
                            

                              =C2=A0
                            

                          
                        

                        

                          
                            

                              
                                IMPORTANT NOTICE: Please note that this
                                WebEx service allows audio and other
                                information sent during the session to
                                be recorded, which may be discoverable
                                in a legal matter. By joining this
                                session, you automatically consent to
                                such recordings. If you do not consent
                                to being recorded, discuss your concerns
                                with the host or do not join the
                                session.
                            

                          
                        

                      		
                    

                  
                

              		
            

          
        

        

        

        

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


      

      

      

      

      

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


    

    

  



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c3c46cba557b051f5755a9--


From nobody Wed Sep  9 14:43:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBD21B47D8 for ; Wed,  9 Sep 2015 14:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1yBFIW428LO for ; Wed,  9 Sep 2015 14:43:25 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02C41B47D6 for ; Wed,  9 Sep 2015 14:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2316; q=dns/txt; s=iport; t=1441835004; x=1443044604; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=TcOGSAphHwZCJbUVDXvodHBwvXyITthCcRMlGy+eKnQ=; b=Ijtc2LDiCDEISmWrzdEkNymrPGk9kgTBOp4kpwAjsLGL9kSat39H1onL bGswTueravjcHV3ESmHhNgOXSh230Q/da/AV+Z3BkQRhX94C0HdqREvxO Hmurzni9Rz32nUk1eJqV/jLE3Ss9HgRSuiGbUCs7jYQu8jBLMcP0ES2vX c=;
X-IronPort-AV: E=Sophos;i="5.17,499,1437436800";  d="scan'208,217";a="611505730"
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; 09 Sep 2015 21:43:22 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t89LhLiK025632; Wed, 9 Sep 2015 21:43:22 GMT
To: Andy Bierman 
References:    
From: Benoit Claise 
Message-ID: <55F0A7FC.4050706@cisco.com>
Date: Wed, 9 Sep 2015 23:43:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050807050708050704010902"
Archived-At: 
Cc: "netmod-chairs@ietf.org" 
Subject: Re: [netmod] Motivations for Structuring Models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 21:43:26 -0000

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

Andy,

[taking on excerpt, out of context, to make a point]
>
>     1) As a consumer of YANG models, how do I identify the set of
>     models that provide a set of functionality? How do YANG model
>     writers ensure that their models are as easy to deal with as
>     possible by having consistent modelling approaches for config?
>
>
> RTFM
That type of language is neither polite, nor useful.

Regards, Benoit (OPS AD)

--------------050807050708050704010902
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Andy,

    

    [taking on excerpt, out of context, to make a point]

    

      

        

          

            

              

                

                  

                    

                      
1) As a consumer of YANG models, how do I
                        identify the set of models that provide a set of
                        functionality? How do YANG model writers ensure
                        that their models are as easy to deal with as
                        possible by having consistent modelling
                        approaches for config?

                    

                  

                

              

            

            


            

            
RTFM

            

          

        

      

    

    That type of language is neither polite, nor useful.

    

    Regards, Benoit (OPS AD)

  


--------------050807050708050704010902--


From nobody Wed Sep  9 15:00:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7691B48E8 for ; Wed,  9 Sep 2015 15:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.86
X-Spam-Level: 
X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxEgyT9k7zsD for ; Wed,  9 Sep 2015 15:00:47 -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 D3F591B48E6 for ; Wed,  9 Sep 2015 15:00:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 06B022D97; Thu, 10 Sep 2015 00:00:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lNg8ZGnPHSjT; Thu, 10 Sep 2015 00:00:44 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Sep 2015 00:00:44 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E7A92004E; Thu, 10 Sep 2015 00:00:44 +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 XOqlKIvHKFtS; Thu, 10 Sep 2015 00:00:41 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A862E20048; Thu, 10 Sep 2015 00:00:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D7F723705DC5; Thu, 10 Sep 2015 00:00:35 +0200 (CEST)
Date: Thu, 10 Sep 2015 00:00:34 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20150909220033.GA35955@elstar.local>
Mail-Followup-To: Benoit Claise , netmod@ietf.org
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55F09386.4030509@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 22:00:49 -0000

On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
 
> 2. The requirements.
> If there are still clarifications needed around the requirements in 
> draft-openconfig-netmod-opstate-01 section 4, or around the requirement 
> that the YANG models need some sort of hierarchy 
> (draft-openconfig-netmod-model-structure), like for the routing models, 
> ... tomorrow interim meeting is your chance, or between now and then on 
> the mailing list.

For the record (since I won't be able to join the call): I disagree
with some of the details in the description of the requirement in
section 4.5. I agree with the part that says that it should be
possible to 'easily' locate the operational state corresponding to
configuration state (and I would add that 'easily' means both for
humans and machines). I would go even further to say that it should
not just be 'easy' but also be 'robust'. What I disagree with is the
part that suggests every 'selector' should be encoded in the schema
path. Note that I am talking about the schema used on a device, I am
not talking about the schema used within an NMS.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep  9 15:24:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CED1A00CA for ; Wed,  9 Sep 2015 15:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL4JVuPZGSlv for ; Wed,  9 Sep 2015 15:24:34 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 C4B1A1A1A0B for ; Wed,  9 Sep 2015 15:24:33 -0700 (PDT)
Received: by lbbmp1 with SMTP id mp1so13674329lbb.1 for ; Wed, 09 Sep 2015 15:24:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dP40M0DGPtGHqRiqVoiQ8pkozfN5lpFFEt/q6azbBt8=; b=mT7FcTZbrogqFcpzPty6/WtdFF3ATaCvxh9wkTds3Qi+nYFtJeogDvaUU09qPObSWI R8GnNQcDp8m9MjiDMbp3/MnOxUUpP7brhC+6Zt1u/RrkcMtVUYnpibBTtCGyfaDDMMas qQgtV0d7jHZRpy5wQa+MAW5JkSRJJptK8fkuSlwgP9cpEg+WZO8X79MqJNg5tEycqPiM 2GmP2xf3bbs8URgO78MvZ2l/1YcdDKecLf3zF73Z7T8EtkGWhhqEqMv1XggOS8fd5FU1 BYWQamxJ1MOt+gxXqARWHEyiKOk+cRdKqq2RZGGPqCy8twmVrluBzObKG9lGSbGhFZJj y90A==
X-Gm-Message-State: ALoCoQmgV+KZP5a2i4Frqk8PRZbiGq3leONLxBwPTcB1e8snH1YB/c0ZSXoIOpcVsJF8TCIa1iGN
MIME-Version: 1.0
X-Received: by 10.152.6.133 with SMTP id b5mr31543288laa.33.1441837471801; Wed, 09 Sep 2015 15:24:31 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 9 Sep 2015 15:24:31 -0700 (PDT)
In-Reply-To: <55F0A7FC.4050706@cisco.com>
References:     <55F0A7FC.4050706@cisco.com>
Date: Wed, 9 Sep 2015 15:24:31 -0700
Message-ID: 
From: Andy Bierman 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=089e01493fa854c1a6051f57f260
Archived-At: 
Cc: "netmod-chairs@ietf.org" 
Subject: Re: [netmod] Motivations for Structuring Models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 22:24:35 -0000

--089e01493fa854c1a6051f57f260
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 9, 2015 at 2:43 PM, Benoit Claise  wrote:

> Andy,
>
> [taking on excerpt, out of context, to make a point]
>
> 1) As a consumer of YANG models, how do I identify the set of models that
>> provide a set of functionality? How do YANG model writers ensure that their
>> models are as easy to deal with as possible by having consistent modelling
>> approaches for config?
>>
>
> RTFM
>
> That type of language is neither polite, nor useful.
>
>
Sorry - Now that I know there are banned acronyms, I will write RTM instead.


> Regards, Benoit (OPS AD)
>

Andy

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




On Wed, Sep 9, 2015 at 2:43 PM, Benoit Claise <bclaise@cisco.com&g=
t; wrote:

 =20
   =20
 =20
  

    Andy,

    

    [taking on excerpt, out of context, to make a point]

    

      

        

          

            

              

                

                  

                    

                      
1) As a consumer of YANG models, how do I
                        identify the set of models that provide a set of
                        functionality? How do YANG model writers ensure
                        that their models are as easy to deal with as
                        possible by having consistent modelling
                        approaches for config?

                    

                  

                

              

            

            


            

            
RTFM

            

          

        

      

    

    That type of language is neither polite, nor useful.

    

Sorry - Now that I know ther=
e are banned acronyms, I will write RTM instead.
=C2=A0

    Regards, Benoit (OPS AD)

  




Andy



--089e01493fa854c1a6051f57f260--


From nobody Wed Sep  9 15:31:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B2E1B4A00 for ; Wed,  9 Sep 2015 15:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKxItUDv37mO for ; Wed,  9 Sep 2015 15:31:19 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF021B49F9 for ; Wed,  9 Sep 2015 15:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=640; q=dns/txt; s=iport; t=1441837879; x=1443047479; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=X475uQlnu+8hggLe/Q2k4UC8VT+VMlbSiMFkl4qFzXA=; b=UdPvtE4LeN4QkCo8vWMj9Z53S1ROKWo5mWFLi013fdqrYr8iNOluxZ81 vsTXyliuXFNgWrAIJGYRQHvFIcl2rgUVnoNAMUs9+zXqHibJEQLF1N1rM y1JeemI2ntwP+TL2HPBn9FQ+7Cct+2fsE0SIifm6J3u1MBVM+ztI5wQF4 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CdBACPsvBV/xbLJq1dg3dpvzCFbwoCghEBAQEBAQGBC4QkAQEEOFELGAklDwJGBgEMCAEBiCoNywQBAQEBAQEBAQEBAQEBAQEBAQEBFQSGc4R7gT2CbBEBWIQsAQSVVox6iHuRfSaCHYFlPDMBhwmBPwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,499,1437436800"; d="scan'208";a="606905074"
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; 09 Sep 2015 22:31:17 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t89MVFif002300; Wed, 9 Sep 2015 22:31:16 GMT
To: Andy Bierman , "netmod@ietf.org" 
References: <20150901142936.GA60706@elstar.local>  <20150904165458.GB33792@elstar.local>
From: Benoit Claise 
Message-ID: <55F0B334.60706@cisco.com>
Date: Thu, 10 Sep 2015 00:31:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150904165458.GB33792@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Sep 2015 22:31:20 -0000

On 04/09/2015 18:54, Juergen Schoenwaelder wrote:
> On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote:
>> Hi,
>>
>> Is there a WEB page that lists all the upcoming virtual meetings?
>> This would really help people remember without scanning lots of
>> ietf-announce email.
>>
> The official list of interim meetings is here:
>
>      https://www.ietf.org/meeting/interim.html
>
> Yes, you have to search for NETMOD and no I am not aware of a nicer
> list directly linked to say the NETMOD WG pages (or even a calendar
> file).
I filed a tool request some time ago exactly on that.

Regards, Benoit
>
> /js
>


From nobody Wed Sep  9 17:38:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E056E1B4DBF for ; Wed,  9 Sep 2015 17:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn3mvRKL8J8S for ; Wed,  9 Sep 2015 17:38:38 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 638471B4BFE for ; Wed,  9 Sep 2015 17:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441845444; bh=b/s5deISzimNnig/LD3TlkKMcy7nda58RrRh9FAys7I=; h=From:Subject:Date:To; b=OwquBv/5R6GIOyX5nQMnR6Ss2+oEOCbJuDt2tMeapmySaE0N9wPtq43J0G+9cJhZQ oapealHSOyHX6tqQm9HN2Qo5t8xOGat1quCiEL2/gJ3ZThqqRqmgFmyznCD1OUrKCD cwR3MmPbyvaBh8MnFKggadvJ4LvetTuUlsxT311o=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
Date: Wed, 9 Sep 2015 20:38:35 -0400
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1549, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Subject: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 00:38:40 -0000

	I wanted to set things up for the interim meeting tomorrow. To =
frame the meeting, we want to achieve two main goals:=20

	1) close on requirements around a requirement to define a =
structure for IETF models and the requirements around ops state/models=20=


	2) discuss/debate/understand the differences between the 3 =
different solution approaches as described in =
draft-openconfig-netmod-opstate-01, draft-kwatsen-netmod-opstate, =
draft-wilton-netmod-opstate-yang.  While I understand the last two =
drafts are relatively new, they are there and have been for a time =
sufficient to read and ask questions on the list of the authors.  =20

	To this end, I=E2=80=99d like to steer the discussion in the =
direction of having direct questions/debate over those solutions. I=E2=80=99=
d like a representative author from each draft lead each of their =
sections.   If time still exists, I=E2=80=99d like to let Kent (speaking =
as co-chair), objectively compare pros/cons of each solution.  I =
understand that we allocated an hour for tomorrow. We incorrectly =
anticipated a single draft to be compared to the existing opsstate =
draft.  If we need additional time, a second meeting will be planned for =
hopefully next week, so that we can tie things off.


	This is the proposed agenda for tomorrow=E2=80=99s meeting.

	0) Agenda Bashing - Tom/2 min

	1) Statement from the AD:
		Please read =
http://www.ietf.org/mail-archive/web/netmod/current/msg13510.html
	=09
	1) Requirements - Tom/15 min
	  - goal is to close on consensus (to be confirmed on list)
	      on the problem statement/requirements, as described in
	      draft-openconfig-netmod-opstate-01, Sections 3 & 4, and
	      implied in draft-openconfig-netmod-model-structure-00
	      (yes, we'll need to write them down), as well as any
	      other requirements not covered by the above.
	    - please come prepared to discuss and finalize these


	2) Questions/Comments about each specific draft - 15 minutes for =
each
		A rep for each draft (Martin?, Wilton?, Anees?)

	   - to be led by a representative for each draft
	      (Martin?, Wilton?, Anees?)
	    - this is not intended to be a presentation of these =
solution
	      so much as an opportunity to ask questions of the authors
	      regarding any aspect of the presented solution.
	    - everyone should come prepared having already read these =
drafts.
	    - if there are no questions, we'll move on to the next draft
	      right away.

	3) Compare and contrast the solutions () - rest of the time, if =
time permits. Kent (as co-chair)

	    - goal is to up-level the conversation to direct comparison
	      of the various solutions.


	Finally, I=E2=80=99d like to ask for a volunteer to take notes =
as well as someone to run the Etherpad.=20


	WebEx Details:




>>>=20
>>> NETMOD Working Group invites you to join this WebEx meeting.
>>> =20
>>> NETMOD Interm meeting on OpenConfig
>>> Thursday, September 10, 2015=20
>>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr=20
>>> =20
>>> Join WebEx meeting
>>> Meeting number:	645 732 277=20
>>> Meeting password:	1234
>>> =20
>>> Join by phone
>>> 1-877-668-4493 Call-in toll free number (US/Canada)
>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>> Access code: 645 732 277

=09




From nobody Wed Sep  9 18:01:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C451B50A9 for ; Wed,  9 Sep 2015 18:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8348nj2bVZmX for ; Wed,  9 Sep 2015 18:01:07 -0700 (PDT)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 526911B4F27 for ; Wed,  9 Sep 2015 18:01:06 -0700 (PDT)
Received: by lagj9 with SMTP id j9so18191791lag.2 for ; Wed, 09 Sep 2015 18:01:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rh05XXidfAkNZtuL1ahA3/9gQ12lC2ZK9QrQcr5kTLw=; b=hXmLH0SJlQ+4Nj0aNafFGiu/eZLLU/ndYebB88klZWFvv7oTMrXM5yaYWlZkUy1OBJ tJxSmt+7q9vQ6OUZ9BXBywbkHj9IY7RqPyxYrxRVXFTYXits6GAALPBeBEMH0FnCuA07 NiA1s1Za7AlnsioN6bzKuMKYeu/35ZCXfyL3YmUByh8+3uhoHObZ4sAF33+v6Tm4m8vX KvUj76Rydy7zu6lrg/c8cdkXDalWi8/CwyWqLrMwXBcT3TZvsreU5N+46XwNIKr6eKjx NEb96nqWB6Fb5LPczRvKuSOY0lc3yVuOk3Hn3OwYsXV5K1pk4MQNb12mq57Hcar8yVc/ cU8g==
X-Gm-Message-State: ALoCoQlZH1uYxsV67RN68e9Dndy6d6ukF77SQHjqproNXyPP0Oux9iBKN9tWwNdm8x19GZ6pOT9O
MIME-Version: 1.0
X-Received: by 10.152.120.198 with SMTP id le6mr32347331lab.38.1441846864325;  Wed, 09 Sep 2015 18:01:04 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 9 Sep 2015 18:01:04 -0700 (PDT)
In-Reply-To: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
Date: Wed, 9 Sep 2015 18:01:04 -0700
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=089e011769052b4d93051f5a2289
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 01:01:10 -0000

--089e011769052b4d93051f5a2289
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

This email and the one from Benoit do not mention any sort of problem scope=
.
IMO it would be useful to know if the scope includes all YANG modules, only
IETF
YANG modules, or perhaps only IETF routing modules. As the scope gets wider=
,
the probability that "1 size fits all" goes way down.


Andy


On Wed, Sep 9, 2015 at 5:38 PM, Nadeau Thomas 
wrote:

>
>         I wanted to set things up for the interim meeting tomorrow. To
> frame the meeting, we want to achieve two main goals:
>
>         1) close on requirements around a requirement to define a
> structure for IETF models and the requirements around ops state/models
>
>         2) discuss/debate/understand the differences between the 3
> different solution approaches as described in
> draft-openconfig-netmod-opstate-01, draft-kwatsen-netmod-opstate,
> draft-wilton-netmod-opstate-yang.  While I understand the last two drafts
> are relatively new, they are there and have been for a time sufficient to
> read and ask questions on the list of the authors.
>
>         To this end, I=E2=80=99d like to steer the discussion in the dire=
ction of
> having direct questions/debate over those solutions. I=E2=80=99d like a
> representative author from each draft lead each of their sections.   If
> time still exists, I=E2=80=99d like to let Kent (speaking as co-chair), o=
bjectively
> compare pros/cons of each solution.  I understand that we allocated an ho=
ur
> for tomorrow. We incorrectly anticipated a single draft to be compared to
> the existing opsstate draft.  If we need additional time, a second meetin=
g
> will be planned for hopefully next week, so that we can tie things off.
>
>
>         This is the proposed agenda for tomorrow=E2=80=99s meeting.
>
>         0) Agenda Bashing - Tom/2 min
>
>         1) Statement from the AD:
>                 Please read
> http://www.ietf.org/mail-archive/web/netmod/current/msg13510.html
>
>         1) Requirements - Tom/15 min
>           - goal is to close on consensus (to be confirmed on list)
>               on the problem statement/requirements, as described in
>               draft-openconfig-netmod-opstate-01, Sections 3 & 4, and
>               implied in draft-openconfig-netmod-model-structure-00
>               (yes, we'll need to write them down), as well as any
>               other requirements not covered by the above.
>             - please come prepared to discuss and finalize these
>
>
>         2) Questions/Comments about each specific draft - 15 minutes for
> each
>                 A rep for each draft (Martin?, Wilton?, Anees?)
>
>            - to be led by a representative for each draft
>               (Martin?, Wilton?, Anees?)
>             - this is not intended to be a presentation of these solution
>               so much as an opportunity to ask questions of the authors
>               regarding any aspect of the presented solution.
>             - everyone should come prepared having already read these
> drafts.
>             - if there are no questions, we'll move on to the next draft
>               right away.
>
>         3) Compare and contrast the solutions () - rest of the time, if
> time permits. Kent (as co-chair)
>
>             - goal is to up-level the conversation to direct comparison
>               of the various solutions.
>
>
>         Finally, I=E2=80=99d like to ask for a volunteer to take notes as=
 well as
> someone to run the Etherpad.
>
>
>         WebEx Details:
>
>
>
>
> >>>
> >>> NETMOD Working Group invites you to join this WebEx meeting.
> >>>
> >>> NETMOD Interm meeting on OpenConfig
> >>> Thursday, September 10, 2015
> >>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
> >>>
> >>> Join WebEx meeting
> >>> Meeting number:     645 732 277
> >>> Meeting password:   1234
> >>>
> >>> Join by phone
> >>> 1-877-668-4493 Call-in toll free number (US/Canada)
> >>> 1-650-479-3208 Call-in toll number (US/Canada)
> >>> Access code: 645 732 277
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

This email and the one from Benoit =
do not mention any sort of problem scope.
IMO it would be useful =
to know if the scope includes all YANG modules, only IETF
YANG mo=
dules, or perhaps only IETF routing modules. As the scope gets wider,
=

the probability that "1 size fits all" goes way down.
<=
div>

Andy


On Wed, Sep 9, 2015 at 5:38=
 PM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I wanted to set things up for the interim meeti=
ng tomorrow. To frame the meeting, we want to achieve two main goals:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) close on requirements around a requirement t=
o define a structure for IETF models and the requirements around ops state/=
models



=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) discuss/debate/understand the differences be=
tween the 3 different solution approaches as described in draft-openconfig-=
netmod-opstate-01, draft-kwatsen-netmod-opstate, draft-wilton-netmod-opstat=
e-yang.=C2=A0 While I understand the last two drafts are relatively new, th=
ey are there and have been for a time sufficient to read and ask questions =
on the list of the authors.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 To this end, I=E2=80=99d like to steer the disc=
ussion in the direction of having direct questions/debate over those soluti=
ons. I=E2=80=99d like a representative author from each draft lead each of =
their sections.=C2=A0 =C2=A0If time still exists, I=E2=80=99d like to let K=
ent (speaking as co-chair), objectively compare pros/cons of each solution.=
=C2=A0 I understand that we allocated an hour for tomorrow. We incorrectly =
anticipated a single draft to be compared to the existing opsstate draft.=
=C2=A0 If we need additional time, a second meeting will be planned for hop=
efully next week, so that we can tie things off.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is the proposed agenda for tomorrow=E2=80=
=99s meeting.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 0) Agenda Bashing - Tom/2 min



=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Statement from the AD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please read http://www.ietf.org/mail-archive/web/netm=
od/current/msg13510.html



=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Requirements - Tom/15 min

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - goal is to close on consensus (to be c=
onfirmed on list)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on the problem statement/r=
equirements, as described in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-openconfig-netmod-op=
state-01, Sections 3 & 4, and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implied in draft-openconfi=
g-netmod-model-structure-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (yes, we'll need to wr=
ite them down), as well as any

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other requirements not cov=
ered by the above.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - please come prepared to discuss=
 and finalize these





=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Questions/Comments about each specific draft=
 - 15 minutes for each

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A rep for each draf=
t (Martin?, Wilton?, Anees?)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- to be led by a representative fo=
r each draft

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Martin?, Wilton?, Anees?)=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - this is not intended to be a pr=
esentation of these solution

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 so much as an opportunity =
to ask questions of the authors

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 regarding any aspect of th=
e presented solution.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - everyone should come prepared h=
aving already read these drafts.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - if there are no questions, we&#=
39;ll move on to the next draft

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 right away.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Compare and contrast the solutions () - rest=
 of the time, if time permits. Kent (as co-chair)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - goal is to up-level the convers=
ation to direct comparison

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the various solutions.<=
br>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Finally, I=E2=80=99d like to ask for a voluntee=
r to take notes as well as someone to run the Etherpad.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 WebEx Details:









>>>

>>> NETMOD Working Group invites you to join this WebEx meeting.
>>>

>>> NETMOD Interm meeting on OpenConfig

>>> Thursday, September 10, 2015

>>> 11:00 am=C2=A0 |=C2=A0 Eastern Daylight Time (New York, GMT-04=
:00)=C2=A0 |=C2=A0 1 hr

>>>

>>> Join WebEx meeting

>>> Meeting number:=C2=A0 =C2=A0 =C2=A0645 732 277

>>> Meeting password:=C2=A0 =C2=A01234

>>>

>>> Join by phone

>>> 1-877-668-4493 Call-in toll free number (US/Canada)

>>> 1-650-479-3208 Call-in toll number (US/Canada)

>>> Access code: 645 732 277











_______________________________________________

netmod mailing list

netmod@ietf.org

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





--089e011769052b4d93051f5a2289--


From nobody Wed Sep  9 18:26:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A70F1B5212 for ; Wed,  9 Sep 2015 18:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpFG48-qgQgY for ; Wed,  9 Sep 2015 18:26:23 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C73F1B5210 for ; Wed,  9 Sep 2015 18:26:23 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Thu, 10 Sep 2015 01:26:19 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.011; Thu, 10 Sep 2015 01:26:19 +0000
From: Kent Watsen 
To: Andy Bierman , Nadeau Thomas 
Thread-Topic: [netmod] Tomorrow's Interim Meeting Details
Thread-Index: AQHQ62EO7gVoAKsHUkGUOjQTCaJPKZ408ZMA///D+gA=
Date: Thu, 10 Sep 2015 01:26:19 +0000
Message-ID: 
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:rWTp1YBNgFTjRAStFXgo8hDY510e+b765RSA4JvZx3KxV2LXFiEAA4l8QTd3Ao3QdBfizYctkpTPwNl51C6XqomE446WblluuaINhpzd3tOn2wBdRz9QD+uvgkIC31EtaKw7B+wj62DcZxuqzjdxFw==; 24:CN3beR9FBL2ucDbkpuXyn/SlhmOR2uAPRKgU+wBplVM05MQVI4enNkwfjmnEM56mdLc3fQR5wOH1M8TetkdtuKVFHCAe/HEK4pze/TJjAfk=; 20:JGtYKGlcfGwNEY1LccEGIhdfbVLc7/AmObbdhymGZCoRTF0x4IXS2d44xFVl9KA8bIafVsAMVYbJV+nOzkKJwA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(24454002)(189002)(19617315012)(189998001)(86362001)(101416001)(551544002)(19580395003)(5007970100001)(19580405001)(5004730100002)(64706001)(76176999)(66066001)(5002640100001)(11100500001)(5001770100001)(83506001)(81156007)(97736004)(4001350100001)(62966003)(4001540100001)(36756003)(5001830100001)(106356001)(50986999)(106116001)(5001960100002)(122556002)(46102003)(77156002)(5001860100001)(10400500002)(105586002)(16297215004)(54356999)(2900100001)(87936001)(92566002)(40100003)(68736005)(102836002)(99286002)(2950100001)(15975445007)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2164FB6D648Dkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2015 01:26:19.4915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 01:26:27 -0000

--_000_D2164FB6D648Dkwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This goes to model-structure requirements, which are currently undefined.  =
As mentioned below, we will need to spend some time tomorrow writing them d=
own, so we have something to call consensus on.    Maybe the open config fo=
lks could take a stab at this before tomorrow's meeting?

Kent

From: Andy Bierman >
Date: Wednesday, September 9, 2015 at 9:01 PM
To: Thomas Nadeau >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] Tomorrow's Interim Meeting Details

Hi,

This email and the one from Benoit do not mention any sort of problem scope=
.
IMO it would be useful to know if the scope includes all YANG modules, only=
 IETF
YANG modules, or perhaps only IETF routing modules. As the scope gets wider=
,
the probability that "1 size fits all" goes way down.


Andy


On Wed, Sep 9, 2015 at 5:38 PM, Nadeau Thomas > wrote:

        I wanted to set things up for the interim meeting tomorrow. To fram=
e the meeting, we want to achieve two main goals:

        1) close on requirements around a requirement to define a structure=
 for IETF models and the requirements around ops state/models

        2) discuss/debate/understand the differences between the 3 differen=
t solution approaches as described in draft-openconfig-netmod-opstate-01, d=
raft-kwatsen-netmod-opstate, draft-wilton-netmod-opstate-yang.  While I und=
erstand the last two drafts are relatively new, they are there and have bee=
n for a time sufficient to read and ask questions on the list of the author=
s.

        To this end, I'd like to steer the discussion in the direction of h=
aving direct questions/debate over those solutions. I'd like a representati=
ve author from each draft lead each of their sections.   If time still exis=
ts, I'd like to let Kent (speaking as co-chair), objectively compare pros/c=
ons of each solution.  I understand that we allocated an hour for tomorrow.=
 We incorrectly anticipated a single draft to be compared to the existing o=
psstate draft.  If we need additional time, a second meeting will be planne=
d for hopefully next week, so that we can tie things off.


        This is the proposed agenda for tomorrow's meeting.

        0) Agenda Bashing - Tom/2 min

        1) Statement from the AD:
                Please read http://www.ietf.org/mail-archive/web/netmod/cur=
rent/msg13510.html

        1) Requirements - Tom/15 min
          - goal is to close on consensus (to be confirmed on list)
              on the problem statement/requirements, as described in
              draft-openconfig-netmod-opstate-01, Sections 3 & 4, and
              implied in draft-openconfig-netmod-model-structure-00
              (yes, we'll need to write them down), as well as any
              other requirements not covered by the above.
            - please come prepared to discuss and finalize these


        2) Questions/Comments about each specific draft - 15 minutes for ea=
ch
                A rep for each draft (Martin?, Wilton?, Anees?)

           - to be led by a representative for each draft
              (Martin?, Wilton?, Anees?)
            - this is not intended to be a presentation of these solution
              so much as an opportunity to ask questions of the authors
              regarding any aspect of the presented solution.
            - everyone should come prepared having already read these draft=
s.
            - if there are no questions, we'll move on to the next draft
              right away.

        3) Compare and contrast the solutions () - rest of the time, if tim=
e permits. Kent (as co-chair)

            - goal is to up-level the conversation to direct comparison
              of the various solutions.


        Finally, I'd like to ask for a volunteer to take notes as well as s=
omeone to run the Etherpad.


        WebEx Details:




>>>
>>> NETMOD Working Group invites you to join this WebEx meeting.
>>>
>>> NETMOD Interm meeting on OpenConfig
>>> Thursday, September 10, 2015
>>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
>>>
>>> Join WebEx meeting
>>> Meeting number:     645 732 277
>>> Meeting password:   1234
>>>
>>> Join by phone
>>> 1-877-668-4493 Call-in toll free number (US/Canada)
>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>> Access code: 645 732 277





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


--_000_D2164FB6D648Dkwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <1E06B1C9578E98489B0053236D2827C4@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable












This goes to model-structure requirements, which are currently undefin=
ed.  As mentioned below, we will need to spend some time tomorrow writ=
ing them down, so we have something to call consensus on.    Mayb=
e the open config folks could take a stab at this
 before tomorrow's meeting?







Kent









From: Andy Bierman <andy@yumaworks.com>

Date: Wednesday, September 9, 2015 =
at 9:01 PM

To: Thomas Nadeau <tnadeau@lucidvision.com>

Cc: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: Re: [netmod] Tomorrow's In=
terim Meeting Details













Hi,






This email and the one from Benoit do not mention any sort of problem =
scope.


IMO it would be useful to know if the scope includes all YANG modules,=
 only IETF


YANG modules, or perhaps only IETF routing modules. As the scope gets =
wider,


the probability that "1 size fits all" goes way down.












Andy












On Wed, Sep 9, 2015 at 5:38 PM, Nadeau Thomas 
<tnadeau@lu=
cidvision.com> wrote:





        I wanted to set things up for the interim meeti=
ng tomorrow. To frame the meeting, we want to achieve two main goals:



        1) close on requirements around a requirement t=
o define a structure for IETF models and the requirements around ops state/=
models



        2) discuss/debate/understand the differences be=
tween the 3 different solution approaches as described in draft-openconfig-=
netmod-opstate-01, draft-kwatsen-netmod-opstate, draft-wilton-netmod-opstat=
e-yang.  While I understand the last two drafts are
 relatively new, they are there and have been for a time sufficient to read=
 and ask questions on the list of the authors.



        To this end, I’d like to steer the discus=
sion in the direction of having direct questions/debate over those solution=
s. I’d like a representative author from each draft lead each of thei=
r sections.   If time still exists, I’d like to let Kent (s=
peaking
 as co-chair), objectively compare pros/cons of each solution.  I unde=
rstand that we allocated an hour for tomorrow. We incorrectly anticipated a=
 single draft to be compared to the existing opsstate draft.  If we ne=
ed additional time, a second meeting will
 be planned for hopefully next week, so that we can tie things off.





        This is the proposed agenda for tomorrow’=
s meeting.



        0) Agenda Bashing - Tom/2 min



        1) Statement from the AD:

                Please read 
http://www.ietf.org/mail-archive/web/netmod/current/msg13510.html



        1) Requirements - Tom/15 min

          - goal is to close on consensus (to be c=
onfirmed on list)

              on the problem statement/r=
equirements, as described in

              draft-openconfig-netmod-op=
state-01, Sections 3 & 4, and

              implied in draft-openconfi=
g-netmod-model-structure-00

              (yes, we'll need to write =
them down), as well as any

              other requirements not cov=
ered by the above.

            - please come prepared to discuss=
 and finalize these





        2) Questions/Comments about each specific draft=
 - 15 minutes for each

                A rep for each draf=
t (Martin?, Wilton?, Anees?)



           - to be led by a representative fo=
r each draft

              (Martin?, Wilton?, Anees?)=


            - this is not intended to be a pr=
esentation of these solution

              so much as an opportunity =
to ask questions of the authors

              regarding any aspect of th=
e presented solution.

            - everyone should come prepared h=
aving already read these drafts.

            - if there are no questions, we'l=
l move on to the next draft

              right away.



        3) Compare and contrast the solutions () - rest=
 of the time, if time permits. Kent (as co-chair)



            - goal is to up-level the convers=
ation to direct comparison

              of the various solutions.<=
br>




        Finally, I’d like to ask for a volunteer =
to take notes as well as someone to run the Etherpad.





        WebEx Details:









>>>

>>> NETMOD Working Group invites you to join this WebEx meeting.
>>>

>>> NETMOD Interm meeting on OpenConfig

>>> Thursday, September 10, 2015

>>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04=
:00)  |  1 hr

>>>

>>> Join WebEx meeting

>>> Meeting number:     645 732 277

>>> Meeting password:   1234

>>>

>>> Join by phone

>>> 1-877-668-4493 Call-in toll free number (US/Canada)

>>> 1-650-479-3208 Call-in toll number (US/Canada)

>>> Access code: 645 732 277











_______________________________________________

netmod mailing list

netmod@ietf.org

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

















--_000_D2164FB6D648Dkwatsenjunipernet_--


From nobody Wed Sep  9 19:03:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0AA1B53E5 for ; Wed,  9 Sep 2015 19:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2f8r5bAFcDo for ; Wed,  9 Sep 2015 19:03:10 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9737F1B2F63 for ; Wed,  9 Sep 2015 19:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20557; q=dns/txt; s=iport; t=1441850590; x=1443060190; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cKFFutpme+J9QBQWVeYY4UzixY3x9HTo6qG/YC823IU=; b=hDxsoI+A1lTTNJeXxDmvg9hEOtXFpxpJdef9YwNqOdfcmElCP/tIofM7 ZWTLcjmDTzmeswzbBG44dqOY/NF7FikxsBXPy4c55AAZvUxsQ0Z8J+vf0 QCe8tLEpq0wSyb89OfdQLTfVvuJAxdXgmESSmK6F6FSIiFPOjA1NPR+ol A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BsAABt5PBV/5ldJa1aA4JWTVRpBoMeugEBDXQFdAEJhS9KAhyBIjgUAQEBAQEBAYEKhCMBAQEEAQEBIEMICw4CAgEIDgMDAQIVBAwDAwICAhkMCxQJBwECAQMBDQUJEogTDbZihTOOVwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEi2qCPYFsEAIBDBgRCgEMBAcSB4JQgUMFlVYBjHmBTIQzgx+RWiaDMU9xAYdDgQUBAQE
X-IronPort-AV: E=Sophos; i="5.17,501,1437436800"; d="scan'208,217"; a="30896017"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 10 Sep 2015 02:03:09 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8A238VX011894 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 02:03:08 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Sep 2015 21:03:07 -0500
Received: from xhc-aln-x15.cisco.com (173.36.12.89) by xch-aln-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 9 Sep 2015 21:03:07 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0248.002; Wed, 9 Sep 2015 21:03:07 -0500
From: "Acee Lindem (acee)" 
To: Kent Watsen , Andy Bierman , Nadeau Thomas 
Thread-Topic: [netmod] Tomorrow's Interim Meeting Details
Thread-Index: AQHQ62EQU1CK8lsn+UmLmdofMz4y0p41RWUAgAAHDoD//8c6gA==
Date: Thu, 10 Sep 2015 02:03:07 +0000
Message-ID: 
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.102.24]
Content-Type: multipart/alternative; boundary="_000_D2165C802DEBAaceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 02:03:13 -0000

--_000_D2165C802DEBAaceeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2luY2UgdGhlIG1lZXRpbmcgaXMgb25seSBhbiBob3VyLCBJIHRoaW5rIGl0IGlzIHVucmVhbGlz
dGljIHRvIHRoaW5rIHdlIGFyZSBnb2luZyB0byBjb3ZlciBib3RoIE9wcy1zdGF0ZSBhbmQgbW9k
ZWwgc3RydWN0dXJlIHRvbW9ycm93Lg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBuZXRtb2QgPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9u
IGJlaGFsZiBvZiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNl
bkBqdW5pcGVyLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIFNlcHRlbWJlciA5LCAyMDE1IGF0IDk6
MjYgUE0NClRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5
dW1hd29ya3MuY29tPj4sICJUaG9tYXMgRC4gTmFkZWF1IiA8dG5hZGVhdUBsdWNpZHZpc2lvbi5j
b208bWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tPj4NCkNjOiBuZXRtb2QgV0cgPG5ldG1v
ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbmV0bW9k
XSBUb21vcnJvdydzIEludGVyaW0gTWVldGluZyBEZXRhaWxzDQoNCg0KVGhpcyBnb2VzIHRvIG1v
ZGVsLXN0cnVjdHVyZSByZXF1aXJlbWVudHMsIHdoaWNoIGFyZSBjdXJyZW50bHkgdW5kZWZpbmVk
LiAgQXMgbWVudGlvbmVkIGJlbG93LCB3ZSB3aWxsIG5lZWQgdG8gc3BlbmQgc29tZSB0aW1lIHRv
bW9ycm93IHdyaXRpbmcgdGhlbSBkb3duLCBzbyB3ZSBoYXZlIHNvbWV0aGluZyB0byBjYWxsIGNv
bnNlbnN1cyBvbi4gICAgTWF5YmUgdGhlIG9wZW4gY29uZmlnIGZvbGtzIGNvdWxkIHRha2UgYSBz
dGFiIGF0IHRoaXMgYmVmb3JlIHRvbW9ycm93J3MgbWVldGluZz8NCg0KS2VudA0KDQpGcm9tOiBB
bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29t
Pj4NCkRhdGU6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDksIDIwMTUgYXQgOTowMSBQTQ0KVG86IFRo
b21hcyBOYWRlYXUgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPG1haWx0bzp0bmFkZWF1QGx1Y2lk
dmlzaW9uLmNvbT4+DQpDYzogIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn
PiIgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJl
OiBbbmV0bW9kXSBUb21vcnJvdydzIEludGVyaW0gTWVldGluZyBEZXRhaWxzDQoNCkhpLA0KDQpU
aGlzIGVtYWlsIGFuZCB0aGUgb25lIGZyb20gQmVub2l0IGRvIG5vdCBtZW50aW9uIGFueSBzb3J0
IG9mIHByb2JsZW0gc2NvcGUuDQpJTU8gaXQgd291bGQgYmUgdXNlZnVsIHRvIGtub3cgaWYgdGhl
IHNjb3BlIGluY2x1ZGVzIGFsbCBZQU5HIG1vZHVsZXMsIG9ubHkgSUVURg0KWUFORyBtb2R1bGVz
LCBvciBwZXJoYXBzIG9ubHkgSUVURiByb3V0aW5nIG1vZHVsZXMuIEFzIHRoZSBzY29wZSBnZXRz
IHdpZGVyLA0KdGhlIHByb2JhYmlsaXR5IHRoYXQgIjEgc2l6ZSBmaXRzIGFsbCIgZ29lcyB3YXkg
ZG93bi4NCg0KDQpBbmR5DQoNCg0KT24gV2VkLCBTZXAgOSwgMjAxNSBhdCA1OjM4IFBNLCBOYWRl
YXUgVGhvbWFzIDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTxtYWlsdG86dG5hZGVhdUBsdWNpZHZp
c2lvbi5jb20+PiB3cm90ZToNCg0KICAgICAgICBJIHdhbnRlZCB0byBzZXQgdGhpbmdzIHVwIGZv
ciB0aGUgaW50ZXJpbSBtZWV0aW5nIHRvbW9ycm93LiBUbyBmcmFtZSB0aGUgbWVldGluZywgd2Ug
d2FudCB0byBhY2hpZXZlIHR3byBtYWluIGdvYWxzOg0KDQogICAgICAgIDEpIGNsb3NlIG9uIHJl
cXVpcmVtZW50cyBhcm91bmQgYSByZXF1aXJlbWVudCB0byBkZWZpbmUgYSBzdHJ1Y3R1cmUgZm9y
IElFVEYgbW9kZWxzIGFuZCB0aGUgcmVxdWlyZW1lbnRzIGFyb3VuZCBvcHMgc3RhdGUvbW9kZWxz
DQoNCiAgICAgICAgMikgZGlzY3Vzcy9kZWJhdGUvdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZXMg
YmV0d2VlbiB0aGUgMyBkaWZmZXJlbnQgc29sdXRpb24gYXBwcm9hY2hlcyBhcyBkZXNjcmliZWQg
aW4gZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZS0wMSwgZHJhZnQta3dhdHNlbi1uZXRt
b2Qtb3BzdGF0ZSwgZHJhZnQtd2lsdG9uLW5ldG1vZC1vcHN0YXRlLXlhbmcuICBXaGlsZSBJIHVu
ZGVyc3RhbmQgdGhlIGxhc3QgdHdvIGRyYWZ0cyBhcmUgcmVsYXRpdmVseSBuZXcsIHRoZXkgYXJl
IHRoZXJlIGFuZCBoYXZlIGJlZW4gZm9yIGEgdGltZSBzdWZmaWNpZW50IHRvIHJlYWQgYW5kIGFz
ayBxdWVzdGlvbnMgb24gdGhlIGxpc3Qgb2YgdGhlIGF1dGhvcnMuDQoNCiAgICAgICAgVG8gdGhp
cyBlbmQsIEnigJlkIGxpa2UgdG8gc3RlZXIgdGhlIGRpc2N1c3Npb24gaW4gdGhlIGRpcmVjdGlv
biBvZiBoYXZpbmcgZGlyZWN0IHF1ZXN0aW9ucy9kZWJhdGUgb3ZlciB0aG9zZSBzb2x1dGlvbnMu
IEnigJlkIGxpa2UgYSByZXByZXNlbnRhdGl2ZSBhdXRob3IgZnJvbSBlYWNoIGRyYWZ0IGxlYWQg
ZWFjaCBvZiB0aGVpciBzZWN0aW9ucy4gICBJZiB0aW1lIHN0aWxsIGV4aXN0cywgSeKAmWQgbGlr
ZSB0byBsZXQgS2VudCAoc3BlYWtpbmcgYXMgY28tY2hhaXIpLCBvYmplY3RpdmVseSBjb21wYXJl
IHByb3MvY29ucyBvZiBlYWNoIHNvbHV0aW9uLiAgSSB1bmRlcnN0YW5kIHRoYXQgd2UgYWxsb2Nh
dGVkIGFuIGhvdXIgZm9yIHRvbW9ycm93LiBXZSBpbmNvcnJlY3RseSBhbnRpY2lwYXRlZCBhIHNp
bmdsZSBkcmFmdCB0byBiZSBjb21wYXJlZCB0byB0aGUgZXhpc3Rpbmcgb3Bzc3RhdGUgZHJhZnQu
ICBJZiB3ZSBuZWVkIGFkZGl0aW9uYWwgdGltZSwgYSBzZWNvbmQgbWVldGluZyB3aWxsIGJlIHBs
YW5uZWQgZm9yIGhvcGVmdWxseSBuZXh0IHdlZWssIHNvIHRoYXQgd2UgY2FuIHRpZSB0aGluZ3Mg
b2ZmLg0KDQoNCiAgICAgICAgVGhpcyBpcyB0aGUgcHJvcG9zZWQgYWdlbmRhIGZvciB0b21vcnJv
d+KAmXMgbWVldGluZy4NCg0KICAgICAgICAwKSBBZ2VuZGEgQmFzaGluZyAtIFRvbS8yIG1pbg0K
DQogICAgICAgIDEpIFN0YXRlbWVudCBmcm9tIHRoZSBBRDoNCiAgICAgICAgICAgICAgICBQbGVh
c2UgcmVhZCBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJl
bnQvbXNnMTM1MTAuaHRtbA0KDQogICAgICAgIDEpIFJlcXVpcmVtZW50cyAtIFRvbS8xNSBtaW4N
CiAgICAgICAgICAtIGdvYWwgaXMgdG8gY2xvc2Ugb24gY29uc2Vuc3VzICh0byBiZSBjb25maXJt
ZWQgb24gbGlzdCkNCiAgICAgICAgICAgICAgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50L3JlcXVp
cmVtZW50cywgYXMgZGVzY3JpYmVkIGluDQogICAgICAgICAgICAgIGRyYWZ0LW9wZW5jb25maWct
bmV0bW9kLW9wc3RhdGUtMDEsIFNlY3Rpb25zIDMgJiA0LCBhbmQNCiAgICAgICAgICAgICAgaW1w
bGllZCBpbiBkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDANCiAgICAg
ICAgICAgICAgKHllcywgd2UnbGwgbmVlZCB0byB3cml0ZSB0aGVtIGRvd24pLCBhcyB3ZWxsIGFz
IGFueQ0KICAgICAgICAgICAgICBvdGhlciByZXF1aXJlbWVudHMgbm90IGNvdmVyZWQgYnkgdGhl
IGFib3ZlLg0KICAgICAgICAgICAgLSBwbGVhc2UgY29tZSBwcmVwYXJlZCB0byBkaXNjdXNzIGFu
ZCBmaW5hbGl6ZSB0aGVzZQ0KDQoNCiAgICAgICAgMikgUXVlc3Rpb25zL0NvbW1lbnRzIGFib3V0
IGVhY2ggc3BlY2lmaWMgZHJhZnQgLSAxNSBtaW51dGVzIGZvciBlYWNoDQogICAgICAgICAgICAg
ICAgQSByZXAgZm9yIGVhY2ggZHJhZnQgKE1hcnRpbj8sIFdpbHRvbj8sIEFuZWVzPykNCg0KICAg
ICAgICAgICAtIHRvIGJlIGxlZCBieSBhIHJlcHJlc2VudGF0aXZlIGZvciBlYWNoIGRyYWZ0DQog
ICAgICAgICAgICAgIChNYXJ0aW4/LCBXaWx0b24/LCBBbmVlcz8pDQogICAgICAgICAgICAtIHRo
aXMgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgcHJlc2VudGF0aW9uIG9mIHRoZXNlIHNvbHV0aW9u
DQogICAgICAgICAgICAgIHNvIG11Y2ggYXMgYW4gb3Bwb3J0dW5pdHkgdG8gYXNrIHF1ZXN0aW9u
cyBvZiB0aGUgYXV0aG9ycw0KICAgICAgICAgICAgICByZWdhcmRpbmcgYW55IGFzcGVjdCBvZiB0
aGUgcHJlc2VudGVkIHNvbHV0aW9uLg0KICAgICAgICAgICAgLSBldmVyeW9uZSBzaG91bGQgY29t
ZSBwcmVwYXJlZCBoYXZpbmcgYWxyZWFkeSByZWFkIHRoZXNlIGRyYWZ0cy4NCiAgICAgICAgICAg
IC0gaWYgdGhlcmUgYXJlIG5vIHF1ZXN0aW9ucywgd2UnbGwgbW92ZSBvbiB0byB0aGUgbmV4dCBk
cmFmdA0KICAgICAgICAgICAgICByaWdodCBhd2F5Lg0KDQogICAgICAgIDMpIENvbXBhcmUgYW5k
IGNvbnRyYXN0IHRoZSBzb2x1dGlvbnMgKCkgLSByZXN0IG9mIHRoZSB0aW1lLCBpZiB0aW1lIHBl
cm1pdHMuIEtlbnQgKGFzIGNvLWNoYWlyKQ0KDQogICAgICAgICAgICAtIGdvYWwgaXMgdG8gdXAt
bGV2ZWwgdGhlIGNvbnZlcnNhdGlvbiB0byBkaXJlY3QgY29tcGFyaXNvbg0KICAgICAgICAgICAg
ICBvZiB0aGUgdmFyaW91cyBzb2x1dGlvbnMuDQoNCg0KICAgICAgICBGaW5hbGx5LCBJ4oCZZCBs
aWtlIHRvIGFzayBmb3IgYSB2b2x1bnRlZXIgdG8gdGFrZSBub3RlcyBhcyB3ZWxsIGFzIHNvbWVv
bmUgdG8gcnVuIHRoZSBFdGhlcnBhZC4NCg0KDQogICAgICAgIFdlYkV4IERldGFpbHM6DQoNCg0K
DQoNCj4+Pg0KPj4+IE5FVE1PRCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhp
cyBXZWJFeCBtZWV0aW5nLg0KPj4+DQo+Pj4gTkVUTU9EIEludGVybSBtZWV0aW5nIG9uIE9wZW5D
b25maWcNCj4+PiBUaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE1DQo+Pj4gMTE6MDAgYW0gIHwg
IEVhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkgIHwgIDEgaHINCj4+
Pg0KPj4+IEpvaW4gV2ViRXggbWVldGluZw0KPj4+IE1lZXRpbmcgbnVtYmVyOiAgICAgNjQ1IDcz
MiAyNzcNCj4+PiBNZWV0aW5nIHBhc3N3b3JkOiAgIDEyMzQNCj4+Pg0KPj4+IEpvaW4gYnkgcGhv
bmUNCj4+PiAxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFk
YSkNCj4+PiAxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQo+
Pj4gQWNjZXNzIGNvZGU6IDY0NSA3MzIgMjc3DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1v
ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K

--_000_D2165C802DEBAaceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5TaW5jZSB0aGUg
bWVldGluZyBpcyBvbmx5IGFuIGhvdXIsIEkgdGhpbmsgaXQgaXMgdW5yZWFsaXN0aWMgdG8gdGhp
bmsgd2UgYXJlIGdvaW5nIHRvIGNvdmVyIGJvdGggT3BzLXN0YXRlIGFuZCBtb2RlbCBzdHJ1Y3R1
cmUgdG9tb3Jyb3cuJm5ic3A7PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZu
YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD
VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg
dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7
IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M
RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s
aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2QgJmx0OzxhIGhyZWY9
Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+Jmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0
c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgU2VwdGVtYmVy
IDksIDIwMTUgYXQgOToyNiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U
bzogPC9zcGFuPkFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtz
LmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDssICZxdW90O1Rob21hcyBELiBOYWRlYXUm
cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSI+dG5hZGVh
dUBsdWNpZHZpc2lvbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi
b2xkIj5DYzogPC9zcGFuPm5ldG1vZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm
Lm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbbmV0bW9kXSBUb21vcnJvdydzIEludGVyaW0g
TWVldGluZyBEZXRhaWxzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt
TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At
bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9y
OiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgZ29lcyB0byBtb2RlbC1z
dHJ1Y3R1cmUgcmVxdWlyZW1lbnRzLCB3aGljaCBhcmUgY3VycmVudGx5IHVuZGVmaW5lZC4gJm5i
c3A7QXMgbWVudGlvbmVkIGJlbG93LCB3ZSB3aWxsIG5lZWQgdG8gc3BlbmQgc29tZSB0aW1lIHRv
bW9ycm93IHdyaXRpbmcgdGhlbSBkb3duLCBzbyB3ZSBoYXZlIHNvbWV0aGluZyB0byBjYWxsIGNv
bnNlbnN1cyBvbi4gJm5ic3A7ICZuYnNwO01heWJlIHRoZSBvcGVuIGNvbmZpZyBmb2xrcyBjb3Vs
ZCB0YWtlIGEgc3RhYiBhdCB0aGlzDQogYmVmb3JlIHRvbW9ycm93J3MgbWVldGluZz88L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PktlbnQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJP
UkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJ
TkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJP
UkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQ
QURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8
L3NwYW4+QW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29t
Ij5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBTZXB0ZW1iZXIgOSwgMjAxNSBhdCA5OjAx
IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+VGhvbWFz
IE5hZGVhdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tIj50bmFk
ZWF1QGx1Y2lkdmlzaW9uLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+
bmV0bW9kQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm
Lm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbbmV0bW9kXSBUb21vcnJvdydzIEludGVyaW0g
TWVldGluZyBEZXRhaWxzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgZW1h
aWwgYW5kIHRoZSBvbmUgZnJvbSBCZW5vaXQgZG8gbm90IG1lbnRpb24gYW55IHNvcnQgb2YgcHJv
YmxlbSBzY29wZS48L2Rpdj4NCjxkaXY+SU1PIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBrbm93IGlm
IHRoZSBzY29wZSBpbmNsdWRlcyBhbGwgWUFORyBtb2R1bGVzLCBvbmx5IElFVEY8L2Rpdj4NCjxk
aXY+WUFORyBtb2R1bGVzLCBvciBwZXJoYXBzIG9ubHkgSUVURiByb3V0aW5nIG1vZHVsZXMuIEFz
IHRoZSBzY29wZSBnZXRzIHdpZGVyLDwvZGl2Pg0KPGRpdj50aGUgcHJvYmFiaWxpdHkgdGhhdCAm
cXVvdDsxIHNpemUgZml0cyBhbGwmcXVvdDsgZ29lcyB3YXkgZG93bi48L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbmR5PC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFz
cz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgU2VwIDksIDIwMTUgYXQgNTozOCBQTSwgTmFkZWF1IFRo
b21hcyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnRuYWRlYXVAbHVjaWR2
aXNpb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+dG5hZGVhdUBsdWNpZHZpc2lvbi5jb208L2E+Jmd0
Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls
ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s
ZWZ0OjFleCI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSB3YW50ZWQgdG8g
c2V0IHRoaW5ncyB1cCBmb3IgdGhlIGludGVyaW0gbWVldGluZyB0b21vcnJvdy4gVG8gZnJhbWUg
dGhlIG1lZXRpbmcsIHdlIHdhbnQgdG8gYWNoaWV2ZSB0d28gbWFpbiBnb2Fsczo8YnI+DQo8YnI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMSkgY2xvc2Ugb24gcmVxdWlyZW1lbnRzIGFy
b3VuZCBhIHJlcXVpcmVtZW50IHRvIGRlZmluZSBhIHN0cnVjdHVyZSBmb3IgSUVURiBtb2RlbHMg
YW5kIHRoZSByZXF1aXJlbWVudHMgYXJvdW5kIG9wcyBzdGF0ZS9tb2RlbHM8YnI+DQo8YnI+DQom
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMikgZGlzY3Vzcy9kZWJhdGUvdW5kZXJzdGFuZCB0
aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgMyBkaWZmZXJlbnQgc29sdXRpb24gYXBwcm9hY2hl
cyBhcyBkZXNjcmliZWQgaW4gZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZS0wMSwgZHJh
ZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZSwgZHJhZnQtd2lsdG9uLW5ldG1vZC1vcHN0YXRlLXlh
bmcuJm5ic3A7IFdoaWxlIEkgdW5kZXJzdGFuZCB0aGUgbGFzdCB0d28gZHJhZnRzIGFyZQ0KIHJl
bGF0aXZlbHkgbmV3LCB0aGV5IGFyZSB0aGVyZSBhbmQgaGF2ZSBiZWVuIGZvciBhIHRpbWUgc3Vm
ZmljaWVudCB0byByZWFkIGFuZCBhc2sgcXVlc3Rpb25zIG9uIHRoZSBsaXN0IG9mIHRoZSBhdXRo
b3JzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUbyB0aGlzIGVuZCwg
SeKAmWQgbGlrZSB0byBzdGVlciB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgZGlyZWN0aW9uIG9mIGhh
dmluZyBkaXJlY3QgcXVlc3Rpb25zL2RlYmF0ZSBvdmVyIHRob3NlIHNvbHV0aW9ucy4gSeKAmWQg
bGlrZSBhIHJlcHJlc2VudGF0aXZlIGF1dGhvciBmcm9tIGVhY2ggZHJhZnQgbGVhZCBlYWNoIG9m
IHRoZWlyIHNlY3Rpb25zLiZuYnNwOyAmbmJzcDtJZiB0aW1lIHN0aWxsIGV4aXN0cywgSeKAmWQg
bGlrZSB0byBsZXQgS2VudCAoc3BlYWtpbmcNCiBhcyBjby1jaGFpciksIG9iamVjdGl2ZWx5IGNv
bXBhcmUgcHJvcy9jb25zIG9mIGVhY2ggc29sdXRpb24uJm5ic3A7IEkgdW5kZXJzdGFuZCB0aGF0
IHdlIGFsbG9jYXRlZCBhbiBob3VyIGZvciB0b21vcnJvdy4gV2UgaW5jb3JyZWN0bHkgYW50aWNp
cGF0ZWQgYSBzaW5nbGUgZHJhZnQgdG8gYmUgY29tcGFyZWQgdG8gdGhlIGV4aXN0aW5nIG9wc3N0
YXRlIGRyYWZ0LiZuYnNwOyBJZiB3ZSBuZWVkIGFkZGl0aW9uYWwgdGltZSwgYSBzZWNvbmQgbWVl
dGluZyB3aWxsDQogYmUgcGxhbm5lZCBmb3IgaG9wZWZ1bGx5IG5leHQgd2Vlaywgc28gdGhhdCB3
ZSBjYW4gdGllIHRoaW5ncyBvZmYuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IFRoaXMgaXMgdGhlIHByb3Bvc2VkIGFnZW5kYSBmb3IgdG9tb3Jyb3figJlzIG1l
ZXRpbmcuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDApIEFnZW5kYSBC
YXNoaW5nIC0gVG9tLzIgbWluPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IDEpIFN0YXRlbWVudCBmcm9tIHRoZSBBRDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBsZWFzZSByZWFkIDxhIGhyZWY9Imh0dHA6
Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxMzUxMC5o
dG1sIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5v
cmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxMzUxMC5odG1sPC9hPjxicj4N
Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxKSBSZXF1aXJlbWVudHMgLSBUb20v
MTUgbWluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIGdvYWwgaXMg
dG8gY2xvc2Ugb24gY29uc2Vuc3VzICh0byBiZSBjb25maXJtZWQgb24gbGlzdCk8YnI+DQombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb24gdGhlIHByb2Js
ZW0gc3RhdGVtZW50L3JlcXVpcmVtZW50cywgYXMgZGVzY3JpYmVkIGluPGJyPg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LW9wZW5jb25maWct
bmV0bW9kLW9wc3RhdGUtMDEsIFNlY3Rpb25zIDMgJmFtcDsgNCwgYW5kPGJyPg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGltcGxpZWQgaW4gZHJhZnQt
b3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0dXJlLTAwPGJyPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICh5ZXMsIHdlJ2xsIG5lZWQgdG8gd3Jp
dGUgdGhlbSBkb3duKSwgYXMgd2VsbCBhcyBhbnk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgb3RoZXIgcmVxdWlyZW1lbnRzIG5vdCBjb3ZlcmVk
IGJ5IHRoZSBhYm92ZS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAtIHBsZWFzZSBjb21lIHByZXBhcmVkIHRvIGRpc2N1c3MgYW5kIGZpbmFsaXplIHRoZXNl
PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIpIFF1ZXN0aW9u
cy9Db21tZW50cyBhYm91dCBlYWNoIHNwZWNpZmljIGRyYWZ0IC0gMTUgbWludXRlcyBmb3IgZWFj
aDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgQSByZXAgZm9yIGVhY2ggZHJhZnQgKE1hcnRpbj8sIFdpbHRvbj8sIEFuZWVzPyk8YnI+
DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gdG8gYmUg
bGVkIGJ5IGEgcmVwcmVzZW50YXRpdmUgZm9yIGVhY2ggZHJhZnQ8YnI+DQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKE1hcnRpbj8sIFdpbHRvbj8sIEFu
ZWVzPyk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIHRo
aXMgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgcHJlc2VudGF0aW9uIG9mIHRoZXNlIHNvbHV0aW9u
PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNv
IG11Y2ggYXMgYW4gb3Bwb3J0dW5pdHkgdG8gYXNrIHF1ZXN0aW9ucyBvZiB0aGUgYXV0aG9yczxi
cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWdh
cmRpbmcgYW55IGFzcGVjdCBvZiB0aGUgcHJlc2VudGVkIHNvbHV0aW9uLjxicj4NCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0gZXZlcnlvbmUgc2hvdWxkIGNvbWUg
cHJlcGFyZWQgaGF2aW5nIGFscmVhZHkgcmVhZCB0aGVzZSBkcmFmdHMuPGJyPg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBpZiB0aGVyZSBhcmUgbm8gcXVlc3Rp
b25zLCB3ZSdsbCBtb3ZlIG9uIHRvIHRoZSBuZXh0IGRyYWZ0PGJyPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJpZ2h0IGF3YXkuPGJyPg0KPGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDMpIENvbXBhcmUgYW5kIGNvbnRyYXN0IHRoZSBz
b2x1dGlvbnMgKCkgLSByZXN0IG9mIHRoZSB0aW1lLCBpZiB0aW1lIHBlcm1pdHMuIEtlbnQgKGFz
IGNvLWNoYWlyKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IC0gZ29hbCBpcyB0byB1cC1sZXZlbCB0aGUgY29udmVyc2F0aW9uIHRvIGRpcmVjdCBj
b21wYXJpc29uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IG9mIHRoZSB2YXJpb3VzIHNvbHV0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRmluYWxseSwgSeKAmWQgbGlrZSB0byBhc2sgZm9yIGEgdm9s
dW50ZWVyIHRvIHRha2Ugbm90ZXMgYXMgd2VsbCBhcyBzb21lb25lIHRvIHJ1biB0aGUgRXRoZXJw
YWQuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlYkV4IERl
dGFpbHM6PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7IE5FVE1PRCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBX
ZWJFeCBtZWV0aW5nLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBORVRNT0Qg
SW50ZXJtIG1lZXRpbmcgb24gT3BlbkNvbmZpZzxicj4NCiZndDsmZ3Q7Jmd0OyBUaHVyc2RheSwg
U2VwdGVtYmVyIDEwLCAyMDE1PGJyPg0KJmd0OyZndDsmZ3Q7IDExOjAwIGFtJm5ic3A7IHwmbmJz
cDsgRWFzdGVybiBEYXlsaWdodCBUaW1lIChOZXcgWW9yaywgR01ULTA0OjAwKSZuYnNwOyB8Jm5i
c3A7IDEgaHI8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSm9pbiBXZWJFeCBt
ZWV0aW5nPGJyPg0KJmd0OyZndDsmZ3Q7IE1lZXRpbmcgbnVtYmVyOiZuYnNwOyAmbmJzcDsgJm5i
c3A7NjQ1IDczMiAyNzc8YnI+DQomZ3Q7Jmd0OyZndDsgTWVldGluZyBwYXNzd29yZDombmJzcDsg
Jm5ic3A7MTIzNDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBKb2luIGJ5IHBo
b25lPGJyPg0KJmd0OyZndDsmZ3Q7IDEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51
bWJlciAoVVMvQ2FuYWRhKTxicj4NCiZndDsmZ3Q7Jmd0OyAxLTY1MC00NzktMzIwOCBDYWxsLWlu
IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPGJyPg0KJmd0OyZndDsmZ3Q7IEFjY2VzcyBjb2RlOiA2
NDUgNzMyIDI3Nzxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcg
bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9y
ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D2165C802DEBAaceeciscocom_--


From nobody Wed Sep  9 19:33:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD561B2C75 for ; Wed,  9 Sep 2015 19:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.001
X-Spam-Level: 
X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCKGdWZAoJjg for ; Wed,  9 Sep 2015 19:33:21 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 2F1B91B440D for ; Wed,  9 Sep 2015 19:33:21 -0700 (PDT)
Received: (qmail 14177 invoked by uid 0); 10 Sep 2015 02:33:16 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 10 Sep 2015 02:33:16 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id FED71r00n2SSUrH01EDA9A; Wed, 09 Sep 2015 20:13:16 -0600
X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=5ZFH_dB4NIgA:10 a=ff-B7xzCdYMA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=dm08xCcUog8iL3fnl5wA:9 a=ib1UgvWQRoPhAgyE:21 a=VsLkx-e2hpM2To_D:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=tn2quUA9Wh57Ntzd6oJIheER/lzu+dbBQDqPZRctYcw=;  b=0htemZgk1/O0Rxv3QfSoq54Gs+d1mmGd+zhw8RjA5PLtoPqGVh2R0wSOE08CmxdUd9ElcS5Hq9Z+1pdBzwmZnv6xixET+tMsiITu+qXfexUyYlEmd45BsQDfRYlOSzXA;
Received: from [71.191.205.82] (port=56096 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZZrMJ-0004uZ-Lb; Wed, 09 Sep 2015 20:13:07 -0600
From: Lou Berger 
To: Juergen Schoenwaelder , Benoit Claise 
Date: Wed, 09 Sep 2015 22:12:58 -0400
Message-ID: <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20150909220033.GA35955@elstar.local>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 71.191.205.82 authed with lberger@labn.net}
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 02:33:23 -0000

Juergen,

It sounds like you are agreeing with the requirements but not the solution. 
 I think this is a valuable distinction, i.e., that it's possible to agree 
with one but not the other.  I'd also like to point out that the first part 
of the discussion is limited to requirements only so we can focus on the 
former before delving in to the latter .

Lou


On September 9, 2015 6:01:20 PM Juergen Schoenwaelder 
 wrote:

> On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
>
>> 2. The requirements.
>> If there are still clarifications needed around the requirements in
>> draft-openconfig-netmod-opstate-01 section 4, or around the requirement
>> that the YANG models need some sort of hierarchy
>> (draft-openconfig-netmod-model-structure), like for the routing models,
>> ... tomorrow interim meeting is your chance, or between now and then on
>> the mailing list.
>
> For the record (since I won't be able to join the call): I disagree
> with some of the details in the description of the requirement in
> section 4.5. I agree with the part that says that it should be
> possible to 'easily' locate the operational state corresponding to
> configuration state (and I would add that 'easily' means both for
> humans and machines). I would go even further to say that it should
> not just be 'easy' but also be 'robust'. What I disagree with is the
> part that suggests every 'selector' should be encoded in the schema
> path. Note that I am talking about the schema used on a device, I am
> not talking about the schema used within an NMS.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From nobody Wed Sep  9 21:47:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5221B2B80 for ; Wed,  9 Sep 2015 21:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py2kpYCQVUXv for ; Wed,  9 Sep 2015 21:47:46 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71F1B37F6 for ; Wed,  9 Sep 2015 21:47:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hSKwaI8sRL9IEee3UN8Meq1wN6fXxtTNmC/6rrtgtiwSlEQYIgt2t9TcKO0WyTDN; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZZtls-0007iy-3t for netmod@ietf.org; Thu, 10 Sep 2015 00:47:40 -0400
Received: from 76.254.48.192 by webmail.earthlink.net with HTTP; Thu, 10 Sep 2015 00:47:39 -0400
Message-ID: <574764.1441860459985.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
Date: Wed, 9 Sep 2015 21:47:39 -0700 (GMT-07:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edcb60e29876a852ae256973009dd059fa350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.33
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 04:47:47 -0000

Hi -

> From: Andy Bierman
> Sent: Sep 9, 2015 12:10 PM
> To: Ladislav Lhotka
> Cc: Robert Wilton , Randy Presuhn , "netmod@ietf.org"
> Subject: Re: [netmod] Y26 again, sorry
...
> I don't think it really addresses the design pattern very well.
> You want to claim that M and Q are both being developed at the
> same time,so it's OK that Q adds mandatory nodes to M.  YANG
> has no such rule.YANG says a server can implement M and never
> implement Q.YANG says a server may implement M and then add Q
> in a future release.These conformance mechanisms do not align
> with your expectationsof how YANG can/should be used.

I agree with Andy that there seems to be a mismatch in expectations.
Let's look at a slightly more complex hypothetical case to tease
out how folks *want* things to work.  Assume the following have
been defined:

  - base module M
  - augmentation Q
  - augmentation R

On a server claiming to supporting the modules containing M, Q,
and R, respectively, which of the following might one encounter
concurrently?

     - plain M
     - M+Q
     - M+R
     - M+Q+R

If the answer is "any of the them" (which is what I'd expect)
how can the modeler exclude specific combinations, and would
these exclusions be testable as part of a conformance check?

If the answer is anything other than "any of them", how does
the modeler go about making it possible to handle equivalents
to the excluded cases, in the event that someone actually does
need to support functionality equivalent to the excluded cases?

I think this matters because the question of mandatory stuff
within an augmentation appears to really be a stand-in for
making an augmentation (at least conditionally) mandatory,
as well as naturally leading to questions about "non-instantiable"
stuff done for modeling convenience.

I think Andy is very right to be concerned about this, because
this is another aspect of the old question of deciding just how
different two things can be before we give up on trying to claim
that they are two instances of the same class or in some weaker
sense "compatible".

Randy


From nobody Wed Sep  9 23:08:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C7A1A9308 for ; Wed,  9 Sep 2015 23:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK04VDu1g1ed for ; Wed,  9 Sep 2015 23:08:39 -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 CB6D41B5514 for ; Wed,  9 Sep 2015 23:08:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 280332F22; Thu, 10 Sep 2015 08:08:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6y11gBgOZE_h; Thu, 10 Sep 2015 08:08:35 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Sep 2015 08:08:35 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BC8A20282; Thu, 10 Sep 2015 08:08:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xo5DgthyT5ll; Thu, 10 Sep 2015 08:08:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A626F20281; Thu, 10 Sep 2015 08:08:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AF2E13706046; Thu, 10 Sep 2015 08:08:30 +0200 (CEST)
Date: Thu, 10 Sep 2015 08:08:30 +0200
From: Juergen Schoenwaelder 
To: Nadeau Thomas 
Message-ID: <20150910060830.GB36798@elstar.local>
Mail-Followup-To: Nadeau Thomas , netmod WG 
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 06:08:40 -0000

On Wed, Sep 09, 2015 at 08:38:35PM -0400, Nadeau Thomas wrote:
> 
> 	I wanted to set things up for the interim meeting tomorrow. To frame the meeting, we want to achieve two main goals: 
> 
> 	1) close on requirements around a requirement to define a structure for IETF models and the requirements around ops state/models 
>

I am confused. Benoit pointed to section 4 which has essentially
requirements concerning the support of asynchronous systems. You seem
to be talking also about requirements that go beyond that. It would be
good to know well ahead of time what is exactly on the agenda.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep  9 23:33:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD661B33F1 for ; Wed,  9 Sep 2015 23:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.86
X-Spam-Level: 
X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqLVnKo-vF-A for ; Wed,  9 Sep 2015 23:32:57 -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 2A5081ACCF4 for ; Wed,  9 Sep 2015 23:32:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0F6474E; Thu, 10 Sep 2015 08:32:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cbKYtYa8ireb; Thu, 10 Sep 2015 08:32:54 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Sep 2015 08:32:54 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FEA72037F; Thu, 10 Sep 2015 08:32:54 +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 RMGnYFDoeSI4; Thu, 10 Sep 2015 08:32:51 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 516352037E; Thu, 10 Sep 2015 08:32:51 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5A0B837060BE; Thu, 10 Sep 2015 08:32:48 +0200 (CEST)
Date: Thu, 10 Sep 2015 08:32:48 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Message-ID: <20150910063248.GD36798@elstar.local>
Mail-Followup-To: Lou Berger , Benoit Claise , netmod@ietf.org
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 06:32:59 -0000

Yes, in my view, section 4.5 goes a bit too far in making a certain
solution part of the requirement.

The solutions that have been written up have different properties in
terms of data modeling impact, device implementation impact, NMS
implementation impact and backwards compatibility impact. Furthermore,
we need to acknowledge that not all devices are asynchronous. These
aspects need to be taken into account when selecting a solution.

What is needed is clarity what the requirements are that we find
agreement on. I believe it is possible to tweak the text in section 4
to something people can agree on. But as it is written in -01, I do
not think we are there yet.

/js

On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
> Juergen,
> 
> It sounds like you are agreeing with the requirements but not the solution. 
> I think this is a valuable distinction, i.e., that it's possible to agree 
> with one but not the other.  I'd also like to point out that the first part 
> of the discussion is limited to requirements only so we can focus on the 
> former before delving in to the latter .
> 
> Lou
> 
> 
> On September 9, 2015 6:01:20 PM Juergen Schoenwaelder 
>  wrote:
> 
> >On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
> >
> >>2. The requirements.
> >>If there are still clarifications needed around the requirements in
> >>draft-openconfig-netmod-opstate-01 section 4, or around the requirement
> >>that the YANG models need some sort of hierarchy
> >>(draft-openconfig-netmod-model-structure), like for the routing models,
> >>... tomorrow interim meeting is your chance, or between now and then on
> >>the mailing list.
> >
> >For the record (since I won't be able to join the call): I disagree
> >with some of the details in the description of the requirement in
> >section 4.5. I agree with the part that says that it should be
> >possible to 'easily' locate the operational state corresponding to
> >configuration state (and I would add that 'easily' means both for
> >humans and machines). I would go even further to say that it should
> >not just be 'easy' but also be 'robust'. What I disagree with is the
> >part that suggests every 'selector' should be encoded in the schema
> >path. Note that I am talking about the schema used on a device, I am
> >not talking about the schema used within an NMS.
> >
> >/js
> >
> >--
> >Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >Fax:   +49 421 200 3103         
> >
> >_______________________________________________
> >netmod mailing list
> >netmod@ietf.org
> >https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Sep 10 00:42:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E409E1B57AD for ; Thu, 10 Sep 2015 00:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level: 
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDCmxK6ttBFM for ; Thu, 10 Sep 2015 00:42:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 716DD1B2E9E for ; Thu, 10 Sep 2015 00:42:02 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 19E281AE097A; Thu, 10 Sep 2015 09:42:00 +0200 (CEST)
Date: Thu, 10 Sep 2015 09:41:59 +0200 (CEST)
Message-Id: <20150910.094159.1542287559946591076.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <55F09386.4030509@cisco.com>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 07:42:04 -0000

Hi,

Benoit Claise  wrote:
> 2. The requirements.
> If there are still clarifications needed around the requirements in
> draft-openconfig-netmod-opstate-01 section 4

  4.1.  Applied configuration as part of operational state

Already in the title, this requirement mandates the solution.

I think the requirement is that if the device is "asynchronous", the
operator should (1) be able to learn this fact and (2) be able to
retrieve both intended and applied configuration.


  4.2.  Support for both transactional, synchronous management systems as
      well as distributed, asynchronous management systems

If people say that they have systems that work like this, then ok.


  4.3.  Separation of configuration and operational state data; ability to
      retrieve them independently

Ok, but retrieval is going to be a protocol issue, not a language issue.


  4.4.  Ability to retrieve operational state corresponding only to
      derived values, statistics, etc.

Ok, but retrieval is going to be a protocol issue, not a language issue.


  4.5.  Consistent schema locations for configuration and corresponding
      operational state data

This requirement also mandates the solution in the title.  I think
Juergen formulated this requirement better when he wrote that it
should be 'easy' to locate state related to config for humans and
machines, in a 'robust' way.



Also, in the introduction, the document says:

   These proposals are based on the assertion that YANG models should
   be usable via a number of protocols (not solely IETF-defined
   protocols such as NETCONF and RESTCONF)

I agree with this statement in priniciple, but only if the protocol is
suitable for YANG.  I do not agree that YANG should be changed
everytime someone says that they want to use YANG with protocol X
(especially when protocol X is unknown).  In fact, I believe it is not
possible to design a *data* modelling language (see RFC 3444) that can
be used for an arbitrary protocol (see
draft-schoenw-sming-lessons-01).

As an example, I know that some implementations are using YANG with
SNMP.  Does this imply that *all* models MUST have some statement to
assign an oid with every node?


> , or around the
> requirement that the YANG models need some sort of hierarchy
> (draft-openconfig-netmod-model-structure)

I don't think the requirements for this problem are described
anywhere?


/martin


From nobody Thu Sep 10 01:31:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38691B3D74 for ; Thu, 10 Sep 2015 01:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level: 
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMPmDvPYG0nW for ; Thu, 10 Sep 2015 01:31:10 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001: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 E77831B3B5A for ; Thu, 10 Sep 2015 01:31:07 -0700 (PDT)
Received: by igxx6 with SMTP id x6so9945578igx.1 for ; Thu, 10 Sep 2015 01:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ERxGgl4S7vAU/BgKNgYHowu+A85bSw7rIzklTzaSdQ=; b=VcF+r0KWs4IDzPvN2ANF8VwGjVx7bTIEtCULdefpilD8jXQe8lgXfyv/xxRT8QZuLm 2UAUWwDluOk53m+qsnIoqhET3kz/3485AuRJANAQ0HY38UaMQpcYrSJly+Bgz9kw7nlD sIzpAxGfqzSgYP2xj2vU7zmOxMG9HBocIACktvRlB4rX8as4QU04oqrxXxLO7QH173Lx L1AzhqX12toMEMhZEQfUITCHVIWadC8i7BqS+VRcUPHzlXHyleaNFj3JyVBxLXnVMPBr hTBYLnS5vhxUfY/WlXFww5Oa1qGR7u6qTW++0bgrsmx2ZVML+lkcdEBP16jNRPsWFAsi 2Lew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5ERxGgl4S7vAU/BgKNgYHowu+A85bSw7rIzklTzaSdQ=; b=CbGjk0zdq+CyjRCJ8cDw21AZRpzXsXcvGENjnxgx2UTpn1fyJbmdfBw/HlnKtIsL6Z FlFHcg5JbdvcBPTucCKst0l5FMmHYCMMnbSvIf8lIjMPylES2y1dqLxUb76+mHVfCGTq /w4fGamY5NaN+YV3mXck4qpeb/bEGW4myFyGPEdtncott7em0WF/u5Gtd6UpQNbSLyUz CwkeyV6EYDAqZSVZUJ0JcRvmjcY/Pqi/LdIaugvFlIZJSXY3WLMx4xAeB+Du5oWVSxt9 KR7ndEFxlDE849x5/0gLSzhqBV0/Db4JZtoSJ3O9Hgl1Amh4/H0z5ebpsFGQfO60tsMN 8CzQ==
X-Gm-Message-State: ALoCoQljnT3K9XM6W+NB8ifBylI5M73J9KSW7A9hFoV2iMJBVY85VzuRHf9GcGjXpce3tDSkP9TM
MIME-Version: 1.0
X-Received: by 10.50.32.34 with SMTP id f2mr3838110igi.44.1441873867121; Thu, 10 Sep 2015 01:31:07 -0700 (PDT)
Received: by 10.79.32.130 with HTTP; Thu, 10 Sep 2015 01:31:07 -0700 (PDT)
In-Reply-To: <20150910.094159.1542287559946591076.mbj@tail-f.com>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150910.094159.1542287559946591076.mbj@tail-f.com>
Date: Thu, 10 Sep 2015 01:31:07 -0700
Message-ID: 
From: Anees Shaikh 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=047d7b10c9d1a97ad3051f606b13
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" , NETMOD Working Group 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 08:31:13 -0000

--047d7b10c9d1a97ad3051f606b13
Content-Type: text/plain; charset=UTF-8

hi -- some additional comments inline.  I think that the revisit on some of
the operator requirements is primarily due to some proposed solution's
inability to address them.

On Thu, Sep 10, 2015 at 12:41 AM, Martin Bjorklund  wrote:

> Hi,
>
> Benoit Claise  wrote:
> > 2. The requirements.
> > If there are still clarifications needed around the requirements in
> > draft-openconfig-netmod-opstate-01 section 4
>
>   4.1.  Applied configuration as part of operational state
>
> Already in the title, this requirement mandates the solution.
>
> I think the requirement is that if the device is "asynchronous", the
> operator should (1) be able to learn this fact and (2) be able to
> retrieve both intended and applied configuration.
>

No, the title does not mandate a solution -- it just asserts that
configuration should be treated as part of the state, or,  in other words,
what a device is running at any given moment is part of its state -- I do
agree that it's a different perspective from the thinking that led to the
limited way in which YANG supports operational state modeling today.


>
>
>   4.2.  Support for both transactional, synchronous management systems as
>       well as distributed, asynchronous management systems
>
> If people say that they have systems that work like this, then ok.
>
>
>   4.3.  Separation of configuration and operational state data; ability to
>       retrieve them independently
>
> Ok, but retrieval is going to be a protocol issue, not a language issue.
>

Retrieval is not only about the protocol -- the model's structure (in this
case the ability to indicate state data clearly in the model ) also is
important.  Limiting this to a protocol issue also presupposes a solution.


>
>   4.4.  Ability to retrieve operational state corresponding only to
>       derived values, statistics, etc.
>
> Ok, but retrieval is going to be a protocol issue, not a language issue.
>

Again, no -- not only a protocol issue -- same as above (this time you're
dictating a solution :-) ).   Certainly the model plays a part in
designating different data items as operational state that reflects applied
configuration vs. operational state that reflects device-generated data.


>
>
>   4.5.  Consistent schema locations for configuration and corresponding
>       operational state data
>
> This requirement also mandates the solution in the title.  I think
> Juergen formulated this requirement better when he wrote that it
> should be 'easy' to locate state related to config for humans and
> machines, in a 'robust' way.
>

This alternate formulation is not better -- it's just a much vaguer version
of the requirement that is harder to define -- I think we've already seen
there are very different experiences and ideas about what makes a solution
easy or robust.   And prioritizing YANG modeling for consumption by humans
rather than NMSes, automation systems, programmatic interfaces, etc. risks
defeating the whole purpose of using it IMO.


>
>
> Also, in the introduction, the document says:
>
>    These proposals are based on the assertion that YANG models should
>    be usable via a number of protocols (not solely IETF-defined
>    protocols such as NETCONF and RESTCONF)
>
> I agree with this statement in priniciple, but only if the protocol is
> suitable for YANG.  I do not agree that YANG should be changed
> everytime someone says that they want to use YANG with protocol X
> (especially when protocol X is unknown).  In fact, I believe it is not
> possible to design a *data* modelling language (see RFC 3444) that can
> be used for an arbitrary protocol (see
> draft-schoenw-sming-lessons-01).
>
> As an example, I know that some implementations are using YANG with
> SNMP.  Does this imply that *all* models MUST have some statement to
> assign an oid with every node?
>


No.  Please note that our proposed solutions have so far required *no*
changes to YANG other than use of a single extension (which is a supported
language feature).  Not a single line of pyang was changed to successfully
compile models that follow the proposed structure.   Let's not confuse
proposing changes to YANG *models* and introducing conventions with
requiring changes to the YANG language.  This is not to say that some
language changes would not make things a bit more sensible -- we have
worked around those limitations, and most of the changes have been
identified as needed in other contexts as well (see observations from the
ODL project, for example).  I expect proposals to be forthcoming.



>
> > , or around the
> > requirement that the YANG models need some sort of hierarchy
> > (draft-openconfig-netmod-model-structure)
>
> I don't think the requirements for this problem are described
> anywhere?
>

Well, you could re-read the thread that you actively participated in
(Motivations for Structuring Models)  :-)  My read of that discussion (and
the discussion at the June interim meeting on this topic) was that there
was no real disagreement on the need for a structure to help organize
related functionality across the growing set of models  (the ietf-routing
model is trying to do exactly this for a subset of functionality).  The
main issue was whether there is a need to anchor such a structure in an
additional layer on the device (i.e., /device) or whether such a layer
should be maintained solely by the NMS.

thanks.
-- Anees


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

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


hi -- some additional comments inline.=C2=A0 I think that =
the revisit on some of the operator requirements is primarily due to some p=
roposed solution's inability to address them.

On Thu, Sep 10, 2015 at 12:41 AM, Martin Bj=
orklund <mbj@tail-f.com> wrote:
Hi,



Benoit Claise <bclaise@cisco.com> wrote:

> 2. The requirements.

> If there are still clarifications needed around the requirements in
> draft-openconfig-netmod-opstate-01 section 4



=C2=A0 4.1.=C2=A0 Applied configuration as part of operational state=




Already in the title, this requirement mandates the solution.



I think the requirement is that if the device is "asynchronous", =
the

operator should (1) be able to learn this fact and (2) be able to

retrieve both intended and applied configuration.





=C2=A0 4.2.=C2=A0 Support for both transactional, synchronous management sy=
stems as

=C2=A0 =C2=A0 =C2=A0 well as distributed, asynchronous management systems


If people say that they have systems that work like this, then ok.





=C2=A0 4.3.=C2=A0 Separation of configuration and operational state data; a=
bility to

=C2=A0 =C2=A0 =C2=A0 retrieve them independently



Ok, but retrieval is going to be a protocol issue, not a language issue.







=C2=A0 4.4.=C2=A0 Ability to retrieve operational state corresponding only =
to

=C2=A0 =C2=A0 =C2=A0 derived values, statistics, etc.



Ok, but retrieval is going to be a protocol issue, not a language issue.

Again, no -- not only a protocol issue --=
 same as above (this time you're dictating a solution :-) ). =C2=A0 Cer=
tainly the model plays a part in designating different data items as operat=
ional state that reflects applied configuration vs. operational state that =
reflects device-generated data.
=C2=A0





=C2=A0 4.5.=C2=A0 Consistent schema locations for configuration and corresp=
onding

=C2=A0 =C2=A0 =C2=A0 operational state data



This requirement also mandates the solution in the title.=C2=A0 I think

Juergen formulated this requirement better when he wrote that it

should be 'easy' to locate state related to config for humans and
machines, in a 'robust' way.

Th=
is alternate formulation is not better -- it's just a much vaguer versi=
on of the requirement that is harder to define -- I think we've already=
 seen there are very different experiences and ideas about what makes a sol=
ution easy or robust. =C2=A0 And prioritizing YANG modeling for consumption=
 by humans rather than NMSes, automation systems, programmatic interfaces, =
etc. risks defeating the whole purpose of using it IMO.








Also, in the introduction, the document says:



=C2=A0 =C2=A0These proposals are based on the assertion that YANG models sh=
ould

=C2=A0 =C2=A0be usable via a number of protocols (not solely IETF-defined
=C2=A0 =C2=A0protocols such as NETCONF and RESTCONF)



I agree with this statement in priniciple, but only if the protocol is

suitable for YANG.=C2=A0 I do not agree that YANG should be changed

everytime someone says that they want to use YANG with protocol X

(especially when protocol X is unknown).=C2=A0 In fact, I believe it is not=


possible to design a *data* modelling language (see RFC 3444) that can

be used for an arbitrary protocol (see

draft-schoenw-sming-lessons-01).



As an example, I know that some implementations are using YANG with

SNMP.=C2=A0 Does this imply that *all* models MUST have some statement to
assign an oid with every node?


No.=C2=A0 Please note that our proposed solutions have so far requir=
ed *no* changes to YANG other than use of a single extension (which is a su=
pported language feature).=C2=A0 Not a single line of pyang was changed to =
successfully compile models that follow the proposed structure. =C2=A0 Let&=
#39;s not confuse proposing changes to YANG *models* and introducing conven=
tions with requiring changes to the YANG language.=C2=A0 This is not to say=
 that some language changes would not make things a bit more sensible -- we=
 have worked around those limitations, and most of the changes have been id=
entified as needed in other contexts as well (see observations from the ODL=
 project, for example).=C2=A0 I expect proposals to be forthcoming.

=C2=A0



> , or around the

> requirement that the YANG models need some sort of hierarchy

> (draft-openconfig-netmod-model-structure)



I don't think the requirements for this problem are described
anywhere?

Well, you could re-read the t=
hread that you actively participated in (Motivations for Structuring Models=
) =C2=A0:-) =C2=A0My read of that discussion (and the discussion at the Jun=
e interim meeting on this topic) was that there was no real disagreement on=
 the need for a structure to help organize related functionality across the=
 growing set of models =C2=A0(the ietf-routing model is trying to do exactl=
y this for a subset of functionality).=C2=A0 The main issue was whether the=
re is a need to anchor such a structure in an additional layer on the devic=
e (i.e., /device) or whether such a layer should be maintained solely by th=
e NMS.

thanks.
-- Anees



--047d7b10c9d1a97ad3051f606b13--


From nobody Thu Sep 10 01:40:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BC1B4150 for ; Thu, 10 Sep 2015 01:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.11
X-Spam-Level: 
X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-wGyx24PITT for ; Thu, 10 Sep 2015 01:40:08 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A331B414D for ; Thu, 10 Sep 2015 01:40:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11287; q=dns/txt; s=iport; t=1441874409; x=1443084009; h=from:subject:to:message-id:date:mime-version; bh=RXwKtUdqgYGbmE0MF2jRyrRT8qpqwTx7MdxeKE/smsc=; b=k7vLP2aoEoOjmzs51JGoLOl+626CG4jT1nCk1GhksUJfD9uFUJQgPwCQ i/mMB8KZsOwudNzJRU2EH7GnIi17iYqrhnipfIXmpSpEYzUb8m70VtxGy BJesHFrOEQU+wK4tVFS60YZNSK2XGketsjUeJycuo0qxoou6qai4yi2dV g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AZBQDAQPFV/xbLJq1dg3dpgya6EYF5h3ISAQEBAQEBAYEKhE1CBwYgFA8hAhECOBQNCAEBBRKIEw2ZT40+j2WUGwEBCAEBAQEehnOHYYFbgzuBQwWHM44jh3eFA4FMhDOCfCORWigDOIQCPDMBiEgBAQE
X-IronPort-AV: E=Sophos;i="5.17,503,1437436800";  d="scan'208,217";a="629638767"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 10 Sep 2015 08:40:06 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8A8e2td001459 for ; Thu, 10 Sep 2015 08:40:03 GMT
From: Benoit Claise 
To: NETMOD Working Group 
Message-ID: <55F141E3.50002@cisco.com>
Date: Thu, 10 Sep 2015 10:40:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------030200080109010908000800"
Archived-At: 
Subject: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 08:40:10 -0000

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

Dear all,

The YANG coordination team 
 has 
spent some time reading and gathering input on the requirements and 
proposed solutions in draft-openconfig-netmod-opstate. This note is to 
collect some observations that will hopefully contribute to progress in 
the working group.

We believe it is useful to consider that YANG was initially designed to 
be a data modeling language for the NETCONF protocol. IETF is also 
working on RESTCONF which is an HTTP-based protocol to access data 
defined in YANG, using the datastores defined in NETCONF.

YANG is fulfilling its intended role with NETCONF and RESTCONF and has 
gained some significant traction in this capacity. There are some 
changes worked on in YANG 1.1, but they are mostly incremental.

There is interest in using other protocols outside of NETCONF and 
RESTCONF to manipulate data described by YANG. The proposals in the 
draft is based on the assertion that YANG models should be usable for 
protocols beyond RESTCONF and NETCONF. So these are new requirements on 
YANG from, or in preparation for, new protocol bindings.

We have focused on two main aspects of the draft.

FIRSTLY: The proposed split between intended and applied configuration 
as described in sections 4.1 (requirements) and 5.1 (implications)

There are two observations here:
1. The implication is that all configurable data nodes ("intended 
configuration") shall be repeated in an operational version ("applied 
configuration") in all models for all applications going forward. This 
would apply independent of if the system is synchronous or asynchronous 
in nature. Synchronous systems would simply hard-wire the applied 
configuration to be the same as intended configuration at all times.
2. An informal round of conversations with some vendors as well as some 
tooling vendors show that there are currently no widely known platforms 
that allow for observing the intended and applied state separately. A 
common architecture includes a central configuration data store that is 
being updated by the manageability framework and updates read by the 
subsystems affected by the change (e.g. the BGP service or the interface 
manager). In this case, there is no other source of configuration except 
for the content of the data store.

Please note that this was not an exhaustive collection of data, but 
should give some directional information.

The *implication* we would like to make here is that by making this 
feature mandatory part of the YANG language itself (as opposed to an 
optional capability) we risk introducing a fake perception that the 
current NETCONF server supports a capability it can't support. Indeed, 
polling the applied configuration would always return the intended 
configuration.

A *question* would be if it would be useful to consider a direction 
where we make an attempt to separate out requirements that are tied to 
specific protocols and solve them in the protocol semantics rather than 
in the language to the extent we can. Without knowing more about the 
intended protocol in the case of this draft, it is hard to make more 
progress.

A *suggestion* is to ask the draft authors to document the protocol 
bindings in order to qualify the requirements going forward.

SECONDLY: The proposed schema locations for configuration and 
corresponding operational state in sections 4.5 (requirements) and 5.4 
(implications)

The observation to be made here is well captured in the draft itself as 
bullet 3 under section 7:

     "The proposal does not allow items that are not configured, 
configured but not present, or system configured."

Please note that this is a general note that would apply to the language 
itself. Meaning that YANG will no longer be able to describe situations 
like the above for any type of application in any context.

Examples beyond what's already mentioned in the bullet of this could 
include:
- Removable physical assets (line cards, mezzanine cards) in systems 
that allow pre-provisioning of configuration
- Physical assets that arrive in the system with readable default state

Independent of the direction we will be taking going forward, the 
implication we make is that it is a pretty significant impact on the 
expressivity of the language itself and how useful it is in terms of 
modeling application data sets that may not align with the requirements.

The question we would ask is if it would be possible to rebalance the 
implication and make it a little more modular and optional in the 
language. We are aware of suggestions to use the extensibility of the 
language itself (e.g. in draft-kwatsen-netmod-opstate) to express 
relations across data sets. Understanding that this suggested approach 
does not normalize the paths according to the wish of the authors, but 
it can perhaps be a balanced approach that impacts the expressivity less.

                         Regards, the YANG coordination team

--------------030200080109010908000800
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    The YANG
      coordination team has spent some time reading and gathering
    input on the requirements and proposed solutions in
    draft-openconfig-netmod-opstate. This note is to collect some
    observations that will hopefully contribute to progress in the
    working group.

    

    We believe it is useful to consider that YANG was initially designed
    to be a data modeling language for the NETCONF protocol. IETF is
    also working on RESTCONF which is an HTTP-based protocol to access
    data defined in YANG, using the datastores defined in NETCONF.

    

    YANG is fulfilling its intended role with NETCONF and RESTCONF and
    has gained some significant traction in this capacity. There are
    some changes worked on in YANG 1.1, but they are mostly incremental.

    

    There is interest in using other protocols outside of NETCONF and
    RESTCONF to manipulate data described by YANG. The proposals in the
    draft is based on the assertion that YANG models should be usable
    for protocols beyond RESTCONF and NETCONF. So these are new
    requirements on YANG from, or in preparation for, new protocol
    bindings.

    

    We have focused on two main aspects of the draft.

    

    FIRSTLY: The proposed split between intended and applied
    configuration as described in sections 4.1 (requirements) and 5.1
    (implications)

    

    There are two observations here:

    1. The implication is that all configurable data nodes ("intended
    configuration") shall be repeated in an operational version
    ("applied configuration") in all models for all applications going
    forward. This would apply independent of if the system is
    synchronous or asynchronous in nature. Synchronous systems would
    simply hard-wire the applied configuration to be the same as
    intended configuration at all times.

    2. An informal round of conversations with some vendors as well as
    some tooling vendors show that there are currently no widely known
    platforms that allow for observing the intended and applied state
    separately. A common architecture includes a central configuration
    data store that is being updated by the manageability framework and
    updates read by the subsystems affected by the change (e.g. the BGP
    service or the interface manager). In this case, there is no other
    source of configuration except for the content of the data store.

    

    Please note that this was not an exhaustive collection of data, but
    should give some directional information.

    

    The *implication* we would like to make here is that by making this
    feature mandatory part of the YANG language itself (as opposed to an
    optional capability) we risk introducing a fake perception that the
    current NETCONF server supports a capability it can't
    support. Indeed, polling the applied configuration would always
    return the intended configuration.

    

    A *question* would be if it would be useful to consider a direction
    where we make an attempt to separate out requirements that are tied
    to specific protocols and solve them in the protocol semantics
    rather than in the language to the extent we can. Without knowing
    more about the intended protocol in the case of this draft, it is
    hard to make more progress.

    

    A *suggestion* is to ask the draft authors to document the protocol
    bindings in order to qualify the requirements going forward.

    

    SECONDLY: The proposed schema locations for configuration and
    corresponding operational state in sections 4.5 (requirements) and
    5.4 (implications)

    

    The observation to be made here is well captured in the draft itself
    as bullet 3 under section 7:

    

        "The proposal does not allow items that are not configured,
    configured but not present, or system configured."

    

    Please note that this is a general note that would apply to the
    language itself. Meaning that YANG will no longer be able to
    describe situations like the above for any type of application in
    any context.

    

    Examples beyond what's already mentioned in the bullet of this could
    include:

    - Removable physical assets (line cards, mezzanine cards) in systems
    that allow pre-provisioning of configuration

    - Physical assets that arrive in the system with readable default
    state

    

    Independent of the direction we will be taking going forward, the
    implication we make is that it is a pretty significant impact on the
    expressivity of the language itself and how useful it is in terms of
    modeling application data sets that may not align with the
    requirements.

    

    The question we would ask is if it would be possible to rebalance
    the implication and make it a little more modular and optional in
    the language. We are aware of suggestions to use the extensibility
    of the language itself (e.g. in draft-kwatsen-netmod-opstate) to
    express relations across data sets. Understanding that this
    suggested approach does not normalize the paths according to the
    wish of the authors, but it can perhaps be a balanced approach that
    impacts the expressivity less.

    

                            Regards, the YANG coordination team

  


--------------030200080109010908000800--


From nobody Thu Sep 10 01:40:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FD91B4160; Thu, 10 Sep 2015 01:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA6XO1T-lllv; Thu, 10 Sep 2015 01:40:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7341B4150; Thu, 10 Sep 2015 01:40: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.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150910084021.8677.61227.idtracker@ietfa.amsl.com>
Date: Thu, 10 Sep 2015 01:40:21 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 08:40:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : JSON Encoding of Data Modeled with YANG
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-yang-json-05.txt
	Pages           : 20
	Date            : 2015-09-10

Abstract:
   This document defines encoding rules for representing configuration,
   state data, RPC operation or action input and output parameters, and
   notifications defined using YANG as JavaScript Object Notation (JSON)
   text.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-05


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 Sep 10 01:46:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346031B420E for ; Thu, 10 Sep 2015 01:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N--VatNnkUFd for ; Thu, 10 Sep 2015 01:46:12 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1579A1B4204 for ; Thu, 10 Sep 2015 01:46:12 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:6c65:7fe3:d7e3:b1aa] (unknown [IPv6:2001:718:1a02:1:6c65:7fe3:d7e3:b1aa]) by mail.nic.cz (Postfix) with ESMTPSA id A7BC2181808 for ; Thu, 10 Sep 2015 10:46:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441874770; bh=n09SZCygjtEm8i28GEJnIDDEfkiTO8Wv3B/+/TNSFjE=; h=From:Date:To; b=UbZBUbV5C9D+Kl6/Dgg1xORje1QcRyiYJ0HNR+pMRMK49QP/NfCz95BJHOAnyROeQ f0mLYZv3c7fMLlWrWPHaeE4gkyEJhDTNx9K9bQvwH/Z/L9CZKLHDmK3bk5cC6m6MfN ASBFYyyEX0QS3XzLeBic5LyKaIlxjA0r34Tm+xEc=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Sep 2015 10:46:10 +0200
References: <20150910084021.8677.6592.idtracker@ietfa.amsl.com>
To: NETMOD Working Group 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 08:46:14 -0000

Hi,

this revision introduces no changes to the encoding rules. The text was =
modified, and hopefully improved, in quite a few places, mainly due to =
Juergen=E2=80=99s review of -04, thanks Juergen.

Lada=20

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-ietf-netmod-yang-json-05.txt
> Date: 10 Sep 2015 10:40:21 CEST
> To: "Ladislav Lhotka" , "Ladislav Lhotka" =

>=20
>=20
> A new version of I-D, draft-ietf-netmod-yang-json-05.txt
> has been successfully submitted by Ladislav Lhotka and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-netmod-yang-json
> Revision:	05
> Title:		JSON Encoding of Data Modeled with YANG
> Document date:	2015-09-10
> Group:		netmod
> Pages:		20
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-05.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-json-05
>=20
> Abstract:
>   This document defines encoding rules for representing configuration,
>   state data, RPC operation or action input and output parameters, and
>   notifications defined using YANG as JavaScript Object Notation =
(JSON)
>   text.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Sep 10 02:02:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650801B4380 for ; Thu, 10 Sep 2015 02:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ0nVYT1yQRd for ; Thu, 10 Sep 2015 02:02:34 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BFF921B4381 for ; Thu, 10 Sep 2015 02:02:33 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id B6E5A1CC0181; Thu, 10 Sep 2015 11:02:31 +0200 (CEST)
From: Ladislav Lhotka 
To: Randy Presuhn , netmod@ietf.org
In-Reply-To: <574764.1441860459985.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
References: <574764.1441860459985.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 10 Sep 2015 11:02:29 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 09:02:35 -0000

Randy Presuhn  writes:

> Hi -
>
>> From: Andy Bierman
>> Sent: Sep 9, 2015 12:10 PM
>> To: Ladislav Lhotka
>> Cc: Robert Wilton , Randy Presuhn , "netmod@ietf.org"
>> Subject: Re: [netmod] Y26 again, sorry
> ...
>> I don't think it really addresses the design pattern very well.
>> You want to claim that M and Q are both being developed at the
>> same time,so it's OK that Q adds mandatory nodes to M.  YANG
>> has no such rule.YANG says a server can implement M and never
>> implement Q.YANG says a server may implement M and then add Q
>> in a future release.These conformance mechanisms do not align
>> with your expectationsof how YANG can/should be used.
>
> I agree with Andy that there seems to be a mismatch in expectations.

I wonder if we can explain these differences. Is your and Andy's
expectation that the configuration schema has to reflect actual hardware
configuration, perhaps even dynamically adjust to the changes?

In my view, the supported (and advertised) data model and hardware
configuration of the device are two different things.

> Let's look at a slightly more complex hypothetical case to tease
> out how folks *want* things to work.  Assume the following have
> been defined:
>
>   - base module M
>   - augmentation Q
>   - augmentation R
>
> On a server claiming to supporting the modules containing M, Q,
> and R, respectively, which of the following might one encounter
> concurrently?
>
>      - plain M
>      - M+Q
>      - M+R
>      - M+Q+R

It depends on what you mean by "encounter" but in terms of datastore
validity the only possible answer IMO is M+Q+R.

Lada

>
> If the answer is "any of the them" (which is what I'd expect)
> how can the modeler exclude specific combinations, and would
> these exclusions be testable as part of a conformance check?
>
> If the answer is anything other than "any of them", how does
> the modeler go about making it possible to handle equivalents
> to the excluded cases, in the event that someone actually does
> need to support functionality equivalent to the excluded cases?
>
> I think this matters because the question of mandatory stuff
> within an augmentation appears to really be a stand-in for
> making an augmentation (at least conditionally) mandatory,
> as well as naturally leading to questions about "non-instantiable"
> stuff done for modeling convenience.
>
> I think Andy is very right to be concerned about this, because
> this is another aspect of the old question of deciding just how
> different two things can be before we give up on trying to claim
> that they are two instances of the same class or in some weaker
> sense "compatible".
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Thu Sep 10 02:19:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165781AC3B1 for ; Thu, 10 Sep 2015 02:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6Q-AKj16_7E for ; Thu, 10 Sep 2015 02:19:06 -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 906771ACDF1 for ; Thu, 10 Sep 2015 02:19:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 541F2A04; Thu, 10 Sep 2015 11:19:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tqyj-tgfJVpQ; Thu, 10 Sep 2015 11:19:04 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Sep 2015 11:19:04 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A47C20048; Thu, 10 Sep 2015 11:19:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GaDXfcKwuWg9; Thu, 10 Sep 2015 11:19:03 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E239E2004E; Thu, 10 Sep 2015 11:19:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E9D263706360; Thu, 10 Sep 2015 11:18:57 +0200 (CEST)
Date: Thu, 10 Sep 2015 11:18:57 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20150910091857.GA37355@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References:   <20150909.082810.104733136913643670.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150909.082810.104733136913643670.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] data tree
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 09:19:09 -0000

On Wed, Sep 09, 2015 at 08:28:10AM +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > Andy argued that the proposed new definition of data tree looks like it
> > is a big tree containing everything, so here is another try,
> > improvements are welcome:
> > 
> > o data tree: An instantiated tree of any data modeled with YANG, i.e.,
> >   one of: configuration, state data, combined configuration and state
> >   data, RPC input, RPC output, notification.
> 
> Looks good to me, with s/RPC/RPC or action/g
>

Yes, an for consistency s/configuration,/configuration data,/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Sep 10 02:20:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E331B4870 for ; Thu, 10 Sep 2015 02:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level: 
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3YcZEGOfzH2 for ; Thu, 10 Sep 2015 02:19:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CFF3A1B485C for ; Thu, 10 Sep 2015 02:19:58 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id F2E3F1AE097A; Thu, 10 Sep 2015 11:19:56 +0200 (CEST)
Date: Thu, 10 Sep 2015 11:19:56 +0200 (CEST)
Message-Id: <20150910.111956.95605506355234383.mbj@tail-f.com>
To: aashaikh@google.com
From: Martin Bjorklund 
In-Reply-To: 
References: <55F09386.4030509@cisco.com> <20150910.094159.1542287559946591076.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 09:20:00 -0000

Hi,

Anees Shaikh  wrote:
> hi -- some additional comments inline.  I think that the revisit on some of
> the operator requirements is primarily due to some proposed solution's
> inability to address them.
> 
> On Thu, Sep 10, 2015 at 12:41 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Benoit Claise  wrote:
> > > 2. The requirements.
> > > If there are still clarifications needed around the requirements in
> > > draft-openconfig-netmod-opstate-01 section 4
> >
> >   4.1.  Applied configuration as part of operational state
> >
> > Already in the title, this requirement mandates the solution.
> >
> > I think the requirement is that if the device is "asynchronous", the
> > operator should (1) be able to learn this fact and (2) be able to
> > retrieve both intended and applied configuration.
> >
> 
> No, the title does not mandate a solution -- it just asserts that
> configuration should be treated as part of the state, or,  in other words,
> what a device is running at any given moment is part of its state

Ok, as long as "part of operational state" does not mean "must be
modelled as config false in YANG".

> -- I do
> agree that it's a different perspective from the thinking that led to the
> limited way in which YANG supports operational state modeling today.
>
> >   4.2.  Support for both transactional, synchronous management systems as
> >       well as distributed, asynchronous management systems
> >
> > If people say that they have systems that work like this, then ok.
> >
> >
> >   4.3.  Separation of configuration and operational state data; ability to
> >       retrieve them independently
> >
> > Ok, but retrieval is going to be a protocol issue, not a language issue.
> >
> 
> Retrieval is not only about the protocol -- the model's structure (in this
> case the ability to indicate state data clearly in the model ) also is
> important.  Limiting this to a protocol issue also presupposes a solution.

Let me rephrase.  I agree that we need to be able to separate
configuration data from operational state data, and this is a language
issue.  However, the protocol needs to support retrieval of them
independently.

> >   4.4.  Ability to retrieve operational state corresponding only to
> >       derived values, statistics, etc.
> >
> > Ok, but retrieval is going to be a protocol issue, not a language issue.
> >
> 
> Again, no -- not only a protocol issue -- same as above (this time you're
> dictating a solution :-) ).   Certainly the model plays a part in
> designating different data items as operational state that reflects applied
> configuration vs. operational state that reflects device-generated data.

Agreed.  See above.

> >   4.5.  Consistent schema locations for configuration and corresponding
> >       operational state data
> >
> > This requirement also mandates the solution in the title.  I think
> > Juergen formulated this requirement better when he wrote that it
> > should be 'easy' to locate state related to config for humans and
> > machines, in a 'robust' way.
> >
> 
> This alternate formulation is not better -- it's just a much vaguer version
> of the requirement that is harder to define

How about "ability to relate configuration with its corresponding
operational state"?   And not use terms like "easy", "robust" etc.

> -- I think we've already seen
> there are very different experiences and ideas about what makes a solution
> easy or robust.   And prioritizing YANG modeling for consumption by humans
> rather than NMSes, automation systems, programmatic interfaces, etc. risks
> defeating the whole purpose of using it IMO.
> 
> 
> >
> >
> > Also, in the introduction, the document says:
> >
> >    These proposals are based on the assertion that YANG models should
> >    be usable via a number of protocols (not solely IETF-defined
> >    protocols such as NETCONF and RESTCONF)
> >
> > I agree with this statement in priniciple, but only if the protocol is
> > suitable for YANG.  I do not agree that YANG should be changed
> > everytime someone says that they want to use YANG with protocol X
> > (especially when protocol X is unknown).  In fact, I believe it is not
> > possible to design a *data* modelling language (see RFC 3444) that can
> > be used for an arbitrary protocol (see
> > draft-schoenw-sming-lessons-01).
> >
> > As an example, I know that some implementations are using YANG with
> > SNMP.  Does this imply that *all* models MUST have some statement to
> > assign an oid with every node?
> >
> 
> 
> No.

Great, then we agree!

> Please note that our proposed solutions have so far required *no*
> changes to YANG other than use of a single extension (which is a supported
> language feature).  Not a single line of pyang was changed to successfully
> compile models that follow the proposed structure.   Let's not confuse
> proposing changes to YANG *models* and introducing conventions with
> requiring changes to the YANG language.

Sure, but the implications of these conventions are such that unless
my YANG module follow these conventions, it cannot be used (other than
in a closed proprietary environment).

> This is not to say that some
> language changes would not make things a bit more sensible -- we have
> worked around those limitations, and most of the changes have been
> identified as needed in other contexts as well (see observations from the
> ODL project, for example).  I expect proposals to be forthcoming.
> 
> 
> 
> >
> > > , or around the
> > > requirement that the YANG models need some sort of hierarchy
> > > (draft-openconfig-netmod-model-structure)
> >
> > I don't think the requirements for this problem are described
> > anywhere?
> >
> 
> Well, you could re-read the thread that you actively participated in
> (Motivations for Structuring Models)  :-)

If the goal of this meeting is to agree on requirements, wouldn't it
help if we had them summarized in one place?

> My read of that discussion (and
> the discussion at the June interim meeting on this topic) was that there
> was no real disagreement on the need for a structure to help organize
> related functionality across the growing set of models  (the ietf-routing
> model is trying to do exactly this for a subset of functionality).

Agreed, and this is a good way to handle this problem.  I.e., define
structure for one function at the time.



/martin


From nobody Thu Sep 10 02:43:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C35F1B5F0E for ; Thu, 10 Sep 2015 02:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46p8rDZkd9Tr for ; Thu, 10 Sep 2015 02:43:34 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345471B5EF4 for ; Thu, 10 Sep 2015 02:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1282; q=dns/txt; s=iport; t=1441878214; x=1443087814; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=woRMaEY9f1cR55nTDoL9INR4pHQJUO8l39SMKir+uu4=; b=Z6LRNMBc0l4NaxjQDYjkjd/hLZsQ5S9SgfPD8BoHttDEYoroBjPi9xde 8R3G8tVMIC8imqIk8yRqHanM36NC4SdzjUpLspdlQFb4HXNjx/LGOlvUw vAW1dDzLTDRS38oJ8NEgT6CryfRo7lEP3JvZGEnZdj+Ym0YayBFigc9yF Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaBAA4UPFV/xbLJq1dygcCggwBAQEBAQGBC4QkAQEEMgEFQBELDgoJFg8JAwIBAgFFBgEMCAEBiCrLJQEBAQEBAQEDAQEBAQEBHIZzhHuFE4QsAQSVVox6iHuRfWOEAjyIfAEBAQ
X-IronPort-AV: E=Sophos;i="5.17,503,1437436800"; d="scan'208";a="606915592"
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; 10 Sep 2015 09:43:32 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8A9hUL7026791; Thu, 10 Sep 2015 09:43:31 GMT
To: Nadeau Thomas , netmod WG 
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com> <20150910060830.GB36798@elstar.local>
From: Benoit Claise 
Message-ID: <55F150C1.9000900@cisco.com>
Date: Thu, 10 Sep 2015 11:43:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150910060830.GB36798@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 09:43:35 -0000

Jrgen,
> On Wed, Sep 09, 2015 at 08:38:35PM -0400, Nadeau Thomas wrote:
>> 	I wanted to set things up for the interim meeting tomorrow. To frame the meeting, we want to achieve two main goals:
>>
>> 	1) close on requirements around a requirement to define a structure for IETF models and the requirements around ops state/models
>>
> I am confused. Benoit pointed to section 4 which has essentially
> requirements concerning the support of asynchronous systems. You seem
> to be talking also about requirements that go beyond that. It would be
> good to know well ahead of time what is exactly on the agenda.
I also mentioned: "or around the requirement that the YANG models need 
some sort of hierarchy (draft-openconfig-netmod-model-structure), like 
for the routing models, ..."

If the group acknowledges that there is a requirement to structure all 
YANG models, basically extending what's done for the routing models, 
that would already be an achievement.
I would like to verify whether my understanding is correct: there is a 
willingness to structure the YANG models at least per technology 
(routing, OAM, for example), and we're debating whether or not "/device" 
is appropriate. This "/device" is a minor point IMO.

Regards, Benoit
>
> /js
>


From nobody Thu Sep 10 02:46:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFCC1B600E for ; Thu, 10 Sep 2015 02:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3CWlSdHbHeg for ; Thu, 10 Sep 2015 02:46:32 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2A1B6058 for ; Thu, 10 Sep 2015 02:46:31 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4D2C21CC0181; Thu, 10 Sep 2015 11:46:31 +0200 (CEST)
From: Ladislav Lhotka 
To: Benoit Claise , NETMOD Working Group 
In-Reply-To: <55F141E3.50002@cisco.com>
References: <55F141E3.50002@cisco.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 10 Sep 2015 11:46:30 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on	draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 09:46:34 -0000

Hi,

comments inline.

Benoit Claise  writes:

> Dear all,
>
> The YANG coordination team 
>  has 
> spent some time reading and gathering input on the requirements and 
> proposed solutions in draft-openconfig-netmod-opstate. This note is to 
> collect some observations that will hopefully contribute to progress in 
> the working group.
>
> We believe it is useful to consider that YANG was initially designed to 
> be a data modeling language for the NETCONF protocol. IETF is also 
> working on RESTCONF which is an HTTP-based protocol to access data 
> defined in YANG, using the datastores defined in NETCONF.
>
> YANG is fulfilling its intended role with NETCONF and RESTCONF and has 
> gained some significant traction in this capacity. There are some 
> changes worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and 
> RESTCONF to manipulate data described by YANG. The proposals in the 
> draft is based on the assertion that YANG models should be usable for 
> protocols beyond RESTCONF and NETCONF. So these are new requirements on 
> YANG from, or in preparation for, new protocol bindings.
>
> We have focused on two main aspects of the draft.
>
> FIRSTLY: The proposed split between intended and applied configuration 
> as described in sections 4.1 (requirements) and 5.1 (implications)
>
> There are two observations here:
> 1. The implication is that all configurable data nodes ("intended 
> configuration") shall be repeated in an operational version ("applied 
> configuration") in all models for all applications going forward. This 
> would apply independent of if the system is synchronous or asynchronous 
> in nature. Synchronous systems would simply hard-wire the applied 
> configuration to be the same as intended configuration at all times.
> 2. An informal round of conversations with some vendors as well as some 
> tooling vendors show that there are currently no widely known platforms 
> that allow for observing the intended and applied state separately. A 
> common architecture includes a central configuration data store that is 
> being updated by the manageability framework and updates read by the 
> subsystems affected by the change (e.g. the BGP service or the interface 
> manager). In this case, there is no other source of configuration except 
> for the content of the data store.

It may be because vendors tend to limit user access to the device
configuration to a few official interfaces.

In contrast, consider for example a typical Linux system. No matter what
"official" configuration system is used (init scripts, NetworkManager,
UCI in OpenWRT, even NETCONF), there is always a way to change the
run-time configuration without the official configuration system being
notified. For instance, one can go to the /proc filesystem and change
many kernel parameters on the fly, such as IP addresses assigned to
interfaces.

Since I am mainly interested in such open systems, I do see a use case
for making the distinction between intended and applied
configuration. And by the way, it might help solve the NETCONF/I2RS
dilemma: NETCONF/RESTCONF would only be allowed to modify intended
configuration whereas I2RS would operate exclusively on applied
configuration.

Finally, most existing NETMOD models in fact already have intended and
applied configuration even if they aren't called so: the applied one is
represented by nodes in *-state trees that are duplicates of
configuration entries.

>
> Please note that this was not an exhaustive collection of data, but 
> should give some directional information.
>
> The *implication* we would like to make here is that by making this 
> feature mandatory part of the YANG language itself (as opposed to an 
> optional capability) we risk introducing a fake perception that the 
> current NETCONF server supports a capability it can't support. Indeed, 
> polling the applied configuration would always return the intended 
> configuration.
>
> A *question* would be if it would be useful to consider a direction 
> where we make an attempt to separate out requirements that are tied to 
> specific protocols and solve them in the protocol semantics rather than 
> in the language to the extent we can. Without knowing more about the 
> intended protocol in the case of this draft, it is hard to make more 
> progress.
>
> A *suggestion* is to ask the draft authors to document the protocol 
> bindings in order to qualify the requirements going forward.
>
> SECONDLY: The proposed schema locations for configuration and 
> corresponding operational state in sections 4.5 (requirements) and 5.4 
> (implications)
>
> The observation to be made here is well captured in the draft itself as 
> bullet 3 under section 7:
>
>      "The proposal does not allow items that are not configured, 
> configured but not present, or system configured."
>
> Please note that this is a general note that would apply to the language 
> itself. Meaning that YANG will no longer be able to describe situations 
> like the above for any type of application in any context.
>
> Examples beyond what's already mentioned in the bullet of this could 
> include:
> - Removable physical assets (line cards, mezzanine cards) in systems 
> that allow pre-provisioning of configuration
> - Physical assets that arrive in the system with readable default
> state

I agree, existing NETMOD modules already support pre-provisioning and
system-controlled components.

Lada

>
> Independent of the direction we will be taking going forward, the 
> implication we make is that it is a pretty significant impact on the 
> expressivity of the language itself and how useful it is in terms of 
> modeling application data sets that may not align with the requirements.
>
> The question we would ask is if it would be possible to rebalance the 
> implication and make it a little more modular and optional in the 
> language. We are aware of suggestions to use the extensibility of the 
> language itself (e.g. in draft-kwatsen-netmod-opstate) to express 
> relations across data sets. Understanding that this suggested approach 
> does not normalize the paths according to the wish of the authors, but 
> it can perhaps be a balanced approach that impacts the expressivity less.
>
>                          Regards, the YANG coordination team
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Thu Sep 10 03:37:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E711B6507 for ; Thu, 10 Sep 2015 03:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klI5UbWvEoT2 for ; Thu, 10 Sep 2015 03:36:59 -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 4C3DE1B650A for ; Thu, 10 Sep 2015 03:36:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 136021278; Thu, 10 Sep 2015 12:36:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rhMqSnqijYMs; Thu, 10 Sep 2015 12:36: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; Thu, 10 Sep 2015 12:36:56 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 906B82004E; Thu, 10 Sep 2015 12:36:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 603OXU_4JCkQ; Thu, 10 Sep 2015 12:36: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 1EC8E20048; Thu, 10 Sep 2015 12:36:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EAC043706433; Thu, 10 Sep 2015 12:36:49 +0200 (CEST)
Date: Thu, 10 Sep 2015 12:36:48 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20150910103646.GA37478@elstar.local>
Mail-Followup-To: Benoit Claise , Nadeau Thomas , netmod WG 
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com> <20150910060830.GB36798@elstar.local> <55F150C1.9000900@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <55F150C1.9000900@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 10:37:01 -0000

On Thu, Sep 10, 2015 at 11:43:29AM +0200, Benoit Claise wrote:
> Jrgen,
> >On Wed, Sep 09, 2015 at 08:38:35PM -0400, Nadeau Thomas wrote:
> >>	I wanted to set things up for the interim meeting tomorrow. To frame 
> >>	the meeting, we want to achieve two main goals:
> >>
> >>	1) close on requirements around a requirement to define a structure 
> >>	for IETF models and the requirements around ops state/models
> >>
> >I am confused. Benoit pointed to section 4 which has essentially
> >requirements concerning the support of asynchronous systems. You seem
> >to be talking also about requirements that go beyond that. It would be
> >good to know well ahead of time what is exactly on the agenda.
> I also mentioned: "or around the requirement that the YANG models need 
> some sort of hierarchy (draft-openconfig-netmod-model-structure), like 
> for the routing models, ..."
> 
> If the group acknowledges that there is a requirement to structure all 
> YANG models, basically extending what's done for the routing models, 
> that would already be an achievement.
> I would like to verify whether my understanding is correct: there is a 
> willingness to structure the YANG models at least per technology 
> (routing, OAM, for example), and we're debating whether or not "/device" 
> is appropriate. This "/device" is a minor point IMO.

I tried to explain this in one of my previous posts. There is a real
challenge ahead to design 'good' models, namely models that are
extensible and maintainable and that remain interoperable over a long
lifetime. This requires to identify and model key core components or
abstractions and getting them 'right' is hard and requires lots of
detailed reviews, discussions, revisions. To me, the discussion where
to root models is somewhat missing the real challenge in front of us.

That said, I believe the previous discussions that led NETMOD to use
the flat roots we have used in various RFCs that define core models
have not been proven broken in the sense that the roots are flawed up
to the point that we should declare failure and throw away RFCs and
running code. And I like to note that models such as ietf-interfaces
or ietf-routing actually provide structure (e.g., interface specific
models are expected to augment the core interface model) but they go
way beyond defining a simple root path. It is these kind of models
that we need. We also need to understand the tension between cohesion
and coupling of data models. Having a single model that every other
model directly or indirectly has to augment provides a coupling that
may prove to be a major headache in 10-15 years from now.

Back to the subject of the thread, the discussion around the support
for asynchronous systems and the discussion around the value of a
common nested root structure for models are in my view two separate
things and we should not mix them.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Sep 10 03:47:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9316B1B2B75 for ; Thu, 10 Sep 2015 03:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfEIfxouvPQj for ; Thu, 10 Sep 2015 03:47:50 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C45B1B2AEA for ; Thu, 10 Sep 2015 03:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1441882070; x=1443091670; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=FV112Hf9Xju7Xs91smYELVESTryhn9hDy8b0xVYjrpQ=; b=k1WPQPtPqyznXK0jM4ss0iVx7tI+aolmaGByJvrB4SoQ7FOOKhGa++sN Z5fHH5yhH+9AMkKehXmmYYlAmydhJXsLCRmWdwP3h2PuuhRIjFCr58EZU TpuV7Rz95Wyt6mFLB1zXRfmOxFzPxzWKQnQKCXhULDB/LEKJs1O9hkR2Y o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBACCX/FV/xbLJq1dg3dpvyQMhS1KAoIOAQEBAQEBgQuEJAEBBAEBASQRNgoRCw4KCRYPCQMCAQIBFTAGAQwGAgEBF4gTDcsVAQEBAQEBAQEBAQEBAQEBAQEBARmGc4R7hQcMhCwBBIx3iF+FCodwgUxGg22CfCORWmOEAT0zAYhIAQEB
X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="606917047"
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; 10 Sep 2015 10:47:48 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8AAlmDu031334; Thu, 10 Sep 2015 10:47:48 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <55F15FD3.3050306@cisco.com>
Date: Thu, 10 Sep 2015 11:47:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] posted: draft-kwatsen-netmod-opstate-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 10:47:53 -0000

Hi Kent,

I've a few comments on draft-kwatsen-netmod-opstate-00:

1) Having a related-state statement seems to be a good solution for 
binding oper nodes to config nodes that are not directly related in the 
data tree.

But I note that the binding is attached to the config node.  I had 
incorrectly read/assumed that the binding would be attached to the 
operational node referring back to the config node.

A couple of potential advantages of attaching the binding on the oper 
node instead of the config node may be:
  - There may be cases where many oper nodes depend on a few config 
nodes (e.g. lots of oper nodes could choose to depend on the IP address 
configured on an interface), so spreading out the related-state 
statements may be beneficial.
- I think that it is more likely that oper nodes will be in other 
modules that depend on, or augment, a module with the dependent config 
node.  Obviously the related-state binding can't be written directly 
inline on the config node because the module dependency would be the 
wrong way round.  This could be achieved by augmenting the config node 
with a related-state statement, but this would seem to be less clear and 
more verbose than putting the related-state statement on the oper node 
itself.


2)  Operation.
Yes, I agree that this is a good addition to NETCONF.


3) The Applied Configuration Capability:
Using a separate datastore to differentiate between intended and applied 
cfg seems like an OK solution to me.

But for a separate datastore solution, it would feel more natural (at 
least to me) to put the intended-cfg in a separate datastore, and having 
the applied-cfg and derived-state in the default running datastore.

My reasoning for this is that logically the flow of config information 
through the system is:
[ (A) candidate cfg ] -> (B) intended cfg -> (C) applied cfg -> (D) 
derived state.

Hence, it seems strange to me that (A - candidate) and (C - applied) 
would each be in separate datastores but (B - intended) and (D - 
derived) are together in the running datastore.

I can appreciate that there may be some issues with making (B - 
intended) a separate datastore (i.e. what does an edit-config request 
mean on the running datastore?), but I think that it has the advantage 
that a  request on the running datastore would return the contents 
of (C - applied) and (D - derived) which is arguably more generally 
useful to an NMS dealing with an async system that presumably already 
knows the contents of (B - intended).

Cheers,
Rob


On 03/09/2015 01:23, Kent Watsen wrote:
> For next week's interim meeting, but feel free to post comments before
> then  ;)
>
> Cheers,
> Kent
>
>
> On 9/2/15, 7:55 PM, "internet-drafts@ietf.org" 
> wrote:
>
>> A new version of I-D, draft-kwatsen-netmod-opstate-00.txt
>> has been successfully submitted by Kent Watsen and posted to the
>> IETF repository.
>>
>> Name:		draft-kwatsen-netmod-opstate
>> Revision:	00
>> Title:		Operational State Enhancements for YANG, NETCONF, and RESTCONF
>> Document date:	2015-09-02
>> Group:		Individual Submission
>> Pages:		12
>> URL:
>> https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>> Htmlized:
>> https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00
>>
>>
>> Abstract:
>>    This document presents enhancements to YANG, NETCONF, and RESTCONF to
>>    better support the definition of and access to operational state
>>    data.
>>
>>                   
>>         
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Thu Sep 10 03:55:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4AE1B3079 for ; Thu, 10 Sep 2015 03:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxn1wqOytFSx for ; Thu, 10 Sep 2015 03:55:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0F1B2EA7 for ; Thu, 10 Sep 2015 03:55:24 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id E21F01AE097A for ; Thu, 10 Sep 2015 12:55:22 +0200 (CEST)
Date: Thu, 10 Sep 2015 12:55:22 +0200 (CEST)
Message-Id: <20150910.125522.373110083925215588.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 10:55:26 -0000

Hi,

I think we agreed that is ok for a YANG 1.1 module to import a YANG
1.0 module.

But should it also be ok for a 1.0 module to import a 1.1 module?

If we make this illegal, we might run into problems.  For example,
ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
and the new version use YANG 1.1.  Is it ok for a server to implement
the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
answer is no, it means that we either have to update all modules to
1.1 more or less at the same time (including vendor models!), or we
keep existing modules on 1.0 "forever".

At the lastest interim, it was suggested that a server that implements
such a combination of models would internally promote the 1.0 module
to 1.1, and thus make this combination legal.

Such a strategy should also be safe for old clients, still treating
the module as being 1.0.

It is a bit unclear what the server should do if the 1.0 module that
it "internally promotes" to 1.1 contains something that is illegal in
1.1, e.g.:

        default "a\xb";

Comments?


/martin


From nobody Thu Sep 10 04:02:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04B31B35B2 for ; Thu, 10 Sep 2015 04:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea_gVR1Kq_-F for ; Thu, 10 Sep 2015 04:02:03 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D0B931B3644 for ; Thu, 10 Sep 2015 04:02:02 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id EEB8E1AE097A; Thu, 10 Sep 2015 13:02:01 +0200 (CEST)
Date: Thu, 10 Sep 2015 13:02:01 +0200 (CEST)
Message-Id: <20150910.130201.232517359814550454.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <55F15FD3.3050306@cisco.com>
References:  <55F15FD3.3050306@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] posted: draft-kwatsen-netmod-opstate-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 11:02:04 -0000

Robert Wilton  wrote:
> Hi Kent,
> 
> I've a few comments on draft-kwatsen-netmod-opstate-00:
> 
> 1) Having a related-state statement seems to be a good solution for
> binding oper nodes to config nodes that are not directly related in
> the data tree.
> 
> But I note that the binding is attached to the config node.  I had
> incorrectly read/assumed that the binding would be attached to the
> operational node referring back to the config node.

We discussed this as well.  We interpreted the requirement from
openconfig to be from config to state though.  Maybe it would be
useful to have both 'related-state' and 'related-config'.

> A couple of potential advantages of attaching the binding on the
> oper node instead of the config node may be:
>
>  - There may be cases where many oper nodes depend on a few config
>    nodes (e.g. lots of oper nodes could choose to depend on the IP
>    address configured on an interface), so spreading out the
>    related-state statements may be beneficial. 
>
> - I think that it is more likely that oper nodes will be in other
>   modules that depend on, or augment, a module with the dependent
>   config node.  Obviously the related-state binding can't be written
>   directly inline on the config node because the module dependency
>   would be the wrong way round.  This could be achieved by augmenting
>   the config node with a related-state statement, but this would seem
>   to be less clear and more verbose than putting the related-state
>   statement on the oper node itself. 
> 
> 
> 2)  Operation.
> Yes, I agree that this is a good addition to NETCONF.
> 
> 
> 3) The Applied Configuration Capability:
> Using a separate datastore to differentiate between intended and
> applied cfg seems like an OK solution to me. 
> 
> But for a separate datastore solution, it would feel more natural
> (at least to me) to put the intended-cfg in a separate datastore,
> and having the applied-cfg and derived-state in the default running
> datastore. 

But running is (sometimes) writable, whereas applied config is always
read-only.

I rather map intended to running, and then define new protocol
operations so that the client can retrieve the necessary data properly
(essentially making current  less useful).


/martin




> My reasoning for this is that logically the flow of config information through the system is:
> [ (A) candidate cfg ] -> (B) intended cfg -> (C) applied cfg -> (D)
> derived state.
> 
> Hence, it seems strange to me that (A - candidate) and (C - applied)
> would each be in separate datastores but (B - intended) and (D -
> derived) are together in the running datastore. 
> 
> I can appreciate that there may be some issues with making (B -
> intended) a separate datastore (i.e. what does an edit-config
> request mean on the running datastore?), but I think that it has the
> advantage that a  request on the running datastore would return
> the contents of (C - applied) and (D - derived) which is arguably
> more generally useful to an NMS dealing with an async system that
> presumably already knows the contents of (B - intended).
> 
> Cheers,
> Rob
> 
> 
> On 03/09/2015 01:23, Kent Watsen wrote:
> > For next week's interim meeting, but feel free to post comments before
> > then  ;)
> >
> > Cheers,
> > Kent
> >
> >
> > On 9/2/15, 7:55 PM, "internet-drafts@ietf.org" 
> > wrote:
> >
> >> A new version of I-D, draft-kwatsen-netmod-opstate-00.txt
> >> has been successfully submitted by Kent Watsen and posted to the
> >> IETF repository.
> >>
> >> Name:		draft-kwatsen-netmod-opstate
> >> Revision:	00
> >> Title:		Operational State Enhancements for YANG, NETCONF, and RESTCONF
> >> Document date:	2015-09-02
> >> Group:		Individual Submission
> >> Pages:		12
> >> URL:
> >> https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt
> >> Status:
> >> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
> >> Htmlized:
> >> https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00
> >>
> >>
> >> Abstract:
> >>    This document presents enhancements to YANG, NETCONF, and RESTCONF to
> >>    better support the definition of and access to operational state
> >>    data.
> >>
> >>                           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.
> >>
> >> The IETF Secretariat
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Sep 10 04:20:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4781B3172 for ; Thu, 10 Sep 2015 04:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUXPbsVmB3hr for ; Thu, 10 Sep 2015 04:20:24 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9981B40E2 for ; Thu, 10 Sep 2015 04:20:23 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:6c65:7fe3:d7e3:b1aa] (unknown [IPv6:2001:718:1a02:1:6c65:7fe3:d7e3:b1aa]) by mail.nic.cz (Postfix) with ESMTPSA id 61FDA181805; Thu, 10 Sep 2015 13:20:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441884022; bh=sgvc8kwxNUIcyH6tO0O4lstuzmjAEnoy2dsEcV2HbOw=; h=From:Date:To; b=QOUxcIUxq8KqAY5pwW1qtm7bX+uGKPFdwrmBotxMGF3v9ZL4YtbCOiK8VN6twLeGN SfhHi2swCjhnILU3gTlYKv0QZ6pdh5nQGr+CthVFTnE/hn0v4MfMXI57aMrQDLQ1cf DTWHb4wCu6J4T1h7ZbP2fpU6G/p6Bwn4mNjQ9+9w=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150910.125522.373110083925215588.mbj@tail-f.com>
Date: Thu, 10 Sep 2015 13:20:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 11:20:26 -0000

> On 10 Sep 2015, at 12:55, Martin Bjorklund  wrote:
>=20
> Hi,
>=20
> I think we agreed that is ok for a YANG 1.1 module to import a YANG
> 1.0 module.
>=20
> But should it also be ok for a 1.0 module to import a 1.1 module?

I think it should be illegal for a 1.0 module to import with revision if =
the requested revision is 1.1.

>=20
> If we make this illegal, we might run into problems.  For example,
> ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
> and the new version use YANG 1.1.  Is it ok for a server to implement
> the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
> answer is no, it means that we either have to update all modules to
> 1.1 more or less at the same time (including vendor models!), or we
> keep existing modules on 1.0 "forever".
>=20
> At the lastest interim, it was suggested that a server that implements
> such a combination of models would internally promote the 1.0 module
> to 1.1, and thus make this combination legal.

I think we need a way for the server to identify itself to the client as =
1.1-capable, and then:

- 1.1-capable server: if 1.0 module X imports Y *without revision*, and =
the revision of Y advertised by the server (with default-revision=3Dtrue),=
 then module X is automatically interpreted as 1.1.

- 1.0-only server: if 1.0 module X import Y without revision, then the =
latest 1.0 revision of Y is used. If 1.1 revisions exist, they are not =
used.

>=20
> Such a strategy should also be safe for old clients, still treating
> the module as being 1.0.

I am not sure about this, I think a 1.0-only client cannot work with a =
1.1-capable server is some 1.1 additions are used (e.g. if-feature =
expressions).

>=20
> It is a bit unclear what the server should do if the 1.0 module that
> it "internally promotes" to 1.1 contains something that is illegal in
> 1.1, e.g.:
>=20
>        default "a\xb=E2=80=9D;

We should write an erratum to 6020 making this illegal in 1.0, too.

Lada

>=20
> Comments?
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Sep 10 04:43:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7633B1B32E6 for ; Thu, 10 Sep 2015 04:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65omsB790Lnz for ; Thu, 10 Sep 2015 04:43:31 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C2A941A1A64 for ; Thu, 10 Sep 2015 04:43:30 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 54CD11CC0181; Thu, 10 Sep 2015 13:43:30 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin =?utf-8?Q?Bj=C3=B6rklund?= 
In-Reply-To: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com> 
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 10 Sep 2015 13:43:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 11:43:32 -0000

Ladislav Lhotka  writes:

>> On 10 Sep 2015, at 12:55, Martin Bjorklund  wrote:
>>=20
>> Hi,
>>=20
>> I think we agreed that is ok for a YANG 1.1 module to import a YANG
>> 1.0 module.
>>=20
>> But should it also be ok for a 1.0 module to import a 1.1 module?
>
> I think it should be illegal for a 1.0 module to import with revision if =
the requested revision is 1.1.
>
>>=20
>> If we make this illegal, we might run into problems.  For example,
>> ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
>> and the new version use YANG 1.1.  Is it ok for a server to implement
>> the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
>> answer is no, it means that we either have to update all modules to
>> 1.1 more or less at the same time (including vendor models!), or we
>> keep existing modules on 1.0 "forever".
>>=20
>> At the lastest interim, it was suggested that a server that implements
>> such a combination of models would internally promote the 1.0 module
>> to 1.1, and thus make this combination legal.
>
> I think we need a way for the server to identify itself to the client as =
1.1-capable, and then:
>
> - 1.1-capable server: if 1.0 module X imports Y *without revision*,
> and the revision of Y advertised by the server (with
> default-revision=3Dtrue), then module X is automatically interpreted as
> 1.1.

Correction:

- 1.1-capable server: if 1.0 module X imports Y *without revision*, and
  the revision of Y advertised by the server (with
  default-revision=3Dtrue) is 1.1, then module X is automatically
  interpreted as 1.1.

Lada

>
> - 1.0-only server: if 1.0 module X import Y without revision, then the la=
test 1.0 revision of Y is used. If 1.1 revisions exist, they are not used.
>
>>=20
>> Such a strategy should also be safe for old clients, still treating
>> the module as being 1.0.
>
> I am not sure about this, I think a 1.0-only client cannot work with a 1.=
1-capable server is some 1.1 additions are used (e.g. if-feature expression=
s).
>
>>=20
>> It is a bit unclear what the server should do if the 1.0 module that
>> it "internally promotes" to 1.1 contains something that is illegal in
>> 1.1, e.g.:
>>=20
>>        default "a\xb=E2=80=9D;
>
> We should write an erratum to 6020 making this illegal in 1.0, too.
>
> Lada
>
>>=20
>> Comments?
>>=20
>>=20
>> /martin
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Thu Sep 10 04:45:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52A81B50D6 for ; Thu, 10 Sep 2015 04:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtPMwjMRtGVF for ; Thu, 10 Sep 2015 04:45:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB31B4320 for ; Thu, 10 Sep 2015 04:45:01 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id B25911AE097A; Thu, 10 Sep 2015 13:45:00 +0200 (CEST)
Date: Thu, 10 Sep 2015 13:45:00 +0200 (CEST)
Message-Id: <20150910.134500.743921822231000218.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 11:45:03 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTAgU2Vw
IDIwMTUsIGF0IDEyOjU1LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6
DQo+ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4gSSB0aGluayB3ZSBhZ3JlZWQgdGhhdCBpcyBvayBm
b3IgYSBZQU5HIDEuMSBtb2R1bGUgdG8gaW1wb3J0IGEgWUFORw0KPiA+IDEuMCBtb2R1bGUuDQo+
ID4gDQo+ID4gQnV0IHNob3VsZCBpdCBhbHNvIGJlIG9rIGZvciBhIDEuMCBtb2R1bGUgdG8gaW1w
b3J0IGEgMS4xIG1vZHVsZT8NCj4gDQo+IEkgdGhpbmsgaXQgc2hvdWxkIGJlIGlsbGVnYWwgZm9y
IGEgMS4wIG1vZHVsZSB0byBpbXBvcnQgd2l0aCByZXZpc2lvbg0KPiBpZiB0aGUgcmVxdWVzdGVk
IHJldmlzaW9uIGlzIDEuMS4NCg0KT2suDQoNCj4gPiBJZiB3ZSBtYWtlIHRoaXMgaWxsZWdhbCwg
d2UgbWlnaHQgcnVuIGludG8gcHJvYmxlbXMuICBGb3IgZXhhbXBsZSwNCj4gPiBpZXRmLWlwIGlt
cG9ydHMgaWV0Zi1pbnRlcmZhY2VzLiAgU3VwcG9zZSB3ZSB1cGRhdGUgaWV0Zi1pbnRlcmZhY2Vz
DQo+ID4gYW5kIHRoZSBuZXcgdmVyc2lvbiB1c2UgWUFORyAxLjEuICBJcyBpdCBvayBmb3IgYSBz
ZXJ2ZXIgdG8gaW1wbGVtZW50DQo+ID4gdGhlIDEuMCB2ZXJzaW9uIG9mIGlldGYtaXAgYW5kIDEu
MSB2ZXJzaW9uIG9mIGlldGYtaW50ZXJmYWNlcz8gIElmIHRoZQ0KPiA+IGFuc3dlciBpcyBubywg
aXQgbWVhbnMgdGhhdCB3ZSBlaXRoZXIgaGF2ZSB0byB1cGRhdGUgYWxsIG1vZHVsZXMgdG8NCj4g
PiAxLjEgbW9yZSBvciBsZXNzIGF0IHRoZSBzYW1lIHRpbWUgKGluY2x1ZGluZyB2ZW5kb3IgbW9k
ZWxzISksIG9yIHdlDQo+ID4ga2VlcCBleGlzdGluZyBtb2R1bGVzIG9uIDEuMCAiZm9yZXZlciIu
DQo+ID4gDQo+ID4gQXQgdGhlIGxhc3Rlc3QgaW50ZXJpbSwgaXQgd2FzIHN1Z2dlc3RlZCB0aGF0
IGEgc2VydmVyIHRoYXQgaW1wbGVtZW50cw0KPiA+IHN1Y2ggYSBjb21iaW5hdGlvbiBvZiBtb2Rl
bHMgd291bGQgaW50ZXJuYWxseSBwcm9tb3RlIHRoZSAxLjAgbW9kdWxlDQo+ID4gdG8gMS4xLCBh
bmQgdGh1cyBtYWtlIHRoaXMgY29tYmluYXRpb24gbGVnYWwuDQo+IA0KPiBJIHRoaW5rIHdlIG5l
ZWQgYSB3YXkgZm9yIHRoZSBzZXJ2ZXIgdG8gaWRlbnRpZnkgaXRzZWxmIHRvIHRoZSBjbGllbnQN
Cj4gYXMgMS4xLWNhcGFibGUsIGFuZCB0aGVuOg0KPiANCj4gLSAxLjEtY2FwYWJsZSBzZXJ2ZXI6
IGlmIDEuMCBtb2R1bGUgWCBpbXBvcnRzIFkgKndpdGhvdXQgcmV2aXNpb24qLCBhbmQNCj4gICB0
aGUgcmV2aXNpb24gb2YgWSBhZHZlcnRpc2VkIGJ5IHRoZSBzZXJ2ZXIgKHdpdGgNCj4gICBkZWZh
dWx0LXJldmlzaW9uPXRydWUpLCB0aGVuIG1vZHVsZSBYIGlzIGF1dG9tYXRpY2FsbHkgaW50ZXJw
cmV0ZWQgYXMNCj4gICAxLjEuDQoNCkkgYXNzdW1lIHlvdSBtZWFuIHRoYXQgWSBpcyAxLjEuDQoN
Cj4gLSAxLjAtb25seSBzZXJ2ZXI6IGlmIDEuMCBtb2R1bGUgWCBpbXBvcnQgWSB3aXRob3V0IHJl
dmlzaW9uLCB0aGVuIHRoZQ0KPiAgIGxhdGVzdCAxLjAgcmV2aXNpb24gb2YgWSBpcyB1c2VkLiBJ
ZiAxLjEgcmV2aXNpb25zIGV4aXN0LCB0aGV5IGFyZSBub3QNCj4gICB1c2VkLg0KDQpZZXMuDQoN
Cj4gPiBTdWNoIGEgc3RyYXRlZ3kgc2hvdWxkIGFsc28gYmUgc2FmZSBmb3Igb2xkIGNsaWVudHMs
IHN0aWxsIHRyZWF0aW5nDQo+ID4gdGhlIG1vZHVsZSBhcyBiZWluZyAxLjAuDQo+IA0KPiBJIGFt
IG5vdCBzdXJlIGFib3V0IHRoaXMsIEkgdGhpbmsgYSAxLjAtb25seSBjbGllbnQgY2Fubm90IHdv
cmsgd2l0aCBhDQo+IDEuMS1jYXBhYmxlIHNlcnZlciBpcyBzb21lIDEuMSBhZGRpdGlvbnMgYXJl
IHVzZWQgKGUuZy4gaWYtZmVhdHVyZQ0KPiBleHByZXNzaW9ucykuDQoNCk5vdGUgdGhhdCB0aGUg
MS4wIGNsaWVudCB3b3JrZWQgd2l0aCB0aGUgMS4wIHNlcnZlciB3aXRoIDEuMCBtb2R1bGVzIFgN
CmFuZCBZIGJlZm9yZS4gIE5vdyBZIGlzIHVwZGF0ZWQgdG8gMS4xLiAgQWNjb3JkaW5nIHRvIHNl
Y3Rpb24gMTAsIFkgaXMNCm5vdCBhbGxvd2VkIHRvIGFkZCBpZi1mZWF0dXJlIHRvIGV4aXN0aW5n
IGRlZmluaXRpb25zLg0KDQoNCi9tYXJ0aW4NCg0KDQo+ID4gSXQgaXMgYSBiaXQgdW5jbGVhciB3
aGF0IHRoZSBzZXJ2ZXIgc2hvdWxkIGRvIGlmIHRoZSAxLjAgbW9kdWxlIHRoYXQNCj4gPiBpdCAi
aW50ZXJuYWxseSBwcm9tb3RlcyIgdG8gMS4xIGNvbnRhaW5zIHNvbWV0aGluZyB0aGF0IGlzIGls
bGVnYWwgaW4NCj4gPiAxLjEsIGUuZy46DQo+ID4gDQo+ID4gICAgICAgIGRlZmF1bHQgImFceGLi
gJ07DQo+IA0KPiBXZSBzaG91bGQgd3JpdGUgYW4gZXJyYXR1bSB0byA2MDIwIG1ha2luZyB0aGlz
IGlsbGVnYWwgaW4gMS4wLCB0b28uDQo+IA0KPiBMYWRhDQo+IA0KPiA+IA0KPiA+IENvbW1lbnRz
Pw0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4g
PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZA0KPiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQ
R1AgS2V5IElEOiBFNzRFOEMwQw0KPiANCj4gDQo+IA0KPiANCg==


From nobody Thu Sep 10 05:04:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E33F1B4B63 for ; Thu, 10 Sep 2015 05:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHizyXzRItQK for ; Thu, 10 Sep 2015 05:04:28 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 3F6831AD09D for ; Thu, 10 Sep 2015 05:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441886593; bh=LKHCMrR/C5kRECDwZD7mI4dVQjyKwzb6wREU7BL1t3o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tIta4frbnHD3osEzJaYeyQ9tS2sbNZ4XYGLj+OSdwjZ7Ekd/ZS+1TVogqANAz756l LyJdti70i4J65hg7CJkvBpo0GTe4IbcppkiRjYaBQqeW2pcleC2CLcr05+8r2btnn/ F/eUvOT7rc7qjP6s/Om8FdM7wxGea8ZrhSHI60P4=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA56B7FB-D1BC-48AE-8EE8-882552F59C37"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Thu, 10 Sep 2015 08:04:20 -0400
Message-Id: <98F0E77B-4FF6-4783-9DB3-A60C00E05703@lucidvision.com>
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Unknown ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 1, First 118, in=1550, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:04:33 -0000

--Apple-Mail=_FA56B7FB-D1BC-48AE-8EE8-882552F59C37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


	This is a good point. This is as yet, undefined.  We should =
explicitly specify this.

	=E2=80=94Tom


> On Sep 9, 2015:9:01 PM, at 9:01 PM, Andy Bierman  =
wrote:
>=20
> Hi,
>=20
> This email and the one from Benoit do not mention any sort of problem =
scope.
> IMO it would be useful to know if the scope includes all YANG modules, =
only IETF
> YANG modules, or perhaps only IETF routing modules. As the scope gets =
wider,
> the probability that "1 size fits all" goes way down.
>=20
>=20
> Andy
>=20
>=20
> On Wed, Sep 9, 2015 at 5:38 PM, Nadeau Thomas > wrote:
>=20
>         I wanted to set things up for the interim meeting tomorrow. To =
frame the meeting, we want to achieve two main goals:
>=20
>         1) close on requirements around a requirement to define a =
structure for IETF models and the requirements around ops state/models
>=20
>         2) discuss/debate/understand the differences between the 3 =
different solution approaches as described in =
draft-openconfig-netmod-opstate-01, draft-kwatsen-netmod-opstate, =
draft-wilton-netmod-opstate-yang.  While I understand the last two =
drafts are relatively new, they are there and have been for a time =
sufficient to read and ask questions on the list of the authors.
>=20
>         To this end, I=E2=80=99d like to steer the discussion in the =
direction of having direct questions/debate over those solutions. I=E2=80=99=
d like a representative author from each draft lead each of their =
sections.   If time still exists, I=E2=80=99d like to let Kent (speaking =
as co-chair), objectively compare pros/cons of each solution.  I =
understand that we allocated an hour for tomorrow. We incorrectly =
anticipated a single draft to be compared to the existing opsstate =
draft.  If we need additional time, a second meeting will be planned for =
hopefully next week, so that we can tie things off.
>=20
>=20
>         This is the proposed agenda for tomorrow=E2=80=99s meeting.
>=20
>         0) Agenda Bashing - Tom/2 min
>=20
>         1) Statement from the AD:
>                 Please read =
http://www.ietf.org/mail-archive/web/netmod/current/msg13510.html =

>=20
>         1) Requirements - Tom/15 min
>           - goal is to close on consensus (to be confirmed on list)
>               on the problem statement/requirements, as described in
>               draft-openconfig-netmod-opstate-01, Sections 3 & 4, and
>               implied in draft-openconfig-netmod-model-structure-00
>               (yes, we'll need to write them down), as well as any
>               other requirements not covered by the above.
>             - please come prepared to discuss and finalize these
>=20
>=20
>         2) Questions/Comments about each specific draft - 15 minutes =
for each
>                 A rep for each draft (Martin?, Wilton?, Anees?)
>=20
>            - to be led by a representative for each draft
>               (Martin?, Wilton?, Anees?)
>             - this is not intended to be a presentation of these =
solution
>               so much as an opportunity to ask questions of the =
authors
>               regarding any aspect of the presented solution.
>             - everyone should come prepared having already read these =
drafts.
>             - if there are no questions, we'll move on to the next =
draft
>               right away.
>=20
>         3) Compare and contrast the solutions () - rest of the time, =
if time permits. Kent (as co-chair)
>=20
>             - goal is to up-level the conversation to direct =
comparison
>               of the various solutions.
>=20
>=20
>         Finally, I=E2=80=99d like to ask for a volunteer to take notes =
as well as someone to run the Etherpad.
>=20
>=20
>         WebEx Details:
>=20
>=20
>=20
>=20
> >>>
> >>> NETMOD Working Group invites you to join this WebEx meeting.
> >>>
> >>> NETMOD Interm meeting on OpenConfig
> >>> Thursday, September 10, 2015
> >>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr
> >>>
> >>> Join WebEx meeting
> >>> Meeting number:     645 732 277
> >>> Meeting password:   1234
> >>>
> >>> Join by phone
> >>> 1-877-668-4493 Call-in toll free number (US/Canada)
> >>> 1-650-479-3208 Call-in toll number (US/Canada)
> >>> Access code: 645 732 277
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

>=20


--Apple-Mail=_FA56B7FB-D1BC-48AE-8EE8-882552F59C37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



	This is a =
good point. This is as yet, undefined.  We should explicitly =
specify this.

	=
=E2=80=94Tom


On Sep 9, 2015:9:01 PM, at 9:01 PM, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

This email and the one from Benoit do not mention any sort of =
problem scope.
IMO it would be useful to know if =
the scope includes all YANG modules, only IETF
YANG =
modules, or perhaps only IETF routing modules. As the scope gets =
wider,
the probability that "1 size fits all" goes =
way down.


Andy


On Wed, Sep 9, 2015 at 5:38 PM, Nadeau Thomas =
<tnadeau@lucidvision.com> wrote:


        I wanted to set things up for the interim =
meeting tomorrow. To frame the meeting, we want to achieve two main =
goals:



        1) close on requirements around a =
requirement to define a structure for IETF models and the requirements =
around ops state/models



        2) discuss/debate/understand the differences =
between the 3 different solution approaches as described in =
draft-openconfig-netmod-opstate-01, draft-kwatsen-netmod-opstate, =
draft-wilton-netmod-opstate-yang.  While I understand the last two =
drafts are relatively new, they are there and have been for a time =
sufficient to read and ask questions on the list of the authors.



        To this end, I=E2=80=99d like to steer the =
discussion in the direction of having direct questions/debate over those =
solutions. I=E2=80=99d like a representative author from each draft lead =
each of their sections.   If time still exists, I=E2=80=99d =
like to let Kent (speaking as co-chair), objectively compare pros/cons =
of each solution.  I understand that we allocated an hour for =
tomorrow. We incorrectly anticipated a single draft to be compared to =
the existing opsstate draft.  If we need additional time, a second =
meeting will be planned for hopefully next week, so that we can tie =
things off.





        This is the proposed agenda for tomorrow=E2=80=
=99s meeting.



        0) Agenda Bashing - Tom/2 min



        1) Statement from the AD:

                Please read http://www.ietf.org/mail-archive/web/netmod/current/msg13510.ht=
ml



        1) Requirements - Tom/15 min

          - goal is to close on consensus (to =
be confirmed on list)

              on the problem =
statement/requirements, as described in

              =
draft-openconfig-netmod-opstate-01, Sections 3 & 4, and
=

              implied in =
draft-openconfig-netmod-model-structure-00

              (yes, we'll need to =
write them down), as well as any

              other requirements not =
covered by the above.

            - please come prepared to =
discuss and finalize these





        2) Questions/Comments about each specific =
draft - 15 minutes for each

                A rep for each =
draft (Martin?, Wilton?, Anees?)



           - to be led by a representative =
for each draft

              (Martin?, Wilton?, =
Anees?)

            - this is not intended to be a =
presentation of these solution

              so much as an =
opportunity to ask questions of the authors

              regarding any aspect of =
the presented solution.

            - everyone should come =
prepared having already read these drafts.

            - if there are no questions, =
we'll move on to the next draft

              right away.



        3) Compare and contrast the solutions () - =
rest of the time, if time permits. Kent (as co-chair)



            - goal is to up-level the =
conversation to direct comparison

              of the various =
solutions.





        Finally, I=E2=80=99d like to ask for a =
volunteer to take notes as well as someone to run the Etherpad.





        WebEx Details:









>>>

>>> NETMOD Working Group invites you to join this WebEx =
meeting.

>>>

>>> NETMOD Interm meeting on OpenConfig

>>> Thursday, September 10, 2015

>>> 11:00 am  |  Eastern Daylight Time (New York, =
GMT-04:00)  |  1 hr

>>>

>>> Join WebEx meeting

>>> Meeting number:     645 732 277
=

>>> Meeting password:   1234

>>>

>>> Join by phone

>>> 1-877-668-4493 Call-in toll free number (US/Canada)

>>> 1-650-479-3208 Call-in toll number (US/Canada)
=

>>> Access code: 645 732 277











_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod
=






=

--Apple-Mail=_FA56B7FB-D1BC-48AE-8EE8-882552F59C37--


From nobody Thu Sep 10 05:20:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CA91B5D53 for ; Thu, 10 Sep 2015 05:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7ruP5gqOqdX for ; Thu, 10 Sep 2015 05:20:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8303D1B5D50 for ; Thu, 10 Sep 2015 05:20:07 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id C267B181817; Thu, 10 Sep 2015 14:20:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441887605; bh=Ex0ImkV7hhazz/yOglGCbdj4oQmm+asGePG8D3MYbQ4=; h=From:Date:To; b=FQXNeiL6dpdiLroZyl1fjpllrYCPwXsgVpt6LfLcBrqlxgpVcNLDR5Zu2FE7cF692 k3yiKgmONQa9wGASbtOHYxt/SIp76sC9Zo8eC1V8Ran9yg6rmSjA/h6J5aPVpZgoCs YVAOf93p0n56/JlPdm8R4IN7ij1EkgUS0FkByUcI=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150910.134500.743921822231000218.mbj@tail-f.com>
Date: Thu, 10 Sep 2015 14:20:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com>  <20150910.134500.743921822231000218.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:20:10 -0000

> On 10 Sep 2015, at 13:45, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 10 Sep 2015, at 12:55, Martin Bjorklund  wrote:
>>>=20
>>> Hi,
>>>=20
>>> I think we agreed that is ok for a YANG 1.1 module to import a YANG
>>> 1.0 module.
>>>=20
>>> But should it also be ok for a 1.0 module to import a 1.1 module?
>>=20
>> I think it should be illegal for a 1.0 module to import with revision
>> if the requested revision is 1.1.
>=20
> Ok.
>=20
>>> If we make this illegal, we might run into problems.  For example,
>>> ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
>>> and the new version use YANG 1.1.  Is it ok for a server to =
implement
>>> the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If =
the
>>> answer is no, it means that we either have to update all modules to
>>> 1.1 more or less at the same time (including vendor models!), or we
>>> keep existing modules on 1.0 "forever".
>>>=20
>>> At the lastest interim, it was suggested that a server that =
implements
>>> such a combination of models would internally promote the 1.0 module
>>> to 1.1, and thus make this combination legal.
>>=20
>> I think we need a way for the server to identify itself to the client
>> as 1.1-capable, and then:
>>=20
>> - 1.1-capable server: if 1.0 module X imports Y *without revision*, =
and
>>  the revision of Y advertised by the server (with
>>  default-revision=3Dtrue), then module X is automatically interpreted =
as
>>  1.1.
>=20
> I assume you mean that Y is 1.1.

Yup.

>=20
>> - 1.0-only server: if 1.0 module X import Y without revision, then =
the
>>  latest 1.0 revision of Y is used. If 1.1 revisions exist, they are =
not
>>  used.
>=20
> Yes.
>=20
>>> Such a strategy should also be safe for old clients, still treating
>>> the module as being 1.0.
>>=20
>> I am not sure about this, I think a 1.0-only client cannot work with =
a
>> 1.1-capable server is some 1.1 additions are used (e.g. if-feature
>> expressions).
>=20
> Note that the 1.0 client worked with the 1.0 server with 1.0 modules X
> and Y before.  Now Y is updated to 1.1.  According to section 10, Y is
> not allowed to add if-feature to existing definitions.

New (non-mandatory) nodes may be added to Y that use if-feature =
expressions, new XPath functions etc., and the old client can actually =
receive instances of these nodes in the configuration.

Lada

>=20
>=20
> /martin
>=20
>=20
>>> It is a bit unclear what the server should do if the 1.0 module that
>>> it "internally promotes" to 1.1 contains something that is illegal =
in
>>> 1.1, e.g.:
>>>=20
>>>       default "a\xb=E2=80=9D;
>>=20
>> We should write an erratum to 6020 making this illegal in 1.0, too.
>>=20
>> Lada
>>=20
>>>=20
>>> Comments?
>>>=20
>>>=20
>>> /martin
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Sep 10 05:20:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF65D1B5D69 for ; Thu, 10 Sep 2015 05:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.012
X-Spam-Level: 
X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi5l31nNymcp for ; Thu, 10 Sep 2015 05:20:10 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 B5D6D1B5D39 for ; Thu, 10 Sep 2015 05:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441887534; bh=5GHeo/NDLcta1ggKVy1CsGIf+vL3JYTplSt5uAN10g0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EfnTtDu71ue+kF1eVzbScXpmVyMB2pfaXLMiF/KPx7c7Dmr9xjy+ZSakMgoT4Cfud 48KxkBdmB/shO4nSgOOaue+49J9xnzDBh6tTnPAicMahrUrNfd9UWe3ufVDZHfuqrX 06AfZfsghqdXsSwFiCMzUUUaTgcTzaVTGHDVfHJ8=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <20150910063248.GD36798@elstar.local>
Date: Thu, 10 Sep 2015 08:20:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1553, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:20:11 -0000

> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder =
 wrote:
>=20
> Yes, in my view, section 4.5 goes a bit too far in making a certain
> solution part of the requirement.
>=20
> The solutions that have been written up have different properties in
> terms of data modeling impact, device implementation impact, NMS
> implementation impact and backwards compatibility impact. Furthermore,
> we need to acknowledge that not all devices are asynchronous. These
> aspects need to be taken into account when selecting a solution.
>=20
> What is needed is clarity what the requirements are that we find
> agreement on. I believe it is possible to tweak the text in section 4
> to something people can agree on. But as it is written in -01, I do
> not think we are there yet.

	Is it that you disagree with the specifics of what is written
so that minor refinements would satisfy your need for clarity, or do you
believe there are entire requirements that either do not exist, or =
should
be removed from section 4.5?  If the case is the former, please be =
constructive
and provide proposed changes to the text; if the latter, please specify=20=

that as well.

	=E2=80=94Tom


>=20
> /js
>=20
> On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
>> Juergen,
>>=20
>> It sounds like you are agreeing with the requirements but not the =
solution.=20
>> I think this is a valuable distinction, i.e., that it's possible to =
agree=20
>> with one but not the other.  I'd also like to point out that the =
first part=20
>> of the discussion is limited to requirements only so we can focus on =
the=20
>> former before delving in to the latter .
>>=20
>> Lou
>>=20
>>=20
>> On September 9, 2015 6:01:20 PM Juergen Schoenwaelder=20
>>  wrote:
>>=20
>>> On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
>>>=20
>>>> 2. The requirements.
>>>> If there are still clarifications needed around the requirements in
>>>> draft-openconfig-netmod-opstate-01 section 4, or around the =
requirement
>>>> that the YANG models need some sort of hierarchy
>>>> (draft-openconfig-netmod-model-structure), like for the routing =
models,
>>>> ... tomorrow interim meeting is your chance, or between now and =
then on
>>>> the mailing list.
>>>=20
>>> For the record (since I won't be able to join the call): I disagree
>>> with some of the details in the description of the requirement in
>>> section 4.5. I agree with the part that says that it should be
>>> possible to 'easily' locate the operational state corresponding to
>>> configuration state (and I would add that 'easily' means both for
>>> humans and machines). I would go even further to say that it should
>>> not just be 'easy' but also be 'robust'. What I disagree with is the
>>> part that suggests every 'selector' should be encoded in the schema
>>> path. Note that I am talking about the schema used on a device, I am
>>> not talking about the schema used within an NMS.
>>>=20
>>> /js
>>>=20
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>=20
>>=20
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 10 05:22:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C961B5D53 for ; Thu, 10 Sep 2015 05:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level: 
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHSzAAhLDlfR for ; Thu, 10 Sep 2015 05:21:59 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3282B1B4EA0 for ; Thu, 10 Sep 2015 05:21:58 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Thu, 10 Sep 2015 12:21:55 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Thu, 10 Sep 2015 12:21:55 +0000
From: Kent Watsen 
To: Martin Bjorklund , "aashaikh@google.com" 
Thread-Topic: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
Thread-Index: AQHQ6zxjj8lNuSLDSUGefjLB3380wp41YeCAgAANuoCAAA2kAP//78WA
Date: Thu, 10 Sep 2015 12:21:54 +0000
Message-ID: 
References: <55F09386.4030509@cisco.com> <20150910.094159.1542287559946591076.mbj@tail-f.com>  <20150910.111956.95605506355234383.mbj@tail-f.com>
In-Reply-To: <20150910.111956.95605506355234383.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:cEyWCe1G1NqanDb5mElBNevL4haX8NEnyvq0fHpiLEUm3zSgwMHbHU7vwhHL3UYecZ0bjc+r5KPNHZjYDbcsOYUtWwqYPZzyCAQIEf2UkOWxID9MbX5JkIvozQ+epo4JB2SM2kJNdrPD0acsWlQCXg==; 24:+K3EBrbQx3xO7nD64kWwF6Qqx/lju8uSG3jXIn2Q/pQcj2TAPiWVHKpfEgm6iob1IltiQaJk6TsI9kVEbxhCeGIhRzWhLhk+UUm5X1RV/zQ=; 20:G5iqY8PHmqcmc9t3+tiFpKprV4T/TNXpBh82Y+T6zrvqr02XvHRG7Z6SukjK5xCNE3PUdf0PCiS3PZTjanHO0Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(199003)(189002)(24454002)(377454003)(101416001)(105586002)(2950100001)(106356001)(2900100001)(5001830100001)(93886004)(5001860100001)(122556002)(106116001)(97736004)(66066001)(46102003)(5001770100001)(11100500001)(83506001)(5002640100001)(10400500002)(81156007)(4001540100001)(54356999)(76176999)(50986999)(4001350100001)(40100003)(77156002)(62966003)(19580405001)(64706001)(68736005)(189998001)(5004730100002)(102836002)(5001960100002)(2501003)(87936001)(86362001)(92566002)(99286002)(36756003)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7C27AC745247CC45AAF042614932C57A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2015 12:21:54.8540 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:22:00 -0000

On 9/10/15, 5:19 AM, "Martin Bjorklund"  wrote:

>If the goal of this meeting is to agree on requirements, wouldn't it
>help if we had them summarized in one place?

Yes, we must have a list of requirements that everyone agrees to.   We
will subsequently put it into an email to the WG for final on-list
consensus.  =20


Kent


From nobody Thu Sep 10 05:25:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B761B2A96 for ; Thu, 10 Sep 2015 05:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3I0YShsIJh3 for ; Thu, 10 Sep 2015 05:25:01 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 18E3F1B5F35 for ; Thu, 10 Sep 2015 05:25:01 -0700 (PDT)
Received: (qmail 26691 invoked by uid 0); 10 Sep 2015 12:24:58 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 10 Sep 2015 12:24:58 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id FQQu1r00g2SSUrH01QQxAJ; Thu, 10 Sep 2015 06:24:58 -0600
X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=IFXNed47U8UA:10 a=ff-B7xzCdYMA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=TO6aCCEB_0rY4xCe0vkA:9 a=R7ll5Af61W6XWLOW:21 a=eHVvmq_g8HA-vma0:21 a=CjuIK1q_8ugA:10 a=TF92AUuTpOoA:10 a=HINefQPs-w9PBjTT:21 a=KDDyDu4T4Fga6qxC:21 a=qjNnMIgwBoRgCy9-:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=js2avcEgS6QyVnyYlxy3ZqG4jHlENWG5Hp5wRoiUiQM=;  b=QKvQImnBP/tP5xubhjvx2mnLVmRH86tqLf1bRYRQLn/eKw2xqq6fCGPwcF6SBnHAZea3t7XwKxweE0pmXckz9S1jvXTGdJUhTkfICH7HccdN+l18hl90YVZ2e4xIrLhM;
Received: from [172.56.34.154] (port=20232 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Za0uK-00072R-GB; Thu, 10 Sep 2015 06:24:54 -0600
From: Lou Berger 
To: Benoit Claise , NETMOD Working Group 
Date: Thu, 10 Sep 2015 08:24:51 -0400
Message-ID: <14fb7371e98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <55F141E3.50002@cisco.com>
References: <55F141E3.50002@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------14fb7372f971a1c2818430050d8"
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.34.154 authed with lberger@labn.net}
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:25:04 -0000

This is a multi-part message in MIME format.
------------14fb7372f971a1c2818430050d8
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 8bit

Benoit,

A nit on your mail:


On September 10, 2015 4:40:39 AM Benoit Claise  wrote:

> Dear all,
>
> The YANG coordination team
>  has
> spent some time reading and gathering input on the requirements and
> proposed solutions in draft-openconfig-netmod-opstate. This note is to
> collect some observations that will hopefully contribute to progress in
> the working group.
>
> We believe it is useful to consider that YANG was initially designed to
> be a data modeling language for the NETCONF protocol. IETF is also
> working on RESTCONF which is an HTTP-based protocol to access data
> defined in YANG, using the datastores defined in NETCONF.
>
> YANG is fulfilling its intended role with NETCONF and RESTCONF and has
> gained some significant traction in this capacity. There are some
> changes worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and
> RESTCONF to manipulate data described by YANG. The proposals in the
> draft is based on the assertion that YANG models should be usable for
> protocols beyond RESTCONF and NETCONF. So these are new requirements on
> YANG from, or in preparation for, new protocol bindings.
>
> We have focused on two main aspects of the draft.
>
> FIRSTLY: The proposed split between intended and applied configuration
> as described in sections 4.1 (requirements) and 5.1 (implications)
>
> There are two observations here:
> 1. The implication is that all configurable data nodes ("intended
> configuration") shall be repeated in an operational version ("applied
> configuration") in all models for all applications going forward. This
> would apply independent of if the system is synchronous or asynchronous
> in nature. Synchronous systems would simply hard-wire the applied
> configuration to be the same as intended configuration at all times.
> 2. An informal round of conversations with some vendors as well as some
> tooling vendors show that there are currently no widely known platforms
> that allow for observing the intended and applied state separately. A
> common architecture includes a central configuration data store that is
> being updated by the manageability framework and updates read by the
> subsystems affected by the change (e.g. the BGP service or the interface
> manager). In this case, there is no other source of configuration except
> for the content of the data store.

While this narrow statement is true, every system I know about can provide 
the equivalent of applied config state via show commands.

Lou

>
> Please note that this was not an exhaustive collection of data, but
> should give some directional information.
>
> The *implication* we would like to make here is that by making this
> feature mandatory part of the YANG language itself (as opposed to an
> optional capability) we risk introducing a fake perception that the
> current NETCONF server supports a capability it can't support. Indeed,
> polling the applied configuration would always return the intended
> configuration.
>
> A *question* would be if it would be useful to consider a direction
> where we make an attempt to separate out requirements that are tied to
> specific protocols and solve them in the protocol semantics rather than
> in the language to the extent we can. Without knowing more about the
> intended protocol in the case of this draft, it is hard to make more
> progress.
>
> A *suggestion* is to ask the draft authors to document the protocol
> bindings in order to qualify the requirements going forward.
>
> SECONDLY: The proposed schema locations for configuration and
> corresponding operational state in sections 4.5 (requirements) and 5.4
> (implications)
>
> The observation to be made here is well captured in the draft itself as
> bullet 3 under section 7:
>
>      "The proposal does not allow items that are not configured,
> configured but not present, or system configured."
>
> Please note that this is a general note that would apply to the language
> itself. Meaning that YANG will no longer be able to describe situations
> like the above for any type of application in any context.
>
> Examples beyond what's already mentioned in the bullet of this could
> include:
> - Removable physical assets (line cards, mezzanine cards) in systems
> that allow pre-provisioning of configuration
> - Physical assets that arrive in the system with readable default state
>
> Independent of the direction we will be taking going forward, the
> implication we make is that it is a pretty significant impact on the
> expressivity of the language itself and how useful it is in terms of
> modeling application data sets that may not align with the requirements.
>
> The question we would ask is if it would be possible to rebalance the
> implication and make it a little more modular and optional in the
> language. We are aware of suggestions to use the extensibility of the
> language itself (e.g. in draft-kwatsen-netmod-opstate) to express
> relations across data sets. Understanding that this suggested approach
> does not normalize the paths according to the wish of the authors, but
> it can perhaps be a balanced approach that impacts the expressivity less.
>
>                          Regards, the YANG coordination team
>
>
>
> ----------
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

------------14fb7372f971a1c2818430050d8
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 8bit









Benoit,


A nit on your mail:


On September 10, 2015 4:40:39
AM Benoit Claise <bclaise@cisco.com> wrote:


> Dear all,

>

> The YANG coordination team 

> <http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html>
has 

> spent some time reading and gathering input on the requirements and 

> proposed solutions in draft-openconfig-netmod-opstate. This note is to


> collect some observations that will hopefully contribute to progress
in 

> the working group.

>

> We believe it is useful to consider that YANG was initially designed
to 

> be a data modeling language for the NETCONF protocol. IETF is also 

> working on RESTCONF which is an HTTP-based protocol to access data 

> defined in YANG, using the datastores defined in NETCONF.

>

> YANG is fulfilling its intended role with NETCONF and RESTCONF and has


> gained some significant traction in this capacity. There are some 

> changes worked on in YANG 1.1, but they are mostly incremental.

>

> There is interest in using other protocols outside of NETCONF and 

> RESTCONF to manipulate data described by YANG. The proposals in the 

> draft is based on the assertion that YANG models should be usable for 

> protocols beyond RESTCONF and NETCONF. So these are new requirements
on 

> YANG from, or in preparation for, new protocol bindings.

>

> We have focused on two main aspects of the draft.

>

> FIRSTLY: The proposed split between intended and applied configuration


> as described in sections 4.1 (requirements) and 5.1 (implications)

>

> There are two observations here:

> 1. The implication is that all configurable data nodes ("intended 

> configuration") shall be repeated in an operational version ("applied 

>
configuration") in all models for all applications going forward. This 

> would apply independent of if the system is synchronous or
asynchronous 

> in nature. Synchronous systems would simply hard-wire the applied 

> configuration to be the same as intended configuration at all times.

> 2. An informal round of conversations with some vendors as well as
some 

> tooling vendors show that there are currently no widely known
platforms 

> that allow for observing the intended and applied state separately. A 

> common architecture includes a central configuration data store that
is 

> being updated by the manageability framework and updates read by the 

> subsystems affected by the change (e.g. the BGP service or the
interface 

> manager). In this case, there is no other source of configuration
except 

> for the content of the data store.


While this narrow statement is
true, every system I know about can provide the equivalent of applied
config state via show commands.


Lou


>

> Please note that this was not an exhaustive collection of data, but 

> should give some directional information.

>

> The *implication* we would like to make here is that by making this 

> feature mandatory part of the YANG language itself (as opposed to an 

> optional capability) we risk introducing a fake perception that the 

> current NETCONF server supports a capability it can't support. Indeed,


> polling the applied configuration would always return the intended 

> configuration.

>

> A *question* would be if it would be useful to consider a direction 

> where we make an attempt to separate out requirements that are tied to


> specific protocols and solve them in the protocol semantics rather
than 

> in the language to the extent we can. Without knowing more about the 

> intended protocol in the case of this draft, it is hard to make more 

> progress.

>

> A *suggestion* is to ask the draft authors to document the protocol 

> bindings in order to qualify the requirements going forward.

>

> SECONDLY: The proposed schema locations for configuration and 

> corresponding operational state in sections 4.5 (requirements) and 5.4


> (implications)

>

> The observation to be made here is well captured in the draft itself
as 

> bullet 3 under section 7:

>

>     
"The proposal does not allow items that are not configured, 

> configured but not present, or system configured."

>

> Please note that this is a general note that would apply to the
language 

> itself. Meaning that YANG will no longer be able to describe
situations 

> like the above for any type of application in any context.

>

> Examples beyond what's already mentioned in the bullet of this could 

> include:

> - Removable physical assets (line cards, mezzanine cards) in systems 

> that allow pre-provisioning of configuration

> - Physical assets that arrive in the system with readable default
state

>

> Independent of the direction we will be taking going forward, the 

> implication we make is that it is a pretty significant impact on the 

> expressivity of the language itself and how useful it is in terms of 

> modeling application data sets that may not align with the
requirements.

>

> The question we would ask is if it would be possible to rebalance the 

> implication and make it a little more modular and optional in the 

> language. We are aware of suggestions to use the extensibility of the 

> language itself (e.g. in draft-kwatsen-netmod-opstate) to express 

> relations across data sets. Understanding that this suggested approach


> does not normalize the paths according to the wish of the authors, but


> it can perhaps be a balanced approach that impacts the expressivity
less.

>

>                         
Regards, the YANG coordination team

>

>

>

> ----------

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod

>








------------14fb7372f971a1c2818430050d8--


From nobody Thu Sep 10 05:29:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6843C1B53C8 for ; Thu, 10 Sep 2015 05:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SybEx9IZ_m2P for ; Thu, 10 Sep 2015 05:29:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0F1B2C1F for ; Thu, 10 Sep 2015 05:29:40 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F94C1AE097A; Thu, 10 Sep 2015 14:29:38 +0200 (CEST)
Date: Thu, 10 Sep 2015 14:29:37 +0200 (CEST)
Message-Id: <20150910.142937.1513840100723802033.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20150910.134500.743921822231000218.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:29:41 -0000

Ladislav Lhotka  wrote:
> 
> > On 10 Sep 2015, at 13:45, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> 
> >>> On 10 Sep 2015, at 12:55, Martin Bjorklund  wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> I think we agreed that is ok for a YANG 1.1 module to import a YANG
> >>> 1.0 module.
> >>> 
> >>> But should it also be ok for a 1.0 module to import a 1.1 module?
> >> 
> >> I think it should be illegal for a 1.0 module to import with revision
> >> if the requested revision is 1.1.
> > 
> > Ok.
> > 
> >>> If we make this illegal, we might run into problems.  For example,
> >>> ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
> >>> and the new version use YANG 1.1.  Is it ok for a server to implement
> >>> the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
> >>> answer is no, it means that we either have to update all modules to
> >>> 1.1 more or less at the same time (including vendor models!), or we
> >>> keep existing modules on 1.0 "forever".
> >>> 
> >>> At the lastest interim, it was suggested that a server that implements
> >>> such a combination of models would internally promote the 1.0 module
> >>> to 1.1, and thus make this combination legal.
> >> 
> >> I think we need a way for the server to identify itself to the client
> >> as 1.1-capable, and then:
> >> 
> >> - 1.1-capable server: if 1.0 module X imports Y *without revision*, and
> >>  the revision of Y advertised by the server (with
> >>  default-revision=true), then module X is automatically interpreted as
> >>  1.1.
> > 
> > I assume you mean that Y is 1.1.
> 
> Yup.
> 
> > 
> >> - 1.0-only server: if 1.0 module X import Y without revision, then the
> >>  latest 1.0 revision of Y is used. If 1.1 revisions exist, they are not
> >>  used.
> > 
> > Yes.
> > 
> >>> Such a strategy should also be safe for old clients, still treating
> >>> the module as being 1.0.
> >> 
> >> I am not sure about this, I think a 1.0-only client cannot work with a
> >> 1.1-capable server is some 1.1 additions are used (e.g. if-feature
> >> expressions).
> > 
> > Note that the 1.0 client worked with the 1.0 server with 1.0 modules X
> > and Y before.  Now Y is updated to 1.1.  According to section 10, Y is
> > not allowed to add if-feature to existing definitions.
> 
> New (non-mandatory) nodes may be added to Y that use if-feature
> expressions, new XPath functions etc., and the old client can actually
> receive instances of these nodes in the configuration.

Sure.  But new optional leafs could be added in an upgraded 1.0 model
as well, so the client needs to either be prepared to handle this, or
decide to close the connection when it realizes that it does not
understand all revisions of all data models.


/martin


From nobody Thu Sep 10 05:43:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040311B599A for ; Thu, 10 Sep 2015 05:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dU5UKfgI3Mx for ; Thu, 10 Sep 2015 05:43:30 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF651B4F77 for ; Thu, 10 Sep 2015 05:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4533; q=dns/txt; s=iport; t=1441889006; x=1443098606; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xWARXmxMkifhGvs8lGbw16vi2vvsz5Hb36kMrGCfjH0=; b=ZD/E5trCYsNnPYj1UnigvlQQyXVwBkHII4yiLVGk2NU8YCM06mQZb+5e 516VZqapFvtOQeSgJ3JIHfvdrI5mjnJwO0slsuV7EtikOy+BwIo/Z3VhT r6itOEAR5Jy6GF0nYCre50T3fmgQMSFba0ShAuVk7e4FclzZh9cLBDtrN E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DwAQBhevFV/4gNJK1dgyOBPb0pAQ2HcAKBQzgUAQEBAQEBAYEKhCQBAQMBeQULAgEIBAoELQcyFAMOAgQOBYgmCMtWAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Z0gg6CbIUMB4MYgRQFlVYBjHmBTIdSkVkBHwEBQoQAcYhJAQEB
X-IronPort-AV: E=Sophos;i="5.17,504,1437436800";  d="scan'208,217";a="186720521"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 10 Sep 2015 12:43:26 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t8AChPbB016929 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 12:43:26 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Sep 2015 07:43:25 -0500
Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.000; Thu, 10 Sep 2015 07:43:25 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Lou Berger 
Thread-Topic: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Thread-Index: AQHQ68O+unOoJyevI0yaZqumXcuQd541tQmA
Date: Thu, 10 Sep 2015 12:43:24 +0000
Message-ID: <607103E4-CFE1-4D43-88CE-ECACE0B5B039@cisco.com>
References: <55F141E3.50002@cisco.com>, <14fb7371e98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <14fb7371e98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_607103E4CFE14D4388CEECACE0B5B039ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:43:32 -0000

--_000_607103E4CFE14D4388CEECACE0B5B039ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Lou,

Speaking as an embedded device developer, I think the point here is that up=
 until today there are not very many systems that specifically show the app=
lied config in exactly the same "syntax" as used for providing the intended=
 config. Yes, the applied config can be implied from the output of show com=
mands, but not in a way that is directly correlatable to the config the ope=
rator intended, by either operators themselves or by automation tools.

I completely agree that providing a mechanism whereby management systems an=
d operators can easily see the correlation is important, but we do have to =
realize that this will likely be a non-trivial exercise for embedded system=
s to support this in the way the "opstate" draft or any other draft intends=
 for the distributed or asynchronous use cases, and I speak from experience=
 based on some work we are currently undertaking on similar ideas and apply=
ing them to existing embedded systems.

Cheers,

Einar

On 10 Sep 2015, at 13:25, Lou Berger > wrote:


> 2. An informal round of conversations with some vendors as well as some
> tooling vendors show that there are currently no widely known platforms
> that allow for observing the intended and applied state separately. A
> common architecture includes a central configuration data store that is
> being updated by the manageability framework and updates read by the
> subsystems affected by the change (e.g. the BGP service or the interface
> manager). In this case, there is no other source of configuration except
> for the content of the data store.

While this narrow statement is true, every system I know about can provide =
the equivalent of applied config state via show commands.

--_000_607103E4CFE14D4388CEECACE0B5B039ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Lou,



Speaking as an embedded device developer, I think the point here is that up=
 until today there are not very many systems that specifically show the app=
lied config in exactly the same "syntax" as used for providing th=
e intended config. Yes, the applied config
 can be implied from the output of show commands, but not in a way that is =
directly correlatable to the config the operator intended, by either operat=
ors themselves or by automation tools.







I completely agree that providing a mechanism whereby management syste=
ms and operators can easily see the correlation is important, but we do hav=
e to realize that this will likely be a non-trivial exercise for embedded s=
ystems to support this in the way
 the "opstate" draft or any other draft intends for the distribut=
ed or asynchronous use cases, and I speak from experience based on some wor=
k we are currently undertaking on
similar ideas and applying them to existing embedded systems.







Cheers,







Einar




On 10 Sep 2015, at 13:25, Lou Berger <lberger@labn.net> wrote:








> 2. An informal round of =
conversations with some vendors as well as some


> tooling vendors show that there are currently no widely known platform=
s 

> that allow for observing the intended and applied state separately. A =


> common architecture includes a central configuration data store that i=
s 

> being updated by the manageability framework and updates read by the <=
br>
> subsystems affected by the change (e.g. the BGP service or the interfa=
ce 

> manager). In this case, there is no other source of configuration exce=
pt 

> for the content of the data store.


While this narrow statement i=
s true, every system I know about can provide the equivalent of applied con=
fig state via show commands.








--_000_607103E4CFE14D4388CEECACE0B5B039ciscocom_--


From nobody Thu Sep 10 05:46:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6F1B628C for ; Thu, 10 Sep 2015 05:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.667
X-Spam-Level: 
X-Spam-Status: No, score=-3.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3e50ztY5Smv for ; Thu, 10 Sep 2015 05:46:51 -0700 (PDT)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 43D361B623D for ; Thu, 10 Sep 2015 05:46:51 -0700 (PDT)
Received: (qmail 6946 invoked by uid 0); 10 Sep 2015 12:46:47 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy5.mail.unifiedlayer.com with SMTP; 10 Sep 2015 12:46:47 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id FWSf1r0072SSUrH01WSiZd; Thu, 10 Sep 2015 12:26:46 -0600
X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=IFXNed47U8UA:10 a=ff-B7xzCdYMA:10 a=T0ZuanxOAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=4LPV2hQ7_eIyqLUh6GsA:9 a=0seRMbYgDxWpisbQ:21 a=OOaYADqKsEU9_Mdn:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=eeL6ONiAzC6irt6KAu0u9LoaC1BMbZKeUN/6Ad5IJaU=;  b=UlFKOqktvMKPoiQxiiVdFN5XDt9T+M6WiJCOyn1G747bOj0YdrqkE+Lriz5XnLynnoLuG6KzPy8yao7AI62wnSwPEQ2JOmnQcyiA9LqzCvrRdnKFuEu3KemCLnD6ujSu;
Received: from [172.56.34.154] (port=28835 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Za0w3-0007Re-Kw; Thu, 10 Sep 2015 06:26:40 -0600
From: Lou Berger 
To: Nadeau Thomas , Juergen Schoenwaelder 
Date: Thu, 10 Sep 2015 08:26:38 -0400
Message-ID: <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.34.154 authed with lberger@labn.net}
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:46:53 -0000

I think another question is if the current *requirements* text good /close 
enough for a -00 wg document....

Lou


On September 10, 2015 8:20:34 AM Nadeau Thomas  wrote:

>
>> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder 
>>  wrote:
>>
>> Yes, in my view, section 4.5 goes a bit too far in making a certain
>> solution part of the requirement.
>>
>> The solutions that have been written up have different properties in
>> terms of data modeling impact, device implementation impact, NMS
>> implementation impact and backwards compatibility impact. Furthermore,
>> we need to acknowledge that not all devices are asynchronous. These
>> aspects need to be taken into account when selecting a solution.
>>
>> What is needed is clarity what the requirements are that we find
>> agreement on. I believe it is possible to tweak the text in section 4
>> to something people can agree on. But as it is written in -01, I do
>> not think we are there yet.
>
> 	Is it that you disagree with the specifics of what is written
> so that minor refinements would satisfy your need for clarity, or do you
> believe there are entire requirements that either do not exist, or should
> be removed from section 4.5?  If the case is the former, please be constructive
> and provide proposed changes to the text; if the latter, please specify
> that as well.
>
> 	—Tom
>
>
>>
>> /js
>>
>> On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
>>> Juergen,
>>>
>>> It sounds like you are agreeing with the requirements but not the solution.
>>> I think this is a valuable distinction, i.e., that it's possible to agree
>>> with one but not the other.  I'd also like to point out that the first part
>>> of the discussion is limited to requirements only so we can focus on the
>>> former before delving in to the latter .
>>>
>>> Lou
>>>
>>>
>>> On September 9, 2015 6:01:20 PM Juergen Schoenwaelder
>>>  wrote:
>>>
>>>> On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
>>>>
>>>>> 2. The requirements.
>>>>> If there are still clarifications needed around the requirements in
>>>>> draft-openconfig-netmod-opstate-01 section 4, or around the requirement
>>>>> that the YANG models need some sort of hierarchy
>>>>> (draft-openconfig-netmod-model-structure), like for the routing models,
>>>>> ... tomorrow interim meeting is your chance, or between now and then on
>>>>> the mailing list.
>>>>
>>>> For the record (since I won't be able to join the call): I disagree
>>>> with some of the details in the description of the requirement in
>>>> section 4.5. I agree with the part that says that it should be
>>>> possible to 'easily' locate the operational state corresponding to
>>>> configuration state (and I would add that 'easily' means both for
>>>> humans and machines). I would go even further to say that it should
>>>> not just be 'easy' but also be 'robust'. What I disagree with is the
>>>> part that suggests every 'selector' should be encoded in the schema
>>>> path. Note that I am talking about the schema used on a device, I am
>>>> not talking about the schema used within an NMS.
>>>>
>>>> /js
>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>



From nobody Thu Sep 10 05:52:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC861B530F for ; Thu, 10 Sep 2015 05:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.012
X-Spam-Level: 
X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVS_bzqk_k-5 for ; Thu, 10 Sep 2015 05:52:39 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 82C071B33B6 for ; Thu, 10 Sep 2015 05:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441889484; bh=o5kfihDT8XcifVIJo8djSa7ZfQzL4jdVypxhjo8x60U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZH9N5OejfWaCL8zzDEdBhmyRQVIGpyw+c3Bd4T0+9rRVYFMW7dHP/T0kXpvEYkl+3 KOIXMxsI7drb9BG4jtuP4O8uAEPLf9F2hEcq0Z9I69gRZzA9uUndJL1q29i9qHBRA4 mES35e6W3HZ7ogiDk/Or71htCsjrmOWm3Vj2j0qk=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Date: Thu, 10 Sep 2015 08:52:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com> <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
To: Berger Lou 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=6 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1556, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:52:42 -0000

	The desire from the co-chairs and AD anyways, is that we do not =
start a requirements draft
as a result of today=E2=80=99s meeting (and mailing list confirmation of =
the outcome). As Kent mentioned earlier=20
in this thread, to document this list of detailed requirements on the =
mailing list.  The motivation for this=20
versus a draft, is that waiting for a draft to completely is a drag on =
progress, and we don=E2=80=99t want to=20
gate or slow things down.  Putting them in a place different from the =
existing draft also helps with
the perceptional issues that were raised earlier.

	=E2=80=94Tom


> On Sep 10, 2015:8:26 AM, at 8:26 AM, Lou Berger  =
wrote:
>=20
> I think another question is if the current *requirements* text good =
/close enough for a -00 wg document....
>=20
> Lou
>=20
>=20
> On September 10, 2015 8:20:34 AM Nadeau Thomas =
 wrote:
>=20
>>=20
>>> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> Yes, in my view, section 4.5 goes a bit too far in making a certain
>>> solution part of the requirement.
>>>=20
>>> The solutions that have been written up have different properties in
>>> terms of data modeling impact, device implementation impact, NMS
>>> implementation impact and backwards compatibility impact. =
Furthermore,
>>> we need to acknowledge that not all devices are asynchronous. These
>>> aspects need to be taken into account when selecting a solution.
>>>=20
>>> What is needed is clarity what the requirements are that we find
>>> agreement on. I believe it is possible to tweak the text in section =
4
>>> to something people can agree on. But as it is written in -01, I do
>>> not think we are there yet.
>>=20
>> 	Is it that you disagree with the specifics of what is written
>> so that minor refinements would satisfy your need for clarity, or do =
you
>> believe there are entire requirements that either do not exist, or =
should
>> be removed from section 4.5?  If the case is the former, please be =
constructive
>> and provide proposed changes to the text; if the latter, please =
specify
>> that as well.
>>=20
>> 	=E2=80=94Tom
>>=20
>>=20
>>>=20
>>> /js
>>>=20
>>> On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
>>>> Juergen,
>>>>=20
>>>> It sounds like you are agreeing with the requirements but not the =
solution.
>>>> I think this is a valuable distinction, i.e., that it's possible to =
agree
>>>> with one but not the other.  I'd also like to point out that the =
first part
>>>> of the discussion is limited to requirements only so we can focus =
on the
>>>> former before delving in to the latter .
>>>>=20
>>>> Lou
>>>>=20
>>>>=20
>>>> On September 9, 2015 6:01:20 PM Juergen Schoenwaelder
>>>>  wrote:
>>>>=20
>>>>> On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
>>>>>=20
>>>>>> 2. The requirements.
>>>>>> If there are still clarifications needed around the requirements =
in
>>>>>> draft-openconfig-netmod-opstate-01 section 4, or around the =
requirement
>>>>>> that the YANG models need some sort of hierarchy
>>>>>> (draft-openconfig-netmod-model-structure), like for the routing =
models,
>>>>>> ... tomorrow interim meeting is your chance, or between now and =
then on
>>>>>> the mailing list.
>>>>>=20
>>>>> For the record (since I won't be able to join the call): I =
disagree
>>>>> with some of the details in the description of the requirement in
>>>>> section 4.5. I agree with the part that says that it should be
>>>>> possible to 'easily' locate the operational state corresponding to
>>>>> configuration state (and I would add that 'easily' means both for
>>>>> humans and machines). I would go even further to say that it =
should
>>>>> not just be 'easy' but also be 'robust'. What I disagree with is =
the
>>>>> part that suggests every 'selector' should be encoded in the =
schema
>>>>> path. Note that I am talking about the schema used on a device, I =
am
>>>>> not talking about the schema used within an NMS.
>>>>>=20
>>>>> /js
>>>>>=20
>>>>> --
>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>>>> Fax:   +49 421 200 3103         
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>>=20
>=20
>=20


From nobody Thu Sep 10 05:59:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8AD1A1EF1 for ; Thu, 10 Sep 2015 05:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGJhJRnmKqAa for ; Thu, 10 Sep 2015 05:59:13 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F511A21C2 for ; Thu, 10 Sep 2015 05:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6338; q=dns/txt; s=iport; t=1441889953; x=1443099553; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7ovcDKh2GEPLFPJL5TNTfKiYGdi9G73nzWeVjvacQJ4=; b=JQWxsRflm3Nj/uWKUW5uwMasr2vtEjlhD8Dwvl3tu+RpTEst9EdCd9Mt q/l0qDj01MpCa9FjpuVgbuPcrh0Vzi0wYsnKKe57FRqECr+k80GCRDr2k JVD5QwMULGZAlkceamir4MKrBTycs3w3/MZUFT+fHT03ro8sRTRLfGkoK Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CgBADyffFV/xbLJq1dg3dpvyQMhS1KAoIOAQEBAQEBgQuEIwEBAQMBAQEBJBE2BAYBBQsLDgoJFg8JAwIBAgEVMAYNBgIBAReICwgNy0gBAQEBAQEBAQEBAQEBAQEBAQEBARiGc4R7hEFGBQeELAEEjHeIX4UKh3CBTEaDbYJ8I5FaY4QBPTMBiEgBAQE
X-IronPort-AV: E=Sophos;i="5.17,504,1437436800"; d="scan'208";a="606919849"
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; 10 Sep 2015 12:59:10 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8ACxAZF013788; Thu, 10 Sep 2015 12:59:10 GMT
To: Martin Bjorklund 
References:  <55F15FD3.3050306@cisco.com> <20150910.130201.232517359814550454.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <55F17E9D.9050501@cisco.com>
Date: Thu, 10 Sep 2015 13:59:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150910.130201.232517359814550454.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] posted: draft-kwatsen-netmod-opstate-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 12:59:15 -0000

Hi Martin,

On 10/09/2015 12:02, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Kent,
>>
>> I've a few comments on draft-kwatsen-netmod-opstate-00:
>>
>> 1) Having a related-state statement seems to be a good solution for
>> binding oper nodes to config nodes that are not directly related in
>> the data tree.
>>
>> But I note that the binding is attached to the config node.  I had
>> incorrectly read/assumed that the binding would be attached to the
>> operational node referring back to the config node.
> We discussed this as well.  We interpreted the requirement from
> openconfig to be from config to state though.  Maybe it would be
I just see it as a logical relationship between a config node and an 
oper node.  Even if the direction that the relationship may be used is 
from a config node to the set of possibly impacted oper nodes, the 
relationship could presumably still be specified in the reverse 
direction if that made more sense.

But I actually think that the relationship could be useful in both 
directions, e.g.
1) When updating a config node, being able to subsequently fetch/monitor 
the set of oper nodes that may be impacted to ensure that the change had 
the desired effect.
2) If the NMS detects (or is notified) that an operational node has 
changed (potentially unexpected) to be able to know the set of config 
nodes that could impact that operational node.


> useful to have both 'related-state' and 'related-config'.
>
>> A couple of potential advantages of attaching the binding on the
>> oper node instead of the config node may be:
>>
>>   - There may be cases where many oper nodes depend on a few config
>>     nodes (e.g. lots of oper nodes could choose to depend on the IP
>>     address configured on an interface), so spreading out the
>>     related-state statements may be beneficial.
>>
>> - I think that it is more likely that oper nodes will be in other
>>    modules that depend on, or augment, a module with the dependent
>>    config node.  Obviously the related-state binding can't be written
>>    directly inline on the config node because the module dependency
>>    would be the wrong way round.  This could be achieved by augmenting
>>    the config node with a related-state statement, but this would seem
>>    to be less clear and more verbose than putting the related-state
>>    statement on the oper node itself.
>>
>>
>> 2)  Operation.
>> Yes, I agree that this is a good addition to NETCONF.
>>
>>
>> 3) The Applied Configuration Capability:
>> Using a separate datastore to differentiate between intended and
>> applied cfg seems like an OK solution to me.
>>
>> But for a separate datastore solution, it would feel more natural
>> (at least to me) to put the intended-cfg in a separate datastore,
>> and having the applied-cfg and derived-state in the default running
>> datastore.
> But running is (sometimes) writable, whereas applied config is always
> read-only.
Yes.  I think that the expectation would be:
  - if the server supports an intended-cfg datastore then clients should 
write to that one.
  - for backwards compatibility only, if a client attempts to write 
config to the running datastore, the config request would be routed to 
the intended-cfg datastore instead.

>
> I rather map intended to running, and then define new protocol
> operations so that the client can retrieve the necessary data properly
> (essentially making current  less useful).
Do you mean operations like allowing data to be fetching from multiple 
datastores in one request and merging the trees together in the 
response?  Or something else?

Thanks,
Rob


>
>
> /martin
>
>
>
>
>> My reasoning for this is that logically the flow of config information through the system is:
>> [ (A) candidate cfg ] -> (B) intended cfg -> (C) applied cfg -> (D)
>> derived state.
>>
>> Hence, it seems strange to me that (A - candidate) and (C - applied)
>> would each be in separate datastores but (B - intended) and (D -
>> derived) are together in the running datastore.
>>
>> I can appreciate that there may be some issues with making (B -
>> intended) a separate datastore (i.e. what does an edit-config
>> request mean on the running datastore?), but I think that it has the
>> advantage that a  request on the running datastore would return
>> the contents of (C - applied) and (D - derived) which is arguably
>> more generally useful to an NMS dealing with an async system that
>> presumably already knows the contents of (B - intended).
>>
>> Cheers,
>> Rob
>>
>>
>> On 03/09/2015 01:23, Kent Watsen wrote:
>>> For next week's interim meeting, but feel free to post comments before
>>> then  ;)
>>>
>>> Cheers,
>>> Kent
>>>
>>>
>>> On 9/2/15, 7:55 PM, "internet-drafts@ietf.org" 
>>> wrote:
>>>
>>>> A new version of I-D, draft-kwatsen-netmod-opstate-00.txt
>>>> has been successfully submitted by Kent Watsen and posted to the
>>>> IETF repository.
>>>>
>>>> Name:		draft-kwatsen-netmod-opstate
>>>> Revision:	00
>>>> Title:		Operational State Enhancements for YANG, NETCONF, and RESTCONF
>>>> Document date:	2015-09-02
>>>> Group:		Individual Submission
>>>> Pages:		12
>>>> URL:
>>>> https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>>>> Htmlized:
>>>> https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00
>>>>
>>>>
>>>> Abstract:
>>>>     This document presents enhancements to YANG, NETCONF, and RESTCONF to
>>>>     better support the definition of and access to operational state
>>>>     data.
>>>>
>>>>                            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.
>>>>
>>>> The IETF Secretariat
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> .
>


From nobody Thu Sep 10 06:14:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4405F1B4790 for ; Thu, 10 Sep 2015 06:14:41 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ncwuAJqtNS for ; Thu, 10 Sep 2015 06:14:38 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3131B66C8 for ; Thu, 10 Sep 2015 06:12:51 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Thu, 10 Sep 2015 13:12:47 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Thu, 10 Sep 2015 13:12:47 +0000
From: Kent Watsen 
To: Martin Bjorklund , "rwilton@cisco.com" 
Thread-Topic: [netmod] posted: draft-kwatsen-netmod-opstate-00
Thread-Index: AQHQ5d7F5vaOtbNW5Eu+UYf7uFNYsp41oIWAgAAD+oD//+FxgA==
Date: Thu, 10 Sep 2015 13:12:47 +0000
Message-ID: 
References:  <55F15FD3.3050306@cisco.com> <20150910.130201.232517359814550454.mbj@tail-f.com>
In-Reply-To: <20150910.130201.232517359814550454.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:q6Mhy0Ggs8g7wOcONkBuhnp03hrrQleGI12I3MMzYkawY3RaCwvdQaIOZhD2liGdwg3CbmNOPTaP5mXSoL/+x/h+wui5gA5odj4wuyvGPQgXUAeJNCuMN2SlLmv2tPY4aNFKQv6A100pTIbw3VrU3g==; 24:sDETu+39KOlTAhAxKNtoL6cTAL+rLbutFP1HgzX2a+ZGFb94KEF/Dq/8WHVkVMzAdiad/ozzkvp3mFTZT8SRmkrvRVDK8BRwtOnD+x781t0=; 20:5v0UmMq9czQX4aaCF5iGbgV5WDK+0ztcjEXPm7Cs0FArlFA9v5uOx5d76/uY6xGogpsefQ10dssinNQJURDFKg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(479174004)(377454003)(189002)(51444003)(76176999)(64706001)(50986999)(40100003)(5001830100001)(62966003)(83506001)(2950100001)(77156002)(54356999)(122556002)(5890100001)(4001540100001)(81156007)(5001860100001)(97736004)(87936001)(4001350100001)(5001770100001)(5002640100001)(189998001)(230783001)(2501003)(36756003)(5001960100002)(106356001)(105586002)(101416001)(106116001)(68736005)(102836002)(5007970100001)(5004730100002)(19580395003)(19580405001)(92566002)(46102003)(86362001)(99286002)(11100500001)(2900100001)(99936001)(10400500002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_002_D216F95ED66FDkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2015 13:12:47.4488 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] posted: draft-kwatsen-netmod-opstate-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 13:14:41 -0000

--_002_D216F95ED66FDkwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <68189034B5EEA9408766105BF6DD6020@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable



On 9/10/15, 7:02 AM, "Martin Bjorklund"  wrote:

>Robert Wilton  wrote:
>> Hi Kent,
>>=20
>> I've a few comments on draft-kwatsen-netmod-opstate-00:
>>=20
>> 1) Having a related-state statement seems to be a good solution for
>> binding oper nodes to config nodes that are not directly related in
>> the data tree.
>>=20
>> But I note that the binding is attached to the config node.  I had
>> incorrectly read/assumed that the binding would be attached to the
>> operational node referring back to the config node.
>
>We discussed this as well.  We interpreted the requirement from
>openconfig to be from config to state though.  Maybe it would be
>useful to have both 'related-state' and 'related-config'.

>From a system processing perspective, I'm unsure it matters, in that every
forward pointer implies a reverse pointer.   From a readability
perspective, I think "related-state" makes more sense, as in config begets
state, but am open to a "related-config" statement if it helps.



>> A couple of potential advantages of attaching the binding on the
>> oper node instead of the config node may be:
>>
>>  - There may be cases where many oper nodes depend on a few config
>>    nodes (e.g. lots of oper nodes could choose to depend on the IP
>>    address configured on an interface), so spreading out the
>>    related-state statements may be beneficial.
>>
>> - I think that it is more likely that oper nodes will be in other
>>   modules that depend on, or augment, a module with the dependent
>>   config node.  Obviously the related-state binding can't be written
>>   directly inline on the config node because the module dependency
>>   would be the wrong way round.  This could be achieved by augmenting
>>   the config node with a related-state statement, but this would seem
>>   to be less clear and more verbose than putting the related-state
>>   statement on the oper node itself.

Maybe so. If we pursue this direction, we should exercise these ideas to
ensure the solution we pick withstands these concerns.



>>=20
>>=20
>>=20
>> 2)  Operation.
>> Yes, I agree that this is a good addition to NETCONF.

A loooong overdo addition  ;)



>>=20
>>=20
>> 3) The Applied Configuration Capability:
>> Using a separate datastore to differentiate between intended and
>> applied cfg seems like an OK solution to me.
>>=20
>> But for a separate datastore solution, it would feel more natural
>> (at least to me) to put the intended-cfg in a separate datastore,
>> and having the applied-cfg and derived-state in the default running
>> datastore.=20
>
>But running is (sometimes) writable, whereas applied config is always
>read-only.
>
>I rather map intended to running, and then define new protocol
>operations so that the client can retrieve the necessary data properly
>(essentially making current  less useful).
>
>
>/martin
>
>
>
>
>> My reasoning for this is that logically the flow of config information
>>through the system is:
>> [ (A) candidate cfg ] -> (B) intended cfg -> (C) applied cfg -> (D)
>> derived state.
>>=20
>> Hence, it seems strange to me that (A - candidate) and (C - applied)
>> would each be in separate datastores but (B - intended) and (D -
>> derived) are together in the running datastore.
>>=20
>> I can appreciate that there may be some issues with making (B -
>> intended) a separate datastore (i.e. what does an edit-config
>> request mean on the running datastore?), but I think that it has the
>> advantage that a  request on the running datastore would return
>> the contents of (C - applied) and (D - derived) which is arguably
>> more generally useful to an NMS dealing with an async system that
>> presumably already knows the contents of (B - intended).
>>=20
>> Cheers,
>> Rob


This gets into the ill-defined YANG meta-model, a simple version of which
is provided in Section 3 (Conception Model) and a more complex version is
attached.   In my mind, it is tempting to define something like a
"distinct-intended" capability that would provide read-only access to the
"intended" datastore, so that the combined effects of
running+ephemeral+future-whatever can be observed.

Kent



--_002_D216F95ED66FDkwatsenjunipernet_
Content-Type: image/png; name="yang-meta-model.png"
Content-Description: yang-meta-model.png
Content-Disposition: attachment; filename="yang-meta-model.png"; size=236649;
	creation-date="Thu, 10 Sep 2015 13:12:47 GMT";
	modification-date="Thu, 10 Sep 2015 13:12:47 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAABhwAAASQCAYAAAAHheVnAAAMFWlDQ1BJQ0MgUHJvZmlsZQAASImV
lwdYU8kWx+eWFEISSiACUkJvgvQqvXekg42QBAglhEBQsSOLCq5dRLCiqyAKrgWQxYa9LIK9L4io
rKyLBSyovEkC6PO9/d73Jt/c+8uZc879z2TmZgYABTu2UJiFKgKQLcgXRQV4sxISk1ikPwAZUOCH
BShsTp7QKzIyFPxjGboNEMn9hoUk1z/7/deixOXlcQBAIiGncPM42ZCPAIBrcISifAAIHdCuPztf
KOF3kFVEUCAARLKE02SsKeEUGVtJfWKifCD7AkCmstmiNADokvysAk4azEMXQrYScPkCyDsgu3PS
2VzIXZAnZWfnQFagQjZJ+S5P2r/lTBnPyWanjbOsL9JC9uXnCbPYc//P4fjfJTtLPPYMPVip6aLA
KEmf4bjVZOaESBhqR1oFKeERkJUhX+Rzpf4Svp8uDowd9e/n5PnAMQNMAFDAZfuGQIZjiTLFmbFe
o2zDFkljoT8azs8PihnlFFFO1Gh+tICX5xc9xum8oNDRnMsFWeFjvC2V7x8EGc409Ehheky8TCd6
toAfFw6ZDrkjLzM6ZNT/cWG6T/iYj0gcJdFsAPldqsg/SuaDqWXnjfULs+SwpRrUIHvmp8cEymKx
BF5eQuiYNi7P10+mAePyBLGjmjE4u7yjRmNLhFmRo/7YNl5WQJRsnLGDeQXRY7HX8+EEk40D9iSD
HRwp048NCfMjY2TacByEAh/gC1eQGNYUkAMyAL+9v6kffpO1+AM2EIE0wAMWo5axiHhpiwBeo0Eh
+AsSD+SNx3lLW3mgANq/jFtlVwuQKm0tkEZkgmeQs3EN3B13xUPh1RNWG9wJdx6LYymMPZXoR/Ql
BhL9iabjOjhQdRasIsD/T9u3SMIzQifhCeEWoYtwD4TAVh7ss0ShYLxnceCpNMvo91n8ItEPylkg
DHTBOP/R3qXA6L4xH9wIqrbHvXE3qB9qx5m4BrDA7WBPvHAP2Dd7aP1eoXhcxbex/PF5En3f93HU
Tjej24+qSBnX7zPu9WMWn+/GiAvvIT96Ysuxw9gF7DR2CWvFmgALO4k1Y1ex4xIenwlPpTNh7GlR
Um2ZMA9/zMeqzqrP6vN/PJ09qkAk/b1BPm9OvmRB+OQI54r4aen5LC/4RuaxggQcy0ksGytrewAk
73fZ6+MtU/reRpiXv9lyTwHgXAqNad9sbH0Ajj0DgDH0zab/Bi6vNQAc7+CIRQUyGy65EOC/hgJc
GepAG+gDE9gnG+AAXIEn8APBIALEgEQwE456OsiGqmeD+WAJKAFlYA3YCCrBdrAL1IAD4BBoAq3g
NDgProAOcAs8gHOjF7wEA2AIDCMIQkJoCANRR3QQQ8QcsUGcEHfEDwlFopBEJBlJQwSIGJmPLEXK
kHVIJbITqUV+RY4hp5FLSCdyD+lG+pA3yCcUQ6moCqqFGqGTUSfUCw1BY9AZaBqaixaixegqtAKt
Rvejjehp9Ap6C+1CX6KDGMDkMSami1lgTpgPFoElYamYCFuIlWLlWDVWj7XA3/oG1oX1Yx9xIs7A
WbgFnJ+BeCzOwXPxhfhKvBKvwRvxs/gNvBsfwL8SaARNgjnBhRBESCCkEWYTSgjlhD2Eo4RzcEX1
EoaIRCKTaEx0hGszkZhBnEdcSdxKbCCeInYSe4iDJBJJnWROciNFkNikfFIJaTNpP+kk6Tqpl/SB
LE/WIduQ/clJZAG5iFxO3kc+Qb5Ofk4ellOUM5RzkYuQ48rNlVstt1uuRe6aXK/cMEWJYkxxo8RQ
MihLKBWUeso5ykPKW3l5eT15Z/mp8nz5xfIV8gflL8p3y3+kKlPNqD7U6VQxdRV1L/UU9R71LY1G
M6J50pJo+bRVtFraGdpj2gc6g25JD6Jz6YvoVfRG+nX6KwU5BUMFL4WZCoUK5QqHFa4p9CvKKRop
+iiyFRcqVikeU7yjOKjEULJWilDKVlqptE/pktILZZKykbKfMle5WHmX8hnlHgbG0Gf4MDiMpYzd
jHOMXhWiirFKkEqGSpnKAZV2lQFVZVU71TjVOapVqsdVu5gY04gZxMxirmYeYt5mfpqgNcFrAm/C
ign1E65PeK82Uc1TjadWqtagdkvtkzpL3U89U32tepP6Iw1cw0xjqsZsjW0a5zT6J6pMdJ3ImVg6
8dDE+5qopplmlOY8zV2aVzUHtbS1ArSEWpu1zmj1azO1PbUztDdon9Du02HouOvwdTbonNT5k6XK
8mJlsSpYZ1kDupq6gbpi3Z267brDesZ6sXpFeg16j/Qp+k76qfob9Nv0Bwx0DMIM5hvUGdw3lDN0
Mkw33GR4wfC9kbFRvNEyoyajF8ZqxkHGhcZ1xg9NaCYeJrkm1SY3TYmmTqaZpltNO8xQM3uzdLMq
s2vmqLmDOd98q3nnJMIk50mCSdWT7lhQLbwsCizqLLotmZahlkWWTZavJhtMTpq8dvKFyV+t7K2y
rHZbPbBWtg62LrJusX5jY2bDsamyuWlLs/W3XWTbbPvaztyOZ7fN7q49wz7Mfpl9m/0XB0cHkUO9
Q5+jgWOy4xbHO04qTpFOK50uOhOcvZ0XObc6f3RxcMl3OeTyt6uFa6brPtcXU4yn8KbsntLjpufG
dtvp1uXOck923+He5aHrwfao9njiqe/J9dzj+dzL1CvDa7/XK28rb5H3Ue/3Pi4+C3xO+WK+Ab6l
vu1+yn6xfpV+j/31/NP86/wHAuwD5gWcCiQEhgSuDbwTpBXECaoNGgh2DF4QfDaEGhIdUhnyJNQs
VBTaEoaGBYetD3sYbhguCG+KABFBEesjHkUaR+ZG/jaVODVyatXUZ1HWUfOjLkQzomdF74seivGO
WR3zINYkVhzbFqcQNz2uNu59vG/8uviuhMkJCxKuJGok8hObk0hJcUl7kgan+U3bOK13uv30kum3
ZxjPmDPj0kyNmVkzj89SmMWedTiZkByfvC/5MzuCXc0eTAlK2ZIywPHhbOK85HpyN3D7eG68dbzn
qW6p61JfpLmlrU/rS/dIL0/v5/vwK/mvMwIztme8z4zI3Js5khWf1ZBNzk7OPiZQFmQKzuZo58zJ
6RSaC0uEXbkuuRtzB0Qhoj15SN6MvOZ8FbjVuSo2Ef8k7i5wL6gq+DA7bvbhOUpzBHOuzjWbu2Lu
80L/wl/m4fM489rm685fMr97gdeCnQuRhSkL2xbpLype1Ls4YHHNEsqSzCW/F1kVrSt6tzR+aUux
VvHi4p6fAn6qK6GXiEruLHNdtn05vpy/vH2F7YrNK76Wcksvl1mVlZd9XslZefln658rfh5Zlbqq
fbXD6m1riGsEa26v9Vhbs05pXeG6nvVh6xs3sDaUbni3cdbGS+V25ds3UTaJN3VVhFY0bzbYvGbz
58r0yltV3lUNWzS3rNjyfit36/Vtntvqt2ttL9v+aQd/x92dATsbq42qy3cRdxXserY7bveFX5x+
qd2jsadsz5e9gr1dNVE1Z2sda2v3ae5bXYfWiev69k/f33HA90BzvUX9zgZmQ9lBcFB88M9fk3+9
fSjkUNthp8P1RwyPbDnKOFraiDTObRxoSm/qak5s7jwWfKytxbXl6G+Wv+1t1W2tOq56fPUJyoni
EyMnC08OnhKe6j+ddrqnbVbbgzMJZ26enXq2/VzIuYvn/c+fueB14eRFt4utl1wuHbvsdLnpisOV
xqv2V4/+bv/70XaH9sZrjteaO5w7WjqndJ647nH99A3fG+dvBt28civ8Vuft2Nt370y/03WXe/fF
vax7r+8X3B9+sPgh4WHpI8VH5Y81H1f/YfpHQ5dD1/Fu3+6rT6KfPOjh9Lx8mvf0c2/xM9qz8uc6
z2tf2Lxo7fPv6/hz2p+9L4Uvh/tL/lL6a8srk1dH/vb8++pAwkDva9HrkTcr36q/3fvO7l3bYOTg
46HsoeH3pR/UP9R8dPp44VP8p+fDsz+TPld8Mf3S8jXk68OR7JERIVvElm4FMFjR1FQA3uwFgJYI
9w7wHEehy85f0oLIzoxSAv/EsjOatDgAsNcTgNjFAITCPco2WA0hU+Fdsv2O8QSore14HS15qbY2
slxUeIohfBgZeasFAKkFgC+ikZHhrSMjX3ZDsfcAOJUrO/dJChHu8XfQJXSpfeVi8EP5F4RkbAmB
xhnfAAAACXBIWXMAABYlAAAWJQFJUiTwAAABn2lUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6
eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAi
PgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRm
LXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAg
ICAgICB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyI+CiAgICAgICAg
IDxleGlmOlBpeGVsWERpbWVuc2lvbj4xNTY0PC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAg
ICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjExNjg8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAg
ICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4K5QBsOwAAQABJ
REFUeAHs3Ql8VPW9///3LAlhCYKIIApIcaEqIugtuNQFq2IVLW5Vu6jYH9XrUu/ttVb7s9fl2tZr
6cVaf1r+14ValaKtdatYFcXiggpUcUGEsogoUIwalpDM8v9+z8zJnDOZTGaSSTLL6/A4mbN+l+eZ
GZLzOd/vNxA3k5gQQAABBBBAAAEEEEAAAQQQQAABBBBoRSAWi8neQmpoaFC0cbu2r1mqwOfrNeDl
/1Fo26dSIKho7WB9fOJ0xXcaogEDBigUCqmqqkqBQMCZW0mazQgggAACZSQQLKO6UBUEEEAAAQQQ
QAABBBBAAAEEEEAAga4QsM+v8gxrV0iTBwIIIFBSAuGSKi2FRQABBBBAAAEEEEAAAQQQQAABBBDo
XgETaAiETKsFM7tBh3gwJDvb1gzmR/eWj9wRQAABBLpNgBYO3UZPxggggAACCCCAAAIIIIAAAggg
gECJCnhaOMRlAhDJf3aZCQEEEECgcgUIOFTutafmCCCAAAIIIIAAAggggAACCCCAQE4CdvwG76xY
VM7snB1wwgyJUAOtG3IC5SAEEECgTAUIOJTphaVaCCCAAAIIIIAAAggggAACCCCAQKcJeFo42BCD
DTbYmXBDp4mTMAIIIFASAgQcSuIyUUgEEEAAAQQQQAABBBBAAAEEEECgiAQ8AQenVIGQiTaYmQkB
BBBAoKIFCDhU9OWn8ggggAACCCCAAAIIIIAAAggggECeAjbYYJsyOE0bEh0puS0c8kyJwxFAAAEE
ykwgXGb1oToIIIAAAggggAACCCCAAAIIIIAAAp0sEIjFZGc72WBDMBhU3M7OFn4ggAACCFSqAC0c
KvXKU28EEEAAAQQQQAABBBBAAAEEEECgPQIBz0gN7rJ9dZfbkybnIIAAAgiUhQAtHMriMlIJBBBA
AAEEEEAAAQQQQAABBBBAoPMF4qY7pXg8pngsItk52aYhFovLzgECD51/EcgBAQQQKGIBWjgU8cWh
aAgggAACCCCAAAIIIIAAAggggEDxCZjWDM2DRgecIIM7hoMTcCi+AlMiBBBAAIEuEiDg0EXQZIMA
AggggAACCCCAAAIIIIAAAgiUhYAJNjQ3ZLCBBzsFQok5scZPBBBAAIEKFSDgUKEXnmojgAACCCCA
AAIIIIAAAggggAAC7RZobuGQaOzgpuPGH9x1XhFAAAEEKkuAgENlXW9qiwACCCCAAAIIIIAAAggg
gAACCHRcwIzjYAZySKRjx4sOhZxZnvGkO54JKSCAAAIIlJoAAYdSu2KUFwEEEEAAAQQQQAABBBBA
AAEEEOhuAU8LBztutB27wRm/IdnDUncXj/wRQAABBLpHINw92ZIrAggggAACCCCAAAIIIIAAAggg
gECpCcSTgYa4bOuGmNOgwQYaGmNxRc0cDAYVtwM8MCGAAAIIVKQALRwq8rJTaQQQQAABBBBAAAEE
EEAAAQQQQKB9AnHTpMGGFOxsl22jBreFAw0c2mfKWQgggEC5CBBwKJcrST0QQAABBBBAAAEEEEAA
AQQQQACBrhCwXSjFTOsGMzvRBpNnIBB05q7InjwQQAABBIpXgIBD8V4bSoYAAggggAACCCCAAAII
IIAAAggUn4Bp2uC2cHAWTAltywa3dYMzlkOy1N7l4qsIJUIAAQQQKLQAAYdCi5IeAggggAACCCCA
AAIIIIAAAgggUOYCsXhUdk5N9hZT4jaTM85Dcod3OXUsSwgggAAC5SrAoNHlemWpFwIIIIAAAggg
gAACCCCAAAIIINAJAs7YDcnBo+2yM9mBopODRXtbNXiX3UN5RQABBBAoXwECDuV7bakZAggggAAC
CCCAAAIIIIAAAgggUHAB22ohlIwv2OWgCTS4XSoFg6aVQzLwUPCMSRABBBBAoOgF6FKp6C8RBUQA
AQQQQAABBBBAAAEEEEAAAQS6X8DbPVLMDBjtrttgQyD5zx3HoftLSwkQQAABBLpDgIBDd6iTJwII
IIAAAggggAACCCCAAAIIIFBCAm5wwS2yvaEUsN0qJad40LRyMDMTAggggEBlC9ClUmVff2qPAAII
IIAAAggggAACCCCAAAII5CVgx2WIB8OJuUcfRc16rKqn4nZ2WjrklRwHI4AAAgiUkQABhzK6mFQF
AQQQQAABBBBAAAEEEEAAAQQQ6CwBt5VDPBDSjt6DTMChRpuHHi1Fdijeayeppq8CJuhgx3GwQQkG
jO6sK0G6CCCAQPEKEHAo3mtDyRBAAAEEEEAAAQQQQAABBBBAAIGiEXADCHETTAhW91I0GlFT74FS
tEmBmt4KmNYOgVCYQEPRXDEKggACCHS9AAGHrjcnRwQQQAABBBBAAAEEEEAAAQQQQKCkBNxgQzhs
byXVqKHvYMV6DtC26v6KmwGkw1XVCpl9vU0gIhQKNbdyKKlKUlgEEEAAgQ4LEHDoMCEJIIAAAggg
gAACCCCAAAIIIIAAApUhYAMPTpdJ4WozWkNQQdONktPVkulGyUQanKCD3c+EAAIIIFCZAgQcKvO6
U2sEEEAAAQQQQAABBBBAAAEEEEAgZwE3iBCNRp1zevWyXSpFlWjxICcIYY+pqalxlm0rBxuccFtG
5JwRByKAAAIIlLQAAYeSvnwUHgEEEEAAAQQQQAABBBBAAAEEEOg6AbeFgxuAqKqqclo4uAEGu93d
13WlIicEEEAAgWIRCJhmb/FiKQzlQAABBBBAAAEEEEAAAQQQQAABBBAoXoGYGa/BTpFIxAk02NtK
7q0lG4xwAw/21U60cHAY+IEAAghUjAAtHCrmUlNRBBBAAAEEEEAAAQQQQAABBBBAoDACNpBgZxuA
8AYVaN1QGF9SQQABBEpVgBYOpXrlKDcCCCCAAAIIIIAAAggggAACCCDQTQJuq4bWsvcGIVo7hu0I
IIAAAuUnECy/KlEjBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ6GoBulTqanHyQwABBBBAAAEE
EEAAAQQQQAABBEpcgBYMJX4BKT4CCCDQSQK0cOgkWJJFAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ
QKCSBGjhUElXm7oigAACCCCAAAIIIIAAAggggAACHRBwx24ww0U7qcSj0URqwVDiNZB4tpUWEB1A
5lQEEECghAUIOJTwxaPoCCCAAAIIIIAAAggggAACCCCAQJcLxGOKN26RYhFpu3mNxxWv7iEFwwr0
7G9ek8GHLi8YGSKAAAIIdLcAAYfuvgLkjwACCCCAAAIIIIAAAggggAACCBS5gNuyIRYzLRt2bFHg
/XnS5x8r+M4TUqRRGjRK2mk3RQ/7P1LvnRUKJYIOtHQo8gtL8RBAAIECCxBwKDAoySGAAAIIIIAA
AggggAACCCCAAALlKuAEHmKmG6WGetO64XPps48Uj+yQeu0ihXooZlo9BEyLByYEEEAAgcoUIOBQ
mdedWiOAAAIIIIAAAggggAACCJS5QN3HcX26TQr3Cmj33cxrkdS3WMtVJDxFWwy3hUPUjNkQj5ig
gm3VYOZgMrhgOlcyPSvFZfcH7BwIOLPb0qFoK0bBEChhAb5PS/jilXHREyP5lHEFqRoCCCCAAAII
IIAAAggggAAClSZQ/3ZUQ4+MasykqPY/MqL/t6Q4BIq1XMWhU/ylcIMOUkDOYNG2eyWzLE+Dhlg0
Zlo5JAaULv4aUUIESleA79PSvXblXvJiecCh3J2pHwIIIIAAAggggAACCCBQdgLrV8b11ptxLV8d
1+cNUk2NNHBIQMO+FNDo/QIa2KfsqkyFEKg4ATfIYIMIdrmxsVGxHQ0KNe5QwMxVZgBpE3JQ1HSz
FItG1NTUpICZbcuGYDDozBaNsRxK863TUBfXu6uzl71XX2nAzuY734wXzoQAAggQcOA9gAACCCCA
AAIIIIAAAgggkJfA32ZHdd21cS3MeFbqUefxkwK67oqQvjoy44FsRACBEhRwAhDmYx6zgQYn2GDD
DYlGDvbTn9if+h5wdvKjZAVmnhzVNRtzLP6u0rTTg/rmSQGN3zfxvsjxTA5DAIEyEqBLpTK6mFQF
AQQQQAABBBBAAAEEEOhUAfOk678fHtGJrQYb/LkvnBvXiZMi+vfZpXnzsWFTXHOfiOmPf4pp7ktx
mUYcTAhUrIANJLitHOxrrKnRjOXQlAgwGBUTe3DmiBnfwc72eCf4ULFiZVDxLXE9n2uwwVbXHDvz
jpiONUGKgy6LatmWrjXgO7trvckNgdYEaOHQmgzbEUAAAQQQQAABBBBAAAEEUgKbYppyWEzPpLak
lsxTrVPGBdR7W1yvviitSO1xlmZeG9O0M0IaVWJ/gb47J6ozZqQq89ySsMbTTVQKhKWKFHACCXbQ
BtvFkh2rwT+EgzOcA8+2l8lbw3xnt/jKM9/3e3mqt6KVgMQKE3A+ZG5ED88Na1IXtXLjO9tzYVhE
oBsFSuzXvW6UImsEEEAAAQQQQAABBBBAoFIFInH9JEOwYfw5Qc24OKjRu/lhNq2M6cHfxnTNI+72
xBgPLe9cufuL87Wqh79cVf5V1hCoSAG3pUPYhBbM0NFOKwYbYIgFAs5My4YyflvsE9CHT4bkG6oh
ItWZ1mBLXonpnulxPZIWgDjDtHJ7+EUTdEj7f6IzlPjO7gxV0kQgfwG6VMrfjDMQQAABBBBAAAEE
EEAAgYoSWHpvVLem1XjazSE9d0PLYIM9bODIoC7/77BWzQnqOOe8gAa3eEw2LcESWG0qgTJSRAS6
QsAGGNzAgtuawQ4KzcDQXaHfjXmY7/EWTy6bDf13C2jiaSHd91JYj13RsnxnfC+qupabO30L39md
TkwGCGQUaPE9kfEoNiKAAAIIIIAAAggggAACCFSmQENc/32zv+rHXRHUr05zbzP693nXBo4N6pH3
gqozgx/4noj1HuRdNk/K1tdL5sWZetZKNQX6qzViylC/Pb9001s0VHWwLG4Zwibh2lwCMJ3okSTu
8ItbJ5tQIa9XesHMkADabq6hGTJASvp18HI4WRSy/N60bBn753KN0ytaAutuoCEei5oulaJOiW2g
IWoW7SpBhxK4iO0tYg5jMky8JKxXaqM69EbP2D3L47rvNenyr7SdcUc+64X4zu5I/m3XLvsR3u8Q
vk9T/2eX8/dp9ndE6e4txP/PpVt7So4AAggggAACCCCAAAIIIJBVYM2zMTX3jOQcGdAvv59HY3nz
V2fWG6/mRvLCuVH94b64Zi5uWZS9zNgQU6cEdMY3ghpS03K/uyWyNqYLzolpfT+zZXBAd/82pOEm
72XPxzTjlzH9frl7ZOJ1yjkB/eiykEYP9G9f/1JUl/w6rj6mn/Klc/37pp4X0QRzE3lrcvOWXgHN
+J9EPu6RLcpxl9lvBl799dVRXeNNb9eAXnwipHHpkZgCebjl6ehrg3H9P67rl4KafVtQlmzNazHN
NN1m3WrG7PBO448M6Mp/C2rSAW0HpLznZVq2XXM9afqBf/QvcT2Tdv3s8cdNMu+NqUFNHtt6Xi2u
RzvfF5nK52wzAbm5c2K6/w+mK5n0Mpr30LRzg848Kv06t5pgae6wt5bdFg7OcmlWg1IXSGD0d0Oa
OT+iaZ7vh2vM98UFXwnKxJFbTB35rHf0O9sWpiP5t6hMlg18n2bBsbv4Pm0DqHR2B0xk2hNyLJ2C
U1IEEEAAAQQQQAABBBBAAIHOF7j3wogu9dw0Ou6qkB75Xus3ePMpUf37MX335FYGos6Q0KxHwjr9
gAw7zKb6JVHtdpb75625mf9iUK//36h+6Cl7pjNnPWHS3De1Z/HtER3pGSg6tSfzUvpA0unleG5u
QPdMMgGPDKdPN/X5vqc+BfV423hMcT2kn80J6/KxGQrRxiZ/faQXXw5p2S1RTfNHoVqk8u1rQ7rz
uy3fJ/W5lKsurhsviurmDAGoFhmZDceZcUQe+vdgy65ezD5/+dv/vsiUb92SmM44K6aFmXambfvZ
vSFdfnhLj7TDinLVvW0UMY9+x8wg0Vu3blVsa51Cb9yv4Bcfq3bN30z/SlFtHzxWsb67aduE7ynY
ZxfV1tYqGAyqqirx3DktH4ry8mYvlLkB/J3R0VTQ2Yzh8LEZwyFT0CA9oQbz/b6L+X73Ts+9FtZ4
b/CtAJ/1Dn1nFyB/b/3aWvZ/H/F96vWqlO9Tb53LeTlYzpWjbggggAACCCCAAAIIIIAAAh0QMDeb
nku7YT/1+MLcNK1/O6bd8gg22FqcNyWie99upT6+vjTiOvLItoMNTponR7TUdNVTsCmtHMe2Emyw
+dV6ji24R6Eq5CmjTfLIw9oONtjjfn9jVDc+nwp42G25TksfyD3YYNN85o6Yfv5SK3n5yl+490Wd
CXANzRRs2McEQMycPl1zflS/fq2VMqYfXALrNghhvwns7AQkTNVs7Zwalk81S+BKFG8Ra/YN6Gdp
n4WFq/3lLehn3Z90Tmtdnr/v+4jvU/ciVfr3qetQTq8EHMrpalIXBBBAAAEEEEAAAQQQQKCAApGN
cS31pme6AZowzLuhncsmkPGvU/xPvtqUfnN7SKvME7CfvRfWx+ZJ+sduDGivtCwunRLVmrRtba1O
M2NOvPliWB+aNB+8omXA5B7TZY87HXiuGQz73qBeNANeT5/kbk28/ux2s/3+oJ5z5zkhjcmjn/4p
FwT1sElj+gWJeg3eOZl+F3v4a9X+tW+blgWvPBfSh6+F9MrMgManJXXztJiWmS6i8p28A73aLrVm
mdYBq5aEteUDM5v3xqq5QV01zp/qzb+O5T0obT7vC19u5npd3tyaJrFn/BTzHnvZlO/JsB4x8z/N
e+1nae+fa74Vy/u968u3iFYSnyL7GY45QQf7Ix4KOXNiQxEVlqJ0k0BAx0zxZ/38otR3rd1TiM96
R76zC5G/v4btX+P7NGVXad+nqZqXz5Lp0ZIJAQQQQAABBBBAAAEEEEAAgZYC2zfHtcK7eQ8ziLN3
vZ3Ly+Z4uuhw0gjojaUhjfIkXjswoIlnh/Tqv8Q0wbQSSJXDjPXw17huyrGlhb/LpIAmX2JujqcN
aDrT9L9/vRkE23YTEu5vbpwnu77pZfKWZ9yFY44MarSnjPlU39elzvHS969Jnd2VHqlcO7aU3r1V
/2NMoObFmI490tvFUFyPL4xrVJ5dCQ0+KKApR0pnmbEgJqePBWHuYgwcGdS19wf00Zejqa6qFse1
3AxoOz7HAFC+7wuv1rI/+8c1GW8CSU9f4+/Sqca8fy+/LazdL4vovOb3UFxzzMC5V+YwcK43v6Jc
thEH20O3nc1yIB5obuEQIOJQlJesKAq1w1+KQnzWO/KdXYj8/TVq3xrfpym3ivw+TVW/bJZo4VA2
l5KKIIAAAggggAACCCCAAAIFFkjr/kHmhm47HlhPK1Rc993o3zRrrj/Y4N1bY24uP3pz4nlqd/ut
d8VV765keX34Of/4DO6ho81Avt92V+yrGdQ5U72aGr0HmadxMx3kPyTj2rdvzNZ/f9d5ZCxcOzbO
mtvKWBq7BXX7tf4Er380s63/KP/akMNDus8Mtt0i2OA9LBzQBVd4N0jpb1f/3tRax94XJuB1rfcp
bTNweCvjR9gcTzeBCG8rnfvNIOylPtkulJwulcx4DgEz28mKBMyinc3o0c4A0nY7U2UL7HGg/7u7
T9rgD4X+rOf7nV3o/Ntztfk+rezv0/a8Z0rhHAIOpXCVKCMCCCCAAAIIIIAAAgggUAwC+wfUs4Pl
aHg7rlu9aYwL6viR3g0tl4eb1gzHeTcvjukDE/zINl01M6RJw1o5wtysnuDtkmd54un4Vo7u2GbT
KuKWs/033bwJdpWHN8+OLP/AdHt1epbrNeo4/w12vRPX9o5kmOXcXmk3L7Mc2ryro++LyFoTcGhO
zbSouDiQvdWLCcJc7HmvrTBjTdR5zi/tRXuj0HOz0AQabLCBCQFXIJxrFNA9oZXX9nzWW0mqXZs7
K3++T/k+bdcbsgROokulErhIFBEBBBBAAAEEEEAAAQQQKAqB5M3jdvYqlKyC5wal2fLtKYmujLLW
r09Qk/aJ6ZnlWY/y7dy1X/YbnwceaQ5fnDqlQPfFUgkml352adDpqqnFjuYNXePRnF0HF4aZroKy
TrsFdPqu0s0bk0eZa7bRtAyp7ejdB5NGvRncu2F7witsIl8frchakow7O/q+sN2MeafNn0lL34+r
aZt3a2q5qiqutd7gmOnyqaMUqdS7d8lKeDXigaDszISAK/DR++5S4nVLLk3TCvRZ9+ecx1oX5s/3
qfcbRKrk79M83qElcWi5/D9XEtgUEgEEEEAAAQQQQAABBBAoaYEC3CzdsNovMDa9j37/7ua1vQ83
i56Aw1bvaJ/NR6UW0roKT+1ILlX1aLGpWzZ0lUehKteWq3nEXUP3MLm5AQdzS/qfJlAwMsexFbzl
jNTF9dTjMT35ZFy/9wSHvMfku9xW+dt8X6RFplY8GNOhD+ZbijI43o7d4E7eZXcbrwgYgSbTXV0u
U2d81nPJ1z2mu/Jv6/uI71P3CvFaagIEHErtilFeBBBAAAEEEEAAAQQQQKCLBKqq7NPsnhtG68xT
5mZLO3qyaS7x5k886ZmtO9oIHLgn9k5rVtFkbmKXw1SOHtWmhUNqCmiXtGuX2tf60sLfRXXsjf73
SutHd92e1a92sEzmM2QeoC6LKRCPmsGio6m6BELm/qiZk1OAsRxciop93faFv+qHHeRft2vd/Vnv
7vxbivi38H3q9/CtldH3qa9eZbBCwKEMLiJVQAABBBBAAAEEEEAAAQQ6Q6BmeGLshGfcxDfG9cJK
6dwsffi7h+b6mmtDg8a0BHt3JOqRllYxrZaDR6Ove6H8WzgsbSXYcNyRAe1n3nv9bADDQL08I67m
92YXXcTBX/YH4cafE9AVXwmoMf0Nmqk85pg9Dguqf6Z9pb7Njt1gYzF2ZhyHUr+ahSl/JK577vAn
NfpL/i7Zuvuz3t35+3Uyr/F9mtlF5fx92kqVS2kzAYdSulqUFQEEEEAAAQQQQAABBBDoSgFzY/eY
feQbO+GuR2M699/b30/7iAP9N2zXbnLuULZZq3cXtnlISR5Qfh5xfbjMcyn2CWiffLpT+jim76S1
bJh2bVDXnmtu1KfdwVhWG9EzN3ry6oLFmp38mYw5KKjJJ/tvovqPKL+1uOlCyc6KmdYNdk5OcRtz
qCwKt+q8ZhDY9LeYfu/dvmtAB+7m2dDdn/Xuzt9D0foi36et27CnmAXa/1tiMdeKsiGAAAIIIIAA
AggggAACCBRAIKBjvulPZuEdMS32DoLr393mWjitD/xbn4233cVMQ1wLfH34B7RTO7rpabNw3XBA
uXlE1sZTA0a3w7PeDMq8wnPelCuC+tV3WwYb7CFNubQq8KRVkMW0LsDeXGYDZpU3OWHDZODBiTG4
LRvclg6VR0KNfQJxzZjm/2xM+X5QQzzHdPdnvbvz91C0usj3aas07ChyAQIORX6BKB4CCCCAAAII
IIAAAggg0J0Co08Maq+0Ahx5dcwZyyFtc8bVTe/H9MDsmOqSe3sOCPjTeySmt9oIYKx/MaZHvKlP
MmmkPe3u3d1Zy2n3mguSTal5XHNpVCuzDELw1l9jPpe9Dg7kNebHR4v9NymPOKq4blvU7h3QeE8N
F94T17IsHp5Dy2rRtnAIBgPO7LR2MLWLB4LOzNgNZXWp21GZuO69LKpb0878t9P8zV+64rOe7Tu7
K/JPI2ixyvcp36ct3hRlsqG4/ucuE1SqgQACCCCAAAIIIIAAAgiUjcBA84T5OWm1mRvTVy+LaX22
gZtNq4THfxXRiJNjmnZtTMuTQYXwsKCuGOdPb+oNMbWa1KaYLrnEfxN6unlStiviDU07/OV88V3/
eiHWSsnDqa8Zx2PMUVEtyxQkMl2UTL3Zr3LFt/K7Vj0H+29Krl3vv/Zu6g0rY7oiLS93X6e+9gnq
Xyd5c4jr6l/7gyzevd7lhlbf5N6jSmQ50cTBRBnM9THL9iq5gYbMV6xE6kUxswv0CSitkZrv+Lq1
Mf3kpKgunevbrG/fGNK4tK7VOuOzns93dmfk7691Dmt8n/J9msPbpBQPIeBQileNMiOAAAIIIIAA
AggggAACXSgw8UchTUnLb4UJOuwzOqKf3B7Twrfj2mTGYtj0cVxLl8R078+i6jM6qnOaBwwNqJcn
QnDqD/03lVeYVg4TzBOxSz/2ZGKeGl/2UkzHHhbzDwxsxgQ46wDPcZ24OHg/fzmv/7eoFiebamxa
aQIqT5iWGwV4ur1UPJqpzU2yQ8ZG9MBr8eZA0Rpz3accGfN1hyTTZ/tJ+zafldPCzt4+V8wZt14S
1VwzULl3WvrXqHaZZN533o1duHz89/3vi2dMN2PH/jSmlZtaFqLefC7+9kRU3zkpol3M56Uj3ZG1
TL1rtzSP3eBmGzWBFjsnJzfg4K7zWoYCpgXS6++bVj3mO39pcl5ovqcf+N+oLvpmREOPjenW5f56
7zUlqFvO9n9m7BGd8VnP5zu7M/L31zzHNb5PfVCV8n3qq3QZrnh+5SvD2lElBBBAAAEEEEAAAQQQ
QACBjguYp1rveS6o9eZmUvpN3ltnmBtMM9rOosrz12f/r4Q0a1JE53megl0xN65D55q797tK4/tJ
C9NuWrk5PHZvSP3dlU5+HXKA7f7JM6aAuTF05Ff8EYYXjzbjC6Q9uZtvsUrFI71e074V1bT0jZ71
6b8JaaBnPZfF2r2CJs2oZnoOPsO8V44z3WiNMxf+hQfjLd6DnkO7ZLH2gJAePieiMx5MZbfwwZjG
mNm+f6eMMzdXt5kbssukFRtTx9ilbF28+I8s/jU7XIOd7WSDDbZlg9vSwdnIj9IXMF93/sZMcZ14
cmqg8LYqaMdg+f8uCSrTkDud8VnP5zu7M/JvyyPbfr5PUzqV+H2aqn15LNHCoTyuI7VAAAEEEEAA
AQQQQAABBDpVwHb989xrIf1gnzyzMTdfn3s5pFGegINN4fTbQpqZ3mzC7jA3aDMHGwJ66sWwJuZ7
B9ummcOU8Uaw6U7qF+ndSeWQVnsOKTaP1uow5YKAjmttp2f7VbeH9P2xng25LtYEdO2clrcqnjEB
qZvTgg3HHelPNOM19B+S91praU66IawHL8iQnHn/PmLK+siLLYMN9mhvS58MZ5fMJhtniMWizpyM
OZjxG8LOXDKVoKBtC5hIwaC2j2p5hPnef/iJkO5rJdjgnNAZn/V8vrM7I/+WElm38H2a4Kn079Os
b5IS3dnyf/ESrQjFRgABBBBAAAEEEEAAAQQQ6GSB/gHd9GRYb94f1FW+fuxb5vvtcwJ67JGQtvwh
pPEZgwQBnfvfJq17g/p22pgOvtTME+P/eWNQH74X0ld38+3xrVRVubc9E5v7Zuto3BxSVe093d/l
k3ePcyPkYn/azfuPDGhoWuuGfMvRnJbpCL87PVLlyL50xOkhPbIkpJ+1cv33MiaPPRHWtcdnNsvF
p//YoD42LWp+0Nr7wnSrNdO0dHnkrpCvhUWmS55Lft4a5/q+sOdMvias5SY48oO0wIc3Pbu8lwnS
/edVQb35WlijMz3qnX5CCazb7pXsFbZz86DRdrkEyk4R8xAIB/SNC9o+frx5j9vv/Jn/Y97nJjBs
v/cn7Zv5O8CbWiE/6266+Xxnd0b+bjlyeeX7NKVUyd+nKYXyWQqY/xj4/6B8ric1QQABBBBAAAEE
EEAAAQS6TsB0t1Fn+qj/dJvpKsYs226TevYNaFcTYEhr0NBmmRpMvx0bNsT1xfbkoebu8QAzBsCQ
fPpPMmWoNwPzVpmbujU5FCBijt1uzulpggZtHm6OXf+RKZ853h48YOeABrZWtjzLkQmnOzwylaP+
7ah2m5K6bfCzOWFdnmy50FAX10fmif5t5vqrlzTYXK9WTbyJ5+HTsMXk8ZHJI9nUoO+ggIZ7A1gm
LWcw5mzXPI/8bDHzel8k62XP2Wi63Nr8RaqivfqaHpaMSW2JBxnc20ZNTU2mRUNM9fX1itVvUq9X
fqvgFx+r54a3pGBY9SOOUazvboqO+6aCvfurd+/eCgbNoOHhxKfLdrvEhEBrAgX5rHsTz+c725xX
8Py9ZUku832aASXDpnL+Ps1Q3bLc1ObvVGVZayqFAAIIIIAAAggggAACCCDQcQHzF2X/3QIFGVOh
xtz0H27GiujQZMpTm9biIFt6YXMjuDbbAd595tghI00AxLutteU8y5Epme7wyFSObNtqTIuXka0F
XbKdmIdPjXlPjMw28LRJy1plnfLIz6aT1/simbE9Z8iwHN8fWQtbQjvt86vJZ1htSModNDoVniqh
ulDUbhcoyGfdW4t8vrPNeQXP31uWHJb5Pk0hVeT3aar6ZbFk/ttlQgABBBBAAAEEEEAAAQQQQAAB
BBBAIDcBGxqMx2PO7IQJTeuFqIk0xMxMS4bcDDkKAQQQKFcBAg7lemWpFwIIIIAAAggggAACCCCA
AAIIINAJAnYEh7h5DDlm5miVaWISMgNGh3uY5iFmZkIAAQQQqGgBAg4VffmpPAIIIIAAAggggAAC
CCCAAAIIIJC7gB2XIV7dU9sHj1a87zBt67enGcMhpOiAvRXotZN6mEFU7DFMCCCAAAKVKUDAoTKv
O7VGAAEEEEAAAQQQQAABBBBAoG2B5GDNbR/IEZUkEDddKMVq+ikeCCsajZp+lIIK9txJqjatHcw+
ulWqpHcDdc1ZgO/TnKk4sLQFCDiU9vWj9AgggAACCCCAAAIIIIAAAgh0mkBV34DGK66FyRx279tp
WZFwkQu4rRbCYXMrqUdvbdtlX0UjEUX6bXeCDDW9+ihcVaWA6VbJBhzs8QQeivyiUrwuFeD7tEu5
yawbBQJxM3Vj/mSNAAIIIIAAAggggAACCCCAAAIIIFCkAu5tI9uSIRaLqaGhQRETaKivr3daNzQ1
NTmBherqatlgRG1trUKhkHr0SAQe7LKdCD4U6QWmWAgggECBBWjhUGBQkkMAAQQQQAABBBBAAAEE
EEAAAQTKRcANFLgtFqpMKwYbRLCBCBuAsMEHO9nt9hgbeLCv7vHu+eXiQT0QQAABBLILEHDI7sNe
BBBAAAEEEEAAAQQQQAABBBBAAIGkgA0k2Mm2ZnBbP9iggl13gwx2P4EGq8CEAAIIVJ4AXSpV3jWn
xggggAACCCCAAAIIIIAAAggggEBeAm5wwXat5LZusK92doML9tW2dLCTd1teGXEwAggggEBJC9DC
oaQvH4VHAAEEEEAAAQQQQAABBBBAAAEEuk7ABhLs7AYa7Kud3JYPXVcSckIAAQQQKEYBWjgU41Wh
TAgggAACCCCAAAIIIIAAAggggEARC7iBhvQiui0b0rezjgACCCBQGQKJjvcqo67UEgEEEEAAAQQQ
QAABBBBAAAEEEEAAAQQQQAABBDpJgC6VOgmWZBFAAAEEEEAAAQQQQAABBBBAAIFyFaAlQ7leWeqF
AAIIdEyAgEPH/DgbAQQQQAABBBBAAAEEEEAAAQQQqDyB5NgNzRU34zowIYAAAgggQMCB9wACCCCA
AAIIIIAAAggggAACCCCAQE4CztgNNtgQbZQZOTpxjh1IOmRuMdnBpJXovZsWEDlxchACCCBQdgIE
HMruklIhBBBAAAEEEEAAAQQQQAABBBBAoBMF4lFpy2YTdGgyQQezHAxJPftKoSqpurfJmNYOnahP
0ggggEBRCxBwKOrLQ+EQQAABBBBAAAEEEEAAAQQQQACB7hdwWjaYYkSjiWBD6PnbpM8/VuCztYpX
91J07FnSTrsp/qVDFTDrwSAtHbr/qlECBBBAoOsFCDh0vTk5IoAAAggggAACCCCAAAIIIIAAAiUp
4AQeYlHFt/xTqt+owOfrTauGXorv2CI1bjMtHmIlWS8KjQACCCBQGAECDoVxJBUEEEAAAQQQQAAB
BBBAAAEEEECgbAVisZgZsiGuSCSieFOTgrGIAqY7peaWD2a/7DFmfyAUUVWV6V7JTIzlULZvCSqG
AAIIZBRItG/LuIuNCCCAAAIIIIAAAggggAACCCCAAAIIpARs4MHOzoDR7qDRZuxou83pbik5jrQb
iEidyRICCCCAQCUI0MKhEq4ydUQAAQQQQAABBBBAAAEEEEAAAQTaIeAGDtxAQ2Njo+k6qVGhyA4F
o43qYdK0MYamqGn5YOaQbeFg5lDIDCTNhAACCCBQcQIEHCruklNhBBBAAAEEEEAAAQQQQAABBBBA
oH0CNvAQNwNHB8zpdrYBiZht6WCjDmaOmH0h2wKCCQEEEECgIgUIOFTkZafSCCCAAAIIIIAAAggg
gAACCCCAQO4CbpdJTsDBBhRMa4aAGTzanaJRG4iImXEd4k4Qwm0Z4e7nFQEEEECgMgQYw6EyrjO1
RAABBBBAAAEEEEAAAQQQQAABBDosYAMJ9l/zGA62mYOZbAMHp6WDs2Z32y1MCCCAAAKVJkDAodKu
OPVFAAEEEEAAAQQQQAABBBBAAAEE2ingBBxiphsl05rBzk6kwaRlO1GiI6V2onIaAgggUEYCBBzK
6GJSFQQQQAABBBBAAAEEEEAAAQQQQKDzBbytF5LLAdPUwc5MCCCAAAIVLUDAoaIvP5VHAAEEEEAA
AQQQQAABBBBAAAEEchdwWjiY7pKC5o6SnZ3JBhpiyZmgQ+6YHIkAAgiUoYD7X0MZVo0qIYAAAggg
gAACCCCAAAIIIIAAAgh0hoAbeGhOmxYOzRQsIIAAApUsQMChkq8+dUcAAQQQQAABBBBAAAEEEEAA
AQTaIRCIx2Rnd4qbgIOdmRBAAAEEKluAgENlX39qjwACCCCAAAIIIIAAAggggAACCOQvYLpVkp3t
ZF9MsCFg+1hqHtKB4INjww8EEECgwgQIOFTYBae6CCCAAAIIIIAAAggggAACCCCAQEcEbCghnvzX
HFYIBM2W5jUn+QAtHjrCzLkIIIBASQoQcCjJy0ahEUAAAQQQQAABBBBAAAEEEEAAge4RsOM32NCC
E3iwrRxsYMG+2C3JIAPBhu65NuSKAAIIdLcAAYfuvgLkjwACCCCAAAIIIIAAAggggAACCJSIgDtY
dNCM32Dn5ikYkuzMhAACCCBQ0QIEHCr68lN5BBBAAAEEEEAAAQQQQAABBBBAILuADTK4k7NsGzKY
DXZO/HD38ooAAgggUOkCBBwq/R1A/RFAAAEEEEAAAQQQQAABBBBAAIEsAt7ukeyyDTTEYlFndoIO
9lw7YLSdmRBAAAEEKlqA/wkq+vJTeQQQQAABBBBAAAEEEEAAAQQQQCC7QIsWDs7httWD2/LBDuBg
Qg/O+A3utuxpshcBBBBAoDwFCDiU53WlVggggAACCCCAAAIIIIAAAggggECnCdgbSs03lQJmyQ7n
YGe7zIQAAgggULEC/C9QsZeeiiOAAAIIIIAAAggggAACCCCAAAL5C7Rs8UALh/wVOQMBBBAoT4Fw
eVaLWiGAAAIIIIAAAggggAACCCCAAAIIFFrACTbYQaTjpjmDnd0pGDJNHkKmVyUzxoPTtZK7g1cE
EEAAgUoSoIVDJV1t6ooAAggggAACCCCAAAIIIIAAAgh0UKB5oGiTjrNsh21wx3BgCIcO6nI6Aggg
UNoCBBxK+/pRegQQQAABBBBAAAEEEEAAAQQQQKDLBeJmwAY728mJMQTNLSYzE2/o8ktBhggggEBR
CRBwKKrLQWEQQAABBBBAAAEEEEAAAQQQQACBIhewrRmcbpVMeCHZhVJq1dv+ocjrQfEQQAABBAou
QMCh4KQkiAACCCCAAAIIIIAAAggggAACCJSxgIkuBJOzE3iwVQ2YW0x2ZkIAAQQQqGgB/ieo6MtP
5RFAAAEEEEAAAQQQQAABBBBAAIH8BGy3SbYdg53dLpTsq7tsFpkQQAABBCpUgIBDhV54qo0AAggg
gAACCCCAAAIIIIAAAgjkKxBP9p0Ui0VlZ7cDpWAwbIZwCJselgLOnG+6HI8AAgggUB4CBBzK4zpS
CwQQQAABBBBAAAEEEEAAAQQQQKDLBNwWDk6GdkwHd/Iuu9t4RQABBBCoGIFwxdSUiiKAAAIIIIAA
AggggAACCCCAAAIIFEQgEIiZlgyx5n6Uoqblg9P6oSCpkwgCCCCAQKkKEHAo1StHuRFAAAEEEEAA
AQQQQAABBBBAAIEiETAdKZmSeFo6FEm5KAYCCCCAQNcKEHDoWm9yQwABBBBAAAEEEEAAAQQQQAAB
BEpfIGaGiLZzcgpUVUl2ZkIAAQQQqGgBAg4VffmpPAIIIIAAAggggAACCCCAAAIIIJBdwA4E7U52
2YYZYtV9JDPbbpRiVeY1GJLsXEatHOo++KNunP+stpla7b7X+br66PHiRpr7TuC1/AQiqtu8Xp/u
aFK4x87afUB/3u/depEbtGDuLfr9uvWmFDvrG1//sSYNqe3WEuWaOd+TuUpxHAIIIIAAAggggAAC
CCCAAAIIIFCBAt6xGZyAQ48+2jziOKnhCxN5iJjAQ29Fe+2qoAk8BENhBYNBM76D6WTJE6goPbY6
3ffQNN3dmCz51vG6koBD6V1GSpyzQP2quzVi1tXNx9/wrdW6fO/SuMHdXOiyWmjSO2/P0OwtiUrN
fmC4Vv3HNPUvgToScCiBi0QREUAAAQQQQAABBBBAAAEEEEAAge4S8AYObDAhFgwr0muA4qEaJ+AQ
qO4phc1yyHSpVNJBhpRw/aqH9FM32GA2zzjldJka5jZFG7Tmo3f11j/e0LJNa/Txtu2J86p6are+
wzVqjzE6cM/9NLwfN3NzA+2co5a9eqMmzJ2RTPwozb74AU0alPNV7pxCFVWqJpjY0Slap2UfLNGS
1Yv09qcfa3uT1LPXbhrW/0s6aORB2m/YSNXahlFMGQRqddqkH+uqh3+R2Lflas1ZdY6+P6L4vzcI
OGS4nGxCAAEEEEAAAQQQQAABBBBAAAEEEEgJ2KCDDTaEw2HFa/po6+4HKxqJKBqNmlYNIdX2HWha
OFQpFDazWS/tFg4N+utzqSe91ec6nZTLTb7oej3+1C/10zdmaVWKruXSG4lNI/qfpxtOuVqTRwxs
eQxbOlmgTvMXuMEGm9V8PbB0tQk4jOrkfCsl+YgWL/gfXfjsL1r/LCywFsN1yRG/1o+/doSK/zZ6
11+7gQecpqkm4HB3MuurXnxBF46YXPRdXRFw6Pr3CjkigAACCCCAAAIIIIAAAggggAACJSlggw4h
E3Sw3SgpFJV9ONnpQsl2pWRmtzWE+1qSldw8X/+1LlXysw/5utoKCdSvf1rnzTxX81Kntbm0qm6W
vjNrlk455FHdffIRRX8Tsc0KdfMBDZ8t0wvL3tFW82B+73776+gDRmVplWLew2ljnPfiLmmBrmCD
Hn/gMH1n+Zoc0luj2xecqn57rNCVo1p2FpTfNc0huzwP6e78pZH69iFH6e435idKvuoeLaqfrPFF
Hp3ho5TnG43DEUAAAQQQQAABBBBAAAEEEEAAgUoRcAMHttWCDSz06NHDaeVg6x+LxZxBo+326upq
p2WD27qhlH0Wv/5bz1PZY3XWQSOzVqd+7YMaevelGY85eNBZOnrwl8yN7wZ9vHmJ7l6XvHHoOfqx
N07VCdsf0tNnTiTo4HHJd/HdBZfq7DeWJE8bq6dHPqvxprevzFOVhvQze+pSe0fuMiC1wlK7Bda/
cWOGYMNYTd3/VB3Yv4c2bVymuctnaZEnh7krVmUMOOR3TT0JFmixu/O31dhv3JmSG3AwLXH+8M5a
jZ8wrEA17JxkCDh0jiupIoAAAggggAACCCCAAAIIIIAAAmUnYIMLdnK6VorHnYCDDUrYdaelg1l2
gxSlWfn1enKxJyjQ51SNtTemW5vqF+i8DMGGqRMe0H8cdayG9PTfevtVtF5LlzyoK5642nfDddE7
Z+o/916qmw4a0lpObG9DoCps7dyAQ9/0BgxpZ9do8nmrtWjVB/rctIjo1Xeo9hrUVjuWtCRYbSkQ
XalfPnGnb/vB+9yrh8+d7Bvs+Er9TCuXPalb/jRNs81YKUfvOdR3jruS3zV1zyrca3fnb2tSM+Rw
XWJeb09W6+6F83T9hPOLuguqxP8SyQLzggACCCCAAAIIIIAAAggggAACCCCAQLqADSbY1gtVZpwG
25qhd+/evtm2fLDbbeDBbeVQioGHyIZXNN0zWPTEA4723Sj1u0Q09/HLW3SjNONbK/SrSSe0CDY4
54ZqNfqQaXruikd1ij8x3f7nu7Q+bRur7Rcw4xO3MdVq5IhxGrf3OI0ywQZ/aKiNU9mdWaDxc632
7qm+QvelBRsSu2s0ctTpuvOaj7TovBd00T65BXvavqbezAu/3D35D9Ox+49NVabuMb1Zn1otxiUC
DsV4VSgTAggggAACCCCAAAIIIIAAAgggUIQCNojgtmSwr97lUgwwpBOvee9Z36ZT9t3Tt+5bqX9R
t6T1U//Dk5fo/L1b9kXvO8+u9DtCM6f+Jm3zDD38gaePn7S9ra1GGutVV1/nzA3R1o7Kbbs3rbrt
DbmdlOUoN736HNOKRBtUvz1Rl7rt9TKND3Ke0oZkUJUdYKQzJlvGpHddfb0aovmUMnuBXK9EutmP
zba3I47Z0m1rX/0nb/gCcBPHfUPZ2+yYwMOI0RpYnTnlQl3T9noULH/PZ7Q9n6vRXz7BAzRfT60s
7tAkwTvP5WIRAQQQQAABBBBAAAEEEEAAAQQQQKClgBtMsAEGO7mv6Ue6x6VvL431Br323hxPUc/S
wbu3PjrrskUP+bpFUv/puuKQ3PtWrxl2jmaPuEVnr0oNrvvT+fP0r3uf7nvavmHD05p219X6yN6U
7Xe5Zn/vfGcQ6zXLHtfM52/V7RvcboQSRT940BW6ctJFmjQit6fG1bhec1+8Xw/8/UE9tiVVFie1
atP3/oEXa9pRp2pUbebbiBFTvqlu+Xqfo7svvlLDty/Tr++/VD9d5ylb9Xmad9mvNC6NdNP6haYb
q8f02LKnNC89fw3XxD2m6IKjLtTkvVveul7/9kxd+twC9TFjmC9d96Tn2s3XhXd8V+ON2TbP1tYW
t1T9i/7ngss0vLUgRbROC19/SH9YOEd313nqlExwRP+zdMGYM3XGYRM1pJWb5/bQFlbTjFUoomV/
/71mPPtrzU6r/yn7/FxXfn2qRvfLbO+tT0ccvel0aDkt9jJv3XITNBrtez+3lX4+1zTbdWuvR6Hy
7+jnyus0cPihOthscMe9+Mu7S3W96X6t7XeFN5WuWy7WcnWdADkhgEBJCpiuQrUjEpV5MSOVmZ+B
kqwGhUaguAXsByxo+uA1Lz3CIdMXb3EXl9IhgAACCCCAAAIIINAhgehqzd/gSaHPWO3Z6s3jes1/
0xuckH541PF596t++GEXSKuuS2W67lm913i6RnvybfpijR5rXCPZrp62zNOHn03Us49O1cWrWt74
tgkt2jBDZ88y8xHP6M6vjUulnWGp7oMHdYYJDLg3Mlsc0mgGun5jmjPfcMZSXX5Ay5v+233l+4c+
MQGEn8/8umanJ9Y4S6//83oTcEhGHOqX6sa7j9b0uvQDvetrNG/dDM27f4YmjnlIc6b4B9b+ZPVc
zaub7xv82T17Vd2TnsG/3a2tvW7RJ40m4JBhkOn6tY+bcTrO9z25n57Kqro5+ukLdh6ru857SKeP
yNzKJd1q82crNXfOV3SV933nSfyx5VfrseV36q6p83X6sLRIjXtcARzdpDr6WrvHGE00icxzE1p3
kx5ae7zOaa3s7nGe1/yuaYbr1kGPDudv6lKIz5WHRKr9kiaZ74RF9jvATKtWv2XGOz/BCTwmthTX
TwIOxXU9KA0CCOQgEDfRhh1NUb2z7gs1mNdIJJYIPORwLocggEDuAja+EAoFVGPaIh8wdCf1MK+l
/cRa7nXnSAQQQAABBBBAAIHMAmX9+2D9en3gqfbBI8e0HkBoXK2XfDfKT9JJ+7a8Ge9JLuNi7fDj
dLau89yc36Bt6d0i+e7ePamJM7xP8mdM1tk4e8Fx2n2Xpbq2lYGo6z6YqRH3X90yARNomahPW7Q2
+OnDo81o4ct0+ai0lhO+8s3RCTP9gRhvBn1DqU5qls7/zzaCDd4zzU3sN8/Uz/depmsP8Ob/hf+g
DqylSpZKpH7VvRo664epDW0uLdGFs/ZSvRmQ+vwRGQIEaVYTb2vdKpXVGl149yXa55rf+QJR7v7C
OLqpdfA1tJN29SWxRhffPUX61u90ToYWKr5Dm1fyuaYtj+24R8s0m4vWYqHlsQX7XPny2ll72BiW
G5hqfEUfbpcGZgiQ+U7rphXf27ybykC2CCCAQN4CtlHD9saIE3Cw0QaevM6bkBMQaFPAtiRqjMZl
g3z2M8eEAAIIIIAAAggggECzQDyWXLSPqZipDP4oq9v0ju9J/91reyXqluFnpG65lnq39z9Ce7fn
5l/17ppgbiTO9gUvvAlnXz57zExdctih2qNXldatfERX/PlqXx2m//lGnTn6Do1K7yqocal+kBZs
OHjEdM089WyN7FfjZNrw2TLNfPhc0y2SaV2RnH46e4ZOve4m09FRbtMp+0/XuSMGaM2qv+jOd7Zq
UN/UrUjvALwj+l+k/3vs2Tpy5N7mJqrJ34yTsGnDm7rzoa/7ghLTn3tElx4wrXkg7wOP+q2e3vOf
quohvT7/Yl3VXNbhuuHkO3REH8mbj1tqO77Dgme/rp+6N3DdHd5XY3RJi2DDUZpx8v81waX91L9X
WNtNkOr1v/9BP3zhF77WFFfM+oWOycPJZjv1kHt1yaFHaOfQp1qw4Jf6zhveYMSTuue1lfrVESO9
JXSWvfVrr2OLRNu7oXqUrvzaeZr97CxPCkt08f2j9b8jfq5bJp2jcYMyBGI8R+d+TU3NQ7tpTNrn
rqMeHcq/0z5XNTpgxEkm4OAGG+frrU/qNS5TUMtj2V2LqU95d5WAfBFAAIEcBexNTztFo1E1NUW0
ZXuTorGYvjykVjXVQXpVytGRwxDIVaChMaZ319ebz1zctCSKKhZODBBozy/rJ9tyBeI4BBBAAAEE
EECgEgVMoCFu/g4LRMyAwvbBFPMEWMCO6xA2N+dN0KGUf09ct/J13xU9fOSevnXvyvYvNvtuMKtp
R14DHHvT2uFd0XwtXFen8W0OPN2y657+B03Tc0OH69jbzvUEHebo8fdu0ChfqwBp2cv/T4958j14
/wf09Jkn+PqEr+k3Spd/72Xt/r+H6cLmG/l3as6y/9CVo+zj1tknXxdMh0zW98/0Hz94z0k65cMv
68xJl2jyiLTWIaEaDRwyXtde+pI+uvHwVAuQurlavn2axidvModrR2r8AYmb8L3WHCA1l/MAHXPg
+IwtAtxS9Fpzkgk4uDdw3a2p12Uv3uIzki7Sq9fcpFGe7q5q+w3TxKOv1Cv7jNKhM8/3vCfu1Mw3
LtFNh6TVK5W8Z8lcy6mPeLpM6q/JJljyNxN3+eqCVNDh7kV/0/Um4JB+u74Qjp7CdHhx5BHXasbS
WboiLZizaNXVmnjH1Tp4jx/r+q9/T0cMyfwe6sg1tYXvqEdH8u/Mz1XffkN91+aLSNqAGb693btC
wKF7/ckdAQTaIWADD/ZfzDxybeceVUHTv3wi4GB/ubX7S/mX3HaQcAoCBRFwPztucM/G+OxnzHyq
Ev/sBiYEEEAAAQQQQACBihaIR81NrmiT4p9/4rwGzJhfst3k7LR74jWQ/ih96XLtyHZDL+2O2sHD
929+6j6/GldpSD/TXqAu1Yqgb4+0xFskOFx3TXtCpw9JtETw7R5wgm4/4iRNWJC6kX7Tolf1bwdM
9gQTVmqmGW8gNZ2lGaf6gw2pfTU6fcr1+q/bUjfTH1i6xAQcbE/9rU9nH/1SxvEevGcMMS0Vfmdi
BFmn0ChdcMhRmv3G/ObDMnV9ZHea5xI90xaZHpizTv7j0w9dq/s8hnbvXdOu9wUbvGfUDJmsP5sn
+8d4nuy//aW/6seHnN8iQOA9Txqr2RfP1aRBLQO7Z+gAAEAASURBVK/56GN+oLNNwGG2e0JTfcag
VqEd3eza/9pf51+8QrUPnKkLl7ccZ2TRul/o5Jm/0AgTeLhz8kUan6XFg/8atX1NbZkL6ZFf/p37
uRo0aG/fJXlh5Spd3mZg0ndKl62YEDQTAgggUBoCTqDB3PCMmadp7ByNmSeuzaxYkwJ2jpvfLjyv
dpkZA94Dub8H0j9DcfMZsp+xxGct8blzP4el8a1BKRFAAAEEEEAAAQQKJeD8HRYxvx9u/VSxDcsV
eORKBe7/ngL3fU/6448U27xGsR1bFTU36e2xpT8N1+590/pqyVKpnWoHZtmbbVeNdu27c7YDWuy7
5ORWgg3JI0eNPVMjvGdt+limu/fmKbLh77q7eU06eMz5WVsCaMDRusjzMPqqNe+YAWuzTIN+o1uO
HpXlgPx29aox/SJ18dSwap5u9+bZf7qOH9IyKOA9ZPjB33QGTG7eVjdPH3jhm3ekFn74jQczBhuc
I0KJ7raaj97yvGnd0byW90LXOvbX6ec+q3fPu1dTW7l8q0zg4YQ79tRPFvg6J8u7Xu09odAenf25
anJGjffU1hdg82wvgsXsn5QiKCBFQAABBLwC7pPXdpu7bJ6nUTDZXygtG7xaLCPQPgH72bKfJfvZ
ssvePxjdfe1LmbMQQAABBBBAAAEESlnA+RssZls4NDotHAL1yT5T7O+MJhhh+uJUsLXHz0uu4gdo
RP8MLQhaqce8dW+rQaOV+xluQvX6+1r/U+Bf7Mh+J3HYTumd6rhpJV8HjNFpptuf6Y3J9S1rtNE8
q1ebbHxiu4PyTp9u/4eWru1leoUy1zDDVBXeprXeXWbAhGw3FG/42sltPNWfIRN3k2lBU99Yr4ak
QdiMzfDRxrfdvV346uIlsjx7zIS269RzP51gbq7P2+IWs3nB3dDiddfe2d4xtTpw5FFSDq07WiRc
JI5DRkzWr/5jgy5Z9qhuf2Ka7s5AcvuzR2tz5CXdWcAgVXd4dPbnqkWdinhDtu+HIi42RUMAgUoU
sL/cujc/nRugtncXMzs3Rj0Bh1CofJrwVuJ1ps7dK2DHSHGnRADPhh0CTtDBfu6Ctn9eJgQQQAAB
BBBAAIGKEXCCDKa29vfEuGm9EGkwIw6Yuaf5+8ydbAecUaerpYgZ38EEHcwO92Ew99U9tnhfG7R8
XaobIsncGU39atyy2Okxgc/qnVYE2W4ft0wkscXcU/dNPcLZb9e1PVpEfw3tbZJsvmf+nv5plke6
DTbSkl+1/FJ9dbmvCB1cScfJnlykfqWeWvgnPfnO02bwbH/wJfuZnbd3w4Y1vsTHDt/dt555paf2
Hj5WeidVh21tULR1LavCrTQPyFCAYnRMFDOskaNO16/MfLVpOTLjj2fq9rTAw+wXztVJX35NkzN0
LZWhqjlt6nKPTv9c+au9Z7+d/BuKaC2NoohKRlEQQACBHAXcgIP3NcdTOQwBBNIE3ICCG3gonT8Q
0yrCKgIIIIAAAggggEBBBZwHwExgIWYfULGzfS7FnUzsIWq7UbIPqKTiEO7eEnmt0T57nGQGHfYG
HVoveu0eY5zuc+a1fkiOe+q1aav30KN00OA2WjB4D8+4XKUeNuBQ5+78snbxDHS8+v0F7o72vW5t
6zZ5rslGtPDZH+mEBbNyPaHLjtv82Xu+vLKO59F8ZFi9fXdav1Bjo404+DY2H124heJ1TK/jwBET
dZNp8XDKs5eZ6+4dR2SNZry8SJOnjE8/pR3r3ePR1Z+r1Z993g6brjmls9/xXVMLckEAgYoV8N4M
raqqam7t4N1esThUHIE8BdxWRG5LInu6+3ek+2RbnklyOAIIIIAAAggggECJC7i/B9pX+1BKLGJa
OJjZtn5125bbfY2Nps8dMweqI8720m95Pl+vf1KvcSNau/mf1nfUljla8tk0TeyX3wWPbHhFNzW3
RDDnVo/VULclQn5JeY5ukr93JH8Lh8F7jDbHpgIrB+/zc13xpQFy7o17Usm4aO6f7/Hl49s5QLY/
xaUtbjon9k8cdJa+vMuX1M/etTTMr7zxC3U8sOPPO9+17J1IpVLz9jwl9VXvXp1/67WUHBNSYY3/
2h16umGrTngj9T5ctPJNEyMb3+H3Vnd5FMvnKvVu7L6lzn/Xd1/dyBkBBCpEwAYX3KeybZW9yxVC
QDURKIiA/Sy5LRvs58j7WSKIVxBiEkEAAQQQQAABBEpSwA062IdRIqZbpYAJPLgPprgVitkucG0r
h+Rkzyn13yGzPtVevZP2dCvrvC7RE8vWauKEYb6tba28t+RR3yEj9vyKdvVtac9KvT5sbt1gzu9z
jPbxBDFqevu7YhkzbJIm51nu9pTKd87mp/Vd3xPu0tQjHtW1xxyh/m4kK3nCspqlmrAgdWPal04n
rYzY8xjp1fnNqa/9vN4stxZ8cg+r1ztp43G4ezrttcgds9V7/KFmcHMTcFjlHtRvgDxvU3drfq/d
6NHZn6u0EKf6hNO35EfVmUcTcOhMXdJGAIHOFUj+huveGLVP0NhfaEv/SZrOZSN1BNoSsH8cMl5D
W0rsRwABBBBAAAEEKkvAPpgSNcGGqBkcOmBmNwjhKjRFYmaMh1TAwd1eyq87so3hEBqpb084Snd7
bkrfvcDcMJ9wWe5PaEeX6vZX/TfSL/iXr+TQAU/223mRDYtSA0Y7FyBtlIi0cQXe/HitOSq/QElH
r2v9F2tSN5pNYqcc8hf96muZu9NpSitvR/PO5fxwyG92+zuLdP0hQ7Jfm8bVeskb6DEhqZ08XVnl
km++xxS7Y9b69NpdI8wBzQGHzza3exwUN59u9Uh7nxb6c7V65RK3ms7rISP39K0X0wojPxbT1aAs
CCCAAAIIIIAAAggggAACCCCAQDELmIdTTLTBV0LvmtPSIW2/7+AiXtlz5L/4SvfKiuZbob7t7sqB
Yy9wFxOvW67T1c8u9W9rda1Bf7znPM327b9Ip+7d37cl08pPH/qFVmYJhry15B7faSOGDPc9m2/H
nzjYc8Sid+7XsizpeQ4t2OJHKxf40jp8/zG+9UKs+Ls3yi/Fnn13c26GN5+16h69tb15LePC+rdm
6zHvnj0O115prTW8uwux3BWOeZUz2qD6HN9Lm95/0tdV1oiB/vdppnzbuqad7ZEt/87+XG1r2OAj
6euPifn2dfcKAYfuvgLkjwACHRawrRqYMeA90DnvgQ5/QEkAAQQQQAABBBBAoCwEbIsGpyVsNGIG
jk57lNfUMBYIOnMpV7bnznv6bjKv+mKTWtY0VcPwoKN1x6DUul2aveBo/WRBW0GHOv3xgZN14bo1
vpOnTvq+hvu2tLLSeKcOvvlGLct0A9x0KXOhp9WFTeEHRxzmfzK/5xj96x7etOfomsf8AQDvXu9y
Q04DPXjPyLzcs99Q3461mz/1rbsrDesf1xVprUDcfemvTZEtnk3z9eIaX3MDz762F+21/YEv9jNf
F875oxpaO/WzBbr0iTt9e28+9ni/u29vYVY6w7H9JavXvb/ZXUNvHKdbFixWfbaE6hfr2j/P8B0x
YlDLFiT5XtNCe+SVf6d+rur11sr5Hq+jdODAtrr48hzexYsEHLoYnOwQQAABBBBAAAEEEEAAAQQQ
QACBUhSwAQfzvJczp3ep5D4AVIr1csscrt3TDFmbmlatX24Gsc021erM0+71BSns0bc/e7T63frv
evDvi7XmszrZm/QNjfXatHmZ5r5wi067bi9duNzfPYoGTdf1+Yyj0DhDE24+TQ8uW5m8CR7Rmg/+
qNNuOzfVRY0tTPWPddKw9BuTNTr+2J/bvc3TvDdP1bEPPKiVn7W8pV7/2VoteHWmvvvLARr8s7O0
OFOgozml3BZ2HuAPrdz+xI81d733FnWDlr5xmwbPPF+LcktSg/cY6zvypj/9Uovrbcgook3rF+vx
VxeoLsen7+14Daee8GNfeqtWTdOh/3ublm72vCui9Vr29r06dsapvqf11efnOqvVAcd9yXZopTMc
O1IgM6S8mdbopmeP09DrTtONzz6upRvWq958BiImUFlfv14LX71Nx04/Lq11z1m6fuLoFlnne00L
7ZFf/p35udqoDzxvO1UfWoDB5VtwF2xD9k7fCpYNCSGAAAIIIIAAAggggAACCCCAAAIIlLKAiTUk
BoY2g0PbZe8UNcM3xEt9CIfqPTVhkGml4PZcsuVRvV9/mbI9SBweNFl/Pfvn2nv21V4OqW6WLv7z
LP+21tb6X6d3Lz7f1+1Ra4f6t8/XxbO/oov9G31rN5/5PQ30bUms1I6Yqtn73Kmzl69p3rto+aU6
2MyqHqtTdt1batqgpXXztaqx+RBnIVu3Mv4jW1+r3f1ITTW7724+5EmdPfNJTdzjIo3ttV0vLJ+V
c6DBTWLInoeb4M+MVMDFtASZON3b6mCsnh7zrMbnODJx/1EX6a49fmFaorg5mPEG1l2nr952nWN0
sBmfYdGWtMCRc+hR+tP3puY+lkcq+byXOsMx70J4T/C9OeZr+gI7ew/IvPyTM27Q6AzjXbR9TY/S
vDFmoPHkNS20R975d9bnavMK/cVDN2L3A7vk/eXJMq9FWjjkxcXBCCCAAAIIIIAAAggggAACCCCA
QIUKOBGHeGIMB0/EwbZucCfvsrutdF5rNWHvkzzFXaJX1mzyrGdeHDhqmj6ceq9Oybw769ZTxjyg
VT+4TEOyHuXfecr+V2iif1PGtR+e/Jq+3+qYEGFNOne+7tv/qJbnNi7RY+vm6LENLYMNUh/1KsS4
BNWjdO23prfIe966OzU9LdgwcZC/5YLvnrY3hX5H6uf7+FtOeHdLff2r8nbBZOIraXttK4fTv7dM
d4zIkKYxyhxsOEtPXDZHE/t1zjPeLcrYGY4tHHLdUKvTTva3nGn7zOG64RtLdOUBmcJi5uw2r2la
DoX2yDd/04lWZ3yu1qx6MRVIM1X++v6jO727rjTZvFYJOOTFxcEIIIAAAggggAACCCCAAAIIIIBA
BQvETJ80dnYnM3aD7JycSr1rpb32O9GtivP6wHttjceQOLx22GT97roVmnfydE1Nu0HuS9CumBYE
lxzyG/3tstX63ZQT8n5S+fDxV+pPV72gG9K6EHLzGTHoIv1p6gpde8hId1Mrr7WafOaf9O637tUl
bZR5RJ+T9JMJ92rRD2e2eBK9KuTvsqlvOLeb7f33Pl8fXvyoLumf4Ya+LXGfs3THGUv1p4t/67SG
SFSij6paqY2cm73P6b4xZ2U+YtAkfcnTuqFXnz09x7WW7kCdc95iLTrjNzq7tXLaVKqP0k+Ofkir
rr1DRwxovf75WlX5khqUMdhTKMd8y+bBa160wbfPrjLX7Ogf65Q+zZszLIzV1ENmatFVi3X5QcMy
7Hc32Rv42a/pUM81tWcVyiNRgvzzt4GqQnyuXAHbJdhb7zyVWtVYHbtXPiFKz6ldtBgwfe7Fuygv
skEAAQQ6JBCNRp1BypqamrR1R0QvL9/spHfYPgPUu0dYVVVVpi/RgEKhQjxu0aGicjICJSvQ4nP2
fuJzdvioXZzPWdj88cDnrGQvLwVHAAEEEEAAAQTyFoiZ7pPsraOGhgZFG7dr++q3FPh8vQa8MkOh
bWagXxNsiNYO1scnTld8pyEaMGCA8zeZ+/dZ6bV4WKufXDdWtzdLXaQ3r7spt8Gcm88xtwjNmA0b
6zZq87bP1WSHEQhXmZvFvTSg/66miyb/DXrPaRkX61fN1NBZqS6bbvjWCl2ebLnQUL9JH9Vt1rYd
5tn3Hr00uP/uJv2ajOm0tTFV5m3JQ02Ze/XVrqbMtdW+O98tk4o2mH76m1RV3VM1oTaObXm2Grab
emz6RNucWFaV+pp6DO/ncTL9/zeY95+qa036GRJI39RYp/X//FRfRIxL2LjX9s/oHmls0HaTZ1V1
TU7pNmyv04a6DfrCetspeU2H5HNN87Ryy9izZ02bT7V32DHPsiUQWv9py7PBvD99Xn131a7m2ub9
LsnxmnpL02EPb2LtyN+e3qHPlU0gukwX3Xh4aswLMz7Iqv+Ylneg0ibVVVPe17arCkY+CCCAAAII
IIAAAggggAACCCCAAAJFJGAHjQ4FnNlEIZyCxYMh2dkJLHi6ViqiUudZlGE6/ZCjdPsb85Pn3amX
11+r4UPyu4kfNjfGhwwyc56553t4Te1AjTRzIaYOlTlUo1pzQ7y9U01PU49hWephghg1PT0BiLYy
qu6vIUPM3MZxYRNoyCNVU4b+Gm7mDk15WuVTxg475lm2thxseYabuSBTjtfUm1eHPbyJtSN/e3qH
Plfm/Pp/vJgKNpj1syccW9TBBlvnVJs3u8aEAAIIIIAAAggggAACCCCAAAIIIIBAawI20OAGG2QC
EMl/cbNcLtOBh15gBh9OTQ8tfjO1whICCCDQhQKvv+4d+PwoXTCmra7SurBwrWRFwKEVGDYjgAAC
CCCAAAIIIIAAAggggAAClS5gu1Pyzs74Dc1jOAScMEMi1JAaOLrUzcIDjtOPBqVqMe+NP2ilZ9iK
1B6WEEAAgU4UaFyqe5evac5gxD7f1/h8muQ0n9m1CwQcutab3BBAAAEEEEAAAQQQQAABBBBAAIHS
FfC0cLAhBhtssHP5hBvspanRyV+7zi4kp1l64L1N7gqvCCCAQJcIrHztHj3myelHRx/lWSveRQIO
xXttKBkCCCCAAAIIIIAAAggggAACCCBQXAKegIMtWNwMGm3ncptq9/62buiTqtX0xx5RfWq1a5fs
oNNMCCBQYQJ1evLFWak6D/qNpuQ5lkzq5K5dYtDorvUmNwQQQAABBBBAAAEEEEAAAQQQQKA0BWyw
wTZlcJo22HYNqRYOzkpZ/eivaRc8o76vv6Edpl67DD5SPbupflW9d9PBJu9FTv5jtXvv7ipJNwGQ
LQIVKVCrY47/jW74pF49wrU67PAzTdur0pgIOJTGdaKUCCCAAAIIIIAAAggggAACCCCAQLcLBGIx
2dlONuQQCoYkMyfCD87msvlRM2Cczp80rtvrUzNksp67bnO3l4MCIIBAVwqENfqQczS6K7MsUF7l
1+atQDAkgwACCCCAAAIIIIAAAggggAACCCDgEQh4Rmpwl+2ru+w5lEUEEEAAgcoUoIVDZV53ao0A
AggggAACCCCAAAIIIIAAAgjkLBA33SnF4zHFo02SnZNtGmKxuOwcIPCQsyUHIoAAAuUsQAuHcr66
1A0BBBBAAAEEEEAAAQQQQAABBBAolIC33ySzbIMMdpOdnYBDofIhHQQQQACBkhUg4FCyl46CI4AA
AggggAACCCCAAAIIIIAAAl0r0KIhQ8CM4WBnJgQQQAABBIwAAQfeBggggAACCCCAAAIIIIAAAggg
gAACuQmYrpVM30rOscmXFsu5JcRRCCCAAALlKEDAoRyvKnVCAAEEEEAAAQQQQAABBBBAAAEEOkPA
jOMgO9vJjhcdCjmzXWZCAAEEEECAgAPvAQQQQAABBBBAAAEEEEAAAQQQQACB3AQ8LRzs4A127AZn
/IZEo4fc0uAoBBBAAIGyFQiXbc2oGAIIIIAAAggggAACCCCAAAIIIIBAQQTiyUBDXLZ1Q8xp0GAD
DY2xuKJmDgaDitsBHpgQQAABBCpagBYOFX35qTwCCCCAAAIIIIAAAggggAACCCCQm0DcNGmwIQU7
22XbqMFt4UADh9wMOQoBBBAodwECDuV+hakfAggggAACCCCAAAIIIIAAAgggUAgB24VSzLRuMLMT
bTBpBgJBZy5E8qSBAAIIIFD6AgQcSv8aUgMEEEAAAQQQQAABBBBAAAEEEECg8wVM0wa3hYOzYHK0
LRvc1g3OWA7JUniXO79g5IAAAgggUCwCBByK5UpQDgQQQAABBBBAAAEEEEAAAQQQQKDIBWLxqOyc
muytJdvKwYYiUpMz5kNqlSUEEEAAgQoRYNDoCrnQVBMBBBBAAAEEEEAAAQQQQAABBBDosECoSnEz
R6v6KB4PKFLVSzEzy+laKRV0SA9AdDhfEkAAAQQQKAkBAg4lcZkoJAIIIIAAAggggAACCCCAAAII
INB9AjaAEDCBhkjtEMVCvbR55IlSZIdUbYINNX2d12CQjjS67wqRMwIIIFAcAgQciuM6UAoEEECg
TARi2r51u2KmSXVVz56q7rK/N7or3zK5bFQDAQQQQAABBBBAAIEcBOJ24IaqGqlHHzX2HCBFmxSu
6Z0MNoRbdKuUQ5IcggACCCBQZgIEHMrsglIdBBBAoPsEInr38f/SnEVuCSbo8p9O0s6dHnTornzd
evKKAAIIIIAAAggggED5CrhdI4VCIcWrqqU+AxXr0U/bA6ZLpVhMoaoqhcJh9anuKXuMnWnpUL7v
B2qGAAIItCVAwKEtIfYjgAACCOQoENO2rd5DP9O2iLSz+ZvEO9Wve0N/+t8ntMrZOEgnnneuxo/Y
yXtInsu55ZtnohyOAAIIIIAAAggggAACHgEbeLCBBNutUtD+q7FjOMQVNAGGgNlugw4EGjxgLCKA
AAIVKkDAoUIvPNVGAAEECiVg/8iwUzxuOlIyy8lVu0UB88STHUjOO322+u1ksMFu3aD3PvpCX9mz
b97Nr3PN130iy1sGlhFAAAEEEEAAAQQQQCA3AWfsBhNssC0X7HKvXr0UjUaddZuCDTLYuafpUtW+
usfxe3huvhyFAAIIlJsAAYdyu6LUBwEEEOhmATcQYP4WyTg1NGzzbe9RoP+J2srXl2kHVyJb/6nV
6zaqMWq6q+2zq/YctosKVI0OlozTEUAAAQQQQAABBBDoHAEbQHCDCzaHKtOVkv0d3A0wePd1TglI
FQEEEECgFAS4P1IKV4kyIoAAAkUs4N7oj0QiikRsi4ZEYWMxs97UpFiV/7+a2n6mz9fYJ801igfD
Zt20jjBPQ9kp1yehcs0333SbC9bKgs1349In9Pu5q5NH7KkLrz5PQ3u0EmFpJR02I4AAAggggAAC
CCBQCgLu7+c2sGAnu25/J66urnZe7bqd7e/d9tU9rhTqRhkRQAABBAov4L8LVPj0SREBBBBAoEIE
7B8dzr9kwMGttt1u//BwpwFjTtEVux+m+saIGWCujwYN6ufuatdrrvm2K/FWTgqGaj17eijxp5dn
E4sIIIAAAggggAACCJSpgBtgcH/Pd3/Xdx/0KdNqUy0EEEAAgRwFCDjkCMVhCCCAAAJ+AfsHhp1s
6wS77LzG4qY/15izPRiMOX27mu5dnYCD/UPECQ6Y03r1H6Aac57dFrWtIMyrbZJtJ/cPFmclw49c
843FUk9aZUgm702Z8rWJBAJxRRyD/Fpo5F0ATkAAAQQQQAABBBBAoBsF3ICC+/t6eksGd3s3FpGs
EUAAAQSKQICAQxFcBIqAAALlJxCJNKqpyQ6kVqVwdViJW9G519PpjijSZG7Ym3NM0+Ueprlyvmmk
5xYzZdphymQSVFWPaoXbm6DpKmn7jiYn+WC4WqFk4wUn6JAMQtidNgCRCEb4b8Qngg52cOnE7P6h
Ytez/pGSY7528GqbVltTR4y9dIlyt51fpvKkronZa94rPc17hQkBBBBAAAEEEEAAAQQQQAABBBAo
VQHubJTqlaPcCCBQdAKR+g167623tejNv2n1Rm/xdtW+B++ncWMP1N577Nxq4GDL5g/1wQfva9my
5Xrfn4BJLJHG2IPHadSQvt7Em5djn6/Qnx94RvW9zKbaA/WNbxyunUwrg03/eFOvvviKFqWleeBX
T9bhE8ZpUG/v7fPm5FosbN2wQm+89oaeX7TM2efe1N9l74N02PjDtc/gHoqaFg42yGCnQCARcHBW
zI9E8MG0Bqj7QHMff0WbTVCgIdBXXzt1svbql2jd4KbpnmNf25Nv1ERqYrGQE8Bw07TBjK2frtPy
5cuyGo875GDtu1uqyyT3/M9Xv66/vLJWoZ5RbVi0VIla2hK+pz8/9EcNqwmq0azZJ78aq3fX10+a
YPzt/rQpUq8Vb7+lN//+ppamXRPtuqcmHPwVHXLgKO3SM9PJaWmxigACCCCAAAIIIIBAFwtkfUio
i8tCdggggAACxSdAwKH4rgklQgCBEhT457vz9Zs5z7dS8o16f5GdX5BGnagfnjVetd57yds3aP6j
d+j5xH38NtMYddx5OuvwES0CF5Ftn+mtDRuS53+qbcd9qg+e+bWeeCtzkm/97Qm99bfXddalF2q/
XaozH+RsjWntwj/r7qcyJ7Tx/cV6ZNkijRx/pPruSDzpb2/Sm/v7za0Y7B8l7o37yPbPtWTNGmfd
bt+8/cTmgIO/EO3P16aTKEOy+UXDRs1/7M4OGW/5eIUJVCxL1CmZvs3H1mHD+0u10bza5URT80Z9
9QQTcEhj3f7xUs357R+1yp6Yadq4Wq8+ZWfpxKk/1PhhqcBHpsPZhgACCCCAAAIIIIBAlws0tyZ2
W/kmf+c2vwszIYAAAggg4L3lhQYCCCCAQB4C9oa2nTe+/ZRu+8O8xI1os+52JZT+6hz/3l/0wnub
m4+12z75+zzNey/VxVD6ee66m997f71XL66u96Vh98XMWALuMfH4G7rzl7fq8TfbKE/8E835zeP6
pMn9YyEF4Kb1yeIndNdf3mxO21seu+xOy19+Xq+vMS0ZBqS6NLJpuJO9GW/nUFWi5YG7nr6/I/m6
adlXm76dbHobPMZu+Vt7tcc7xmu2NNfZbovGtjvr7nm2FYWdI5GI8+qWO7E/cay7zb5uX/+6bjbB
hn+YZbvuphMbOlR7D92led095y93/VKvrK136sAPBBBAAAEEEEAAAQS6W8D5PdWOXRbZoXiT+X3X
PPDkzI3mb5OmrYrbfeb3XCYEEEAAgcoWoIVDZV9/ao8AAh0V2LpKDz/0qpNK8y/Xww/XeV8fr936
1yjWuFWfrl+lhc8+pqUbE798b67bZo7fuTlnO6qCnez5g/Y9QkeM30/DBu+s3rY/fzNuwdbPN2jx
M3dr/vLEcfZG+vOvLNP44YeoJrHJ97O5HJ6t40/4pv7ly8PUM7hda995WX94enHzHwOBwFL9ffnR
mrT/AM8ZycWtK/SnRxc5K83pDh+vc48brz12rtG2uo/19ktP6bmlG5z0Bg6UPvmkZTLZtqQHHpxj
25mvuZXfXFZbXpu2fbXGbvl33fdwHTnhAA0d1N9v/Ow9mv9+6rgXXn7PtDA4RD2Shd919Ek6f9BW
05VSRB8tflJPLU7UORgcpGPPPFEj+oQVN90pmSE3FAj11WBv64bIBv1l5pPNZbMLw8efosmH769+
vcwJZopu26zFL/xRTy9O9Mdlyz73rle13/X/P3v3AWDHVR/6/3frNq1WvVrNkptccMM9GONCTAuh
OgSIMSWUJOT/SEgvhCSQvJf83/unvjxCIHkhgEMwYBvcsXHBDeQmW7Zl2XJRt8pqtbu3zPx/vzP3
d3f2anfVtbv3fgdmp505c85ndq2Z85szc7n0hBT8QAABBBBAAAEEEEBgfAXse2nZwT69eC1J1Peq
6NW2SLFDv0emF79T9co5QzPT+J4hjo4AAgiMvwD/Eoz/OaAECCAwyQS84dqm6x+6UzbUnvIP60+5
Uj791tPFPqMQ6ZPvkm2TmYtOkjdfs0JOfegm+fdbHpcFs6eEJ+KtQdmG9tlLZeXK6bLygrPluNo2
bfaWUsm+CCBS6Jot577tI7LjL/+P/FSXw36r18iWgTNloV7Xe3nK5eRJe29kDzvLEnnHL79bTpxZ
DE/Qi5Zs6emXy4eyFfnnG1aFvOwp/XtXrZPXnzRdrI3cy2X5bnjsoeH1W/IG+ZX3niNTksylc/p8
OevKX5IFi2+VL193v9Tf6FTbPtLEyzvSNlt3uI9r+XXOPVZOPnmGnHT+WcHY1lkPg7TxeWq8/Yv/
W1bpeTGD6MmnZdOe0+vGmbZpMn/hVBkYGJBozgw9h6+EKkTRdJk/b5bM7CyG/dra2hJD6/lQy2vr
E/fLI6knvpa87ip5zwVL9bVYVoYk5JQpTJXTL/+AdEZflf/66Zbaeb1LHl1/oVx4THv9vPj5Gc2P
9QgggAACCCCAAAIIHE4Bv36362cp7ZHq2ntEdm6Q3GPXac+GAZFZx4n0zJfK6z4pma6Z+gBO8kAN
162H8yyQFwIIIDB5BHil0uQ5V5QUAQQmmkBlg9x3x/OhVHYRHsfHyfsvP13a9UK8/rqc2ny1mpOl
5/yc/PZnPyuvW9ZVDxLYzlMWnSk/93OvH9YQ3rh/JNPl1MuOC/slF/xx/RsO3ngeCqI/bN+kPIvl
vZ+8So6fnt+rPLNWni2nhzLXegRYI7pnUJ/ulNU/SD4skeQXy8+/+bXaID5UPwtW2DBv5aVyzdvO
HVavpJz1zFJl33vd8LSHftx0fubRdcwZ+hHtS+T4Od0h2LOXr9UpGK8IhUvqG0mmZpQsD72yqlbt
Wn1LmmeyzXZ2/6FavioPf3uoR0kcny6XnbvMEu51XqIoKydceLHMTp2bx57bMJQVcwgggAACCCCA
AAIIjJNAuCaOqhJrL+54UF/9qUEH2bFB4r6t+mqlVyXWi+T0dfg4FZPDIoAAAgiMswA9HMb5BHB4
BBCYfAJ+Eb1n83pZXWs0tnXRaStldrakT6wnTff+RI9NbbQ04YPCtk9t2db5aE/b27wNvs7nw1T3
sQZ+yyOT0Rf7lMtSyQ59p8B7OPi+F131JlnYXtby2N5DPSGSpTaZc6x+f+AZ7YRh+T23Vp/mP0eO
afOPHmsv6V1b5IV0/Y65XOZrfuWG7z1YmeyY01a8Vi499j655dnkVUZ6RDvosLrYscu1bx4k5Rj6
afmYU9R7ZI5r31rwYICV1+ZtsPn6kM2FbzJYOXI5LXuof7LVymf72LRaTYIFtm8mk3zHoVxO7Gzf
cJ51t1CfnS/LvTUjS7/o4pUyLSpJuXZ8P7aXI1ucJ6cuq8gta+08Z2TD2g3Sd+Fi6eJJMadiigAC
CCCAAAIIIHAUBfw6NVz3a6/q7OCgiI5xlFz3V+yyX+dtu15Mh2vY5Ho66elwFIvKoRBAAAEEJoAA
AYcJcBIoAgIITE6BTJyrN6bbRfhFJ84LT8RH6QZsrZpdbPvgF+u27PM29XlPpy3bMlga0Ov1pLdC
Vv9r3fvq5tTx9m4sr9rTRrW8bNrZlpTP8xx+jILMXqxP8z/zbO3YGgwJ+3pqvYfYtUmeT+W36Lh5
0lZbHko1NGf56xGHVqTmbJs7eKO/Lzd+XO5IHXd4/bVwalyqWIBIX32lgxnv2rYpzNsPS58EJZLO
gHvtX0+594yntWl5j32zI8nPlvsHtsvmrRrYqB3X9/Z98vmq7NR7OF+Won5kW/djQAABBBBAAAEE
EEBgvATq16Z6a1O1oIIFF3TevungQ7Wq6xseqvFtTBFAAAEEWkeAgEPrnGtqigAChyjgF9neYN77
qnYdrjVK27QtlwlPx+fzyX9a/Sl3O6w1rvs4ajFKO+W5p9fIM2uelZ8+/UJI7/nbPn58m7ceDskT
90nPiSRdErhIGsk1YFAe1PJkpbE84ckjzaMaZ0MeyTtW/Yn9ZJ0dQz8HN6x+C6e3pdIPBVLS5bL9
bLB11kae3uZuvs7KYSaRTr1Mtu+hHtfyGGmwY8WDO+SZJ1fLs08/J488u75WzqQx391sX0urQuF8
xnEhZJesS3qEZLVniS9nMtnQo8Ec7Zz7GHbSH3Fm+HnZeM918iV97a3vX09nYJa+NrV8LE1GA0lW
Nhsb9/F9mSKAAAIIIIAAAgggcKQEkmv75BtzsfZsyFTLYbSHkfSqVq/l9UEdfVDKelxntBe23X+k
r4m5hj1SZ4Z8EUAAgYkpQMBhYp4XSoUAApNAYI+++scvvq24+sKeUOrQSBwarJNGZb/A9gZkr5qt
t/0z2iD98iP60eXv/jhsStYN9YrwdL6fbddm6dqxfW3SUJ0uj2/x4/vU16envl+Sd7KlcV1Xh31S
eqih3PMbPrVyJw3nIfEIP6z46eNYkvSyva7Ij23bDuW4XjYLY7zy2K3yle89MOxYlv9QGltKBj9+
uly+rXFqp9rySI/pNK+uTwIbtm6k/Pz4jdvqyzv049PhnKdzZR4BBBBAAAEEEEAAgaMrYNen9hBM
Lrmgr13bDl37R9rbwXpNMyCAAAIItLYAAYfWPv/UHgEEDkLALrLtYrui32rweVvO6jt57Cl3G60R
2XsWeEO0pbF5CzzY4A3NG35yo3zl+ofr6y2dDStWvkZmTZ8mhaweT78nsP7m2+VZXZ9sT44dRUlD
t63z/cLO+iOr5bAy2Jgugx0/nTZ5ct6/TaCvRdL9bKhoz4N0/V7ZskfOmt9Zz8/rYd9GSI6vTzvV
Gt9t//S8LXsZ/dg+tWP4cSydvRrKly3NgR7X8rAhXefNj/xA/u3Gn9aNbbvlffwpZ8j0nm7tnWL9
Gary0m0/lGdq/pbGBktneZmLzQdTnff6q3Td2da5n+1j6dunzwj18V4ci8+7Qh07dP/kn2BLZ4Nv
92lYrzGsWctOlIKei7jWc8bytMH3Cwv8QAABBBBAAAEEEEDgCAnY9Wf6+rwyOCDZkr4DtDbYdhvt
viBbvzcg8OA+TBFAAIFWEyDg0GpnnPoigMAhC/gF99S5CzWvNeHi2jK1J/NtsEZnG61BON0o7A3U
6XXSu1au+95PQjrL14Zz3vpB+ZlTFkkhTr7JYA3QdoG/NLtBnv3Bk7XjjX4BPyz/WnnSZbG8bGhM
Z+u8DDZNz9u2kr6T1QavW2N9/Bi19vOQ9kB+pI9p+/nxD/W4md3PyXeu/+mwopzzlg/KhScvlHaN
/XjAxKbHFjbJM99fHdI2lse9bJpNVdJeqTRU9+Hn3PLIt7cNO/as2Utk+fIeKRaH9xix82zpPeBg
O5lxW1uSblgmLCCAAAIIIIAAAgggcJQF7FrV7iXs8aTQr1mXtbO23VgkfZxrtyiWjgEBBBBAoHUF
CDi07rmn5gggcIACjRfOuYaG4CfXb5ULFi8NT7hbQ3Fjw3zj4Sy/0sBO2awbbN7GUy7/JXnDyfN1
xdBT/h5wqJSHggCWl13sWw8HO47t6w3ifpxcrXeDPXFvaXxI9tPuznpj4Pvo7rUyJPl6eXwfm67d
0qs9LRbW6+f72jTJsyi5cJwkoBFuQ1IN8+m80vN+LJ9G0fB6HupxB/fskE1Wwdqw8tIPyhtOWaBl
tm80DK0353LKOJSnFpzxfUeaWv3N153d2kxsiPUYXjdb3rJtl/7sCWa27D0i0mlsPQMCCCCAAAII
IIAAAuMpYNenNvh1aljWddo3Wtfq99hso/6wq97YrvvDCos/1GZsOwMCCCCAQMsJDLVAtVzVqTAC
CCBw4AJ+0R32zBbCxbfnsuXup2S7vl7HB2t4brzYjkol/dbD0LDz5RfqC5b3MYvnhDy9sdo2po+Z
ntcN9X19Jn08DSeE4/s6L48t+zrfb6RpYdp8WVk7Rki/6mnZVh3atzG/3S88LN+3dz7Vhv05hqdN
T4vT58vJ6TwO4bjmtWvDi+ns5Zgls4OpbfNxNG/f0eti0/S8b7dbrtGGwvQ5sri20Y63/p4n5VW9
K7N5G7wMNu95N87bMgMCCCCAAAIIIIAAAuMuYMEEu4610a6N9X92VRvpss3b4Ne5YYEfCCCAAAIt
JzDUMtZyVafCCCCAwMEJeANxbtoyudRbkkNWq+SmB14IjcbWcGwN8kOjyOYn75I//eIX5VsPW5+G
5J392c7uWu+A5DsG27b3hlf82NP29oofm9rxytufldtuSV71E3bex490w7U9QW+jrWsc09l4verT
3DRZtjJJYetEnpDbH3ox5JEONliK3hcflL//xp1hW7LHgf883MdNel1ol+/OKcHQTbfv6Au2tt2O
ac42X9mxVu5Q47TdaLWoVkthU+L5rLy0zb5fkfj6PvX6FGbL6aele208Ineqo2/39P674uerUCho
nsm5S58/T88UAQQQQAABBBBAAIGjLmD3BdaT10adt7sE/dpZGG2eAQEEEEAAAQIO/A4ggAACBy3Q
Lsedfd6wvV+442ty7R2Py/a+pEFaoor0bl0nd379T+Qfr/1hSDutI3mbnTU4t0+ZOqzh+b5v3iHP
bR8M65KMK7Jl3cPyP7/0bRn+nP6ww4640NgAPmKiMVcWZfHJjfX7v3LjT56Xvlo3jUpppzx933Xy
//3rzWPmdGAbD+9x27oSYy/Dvd+4XdbWjO0c6Fcc6sbrPdE+plNmzxuW4o4f3C8bB/SmSzuU923f
IE8/vV7CYkiVl2VnXjEs/dq7viFfv+tJ2bGnUg9U+PmqDOyWV557VK7/+l/IX/3VdbKpPDyQMSwj
FhBAAAEEEEAAAQQQOJoC+pCNBRrCaPM62BU1wYZAwQ8EEEAAARXgGw78GiCAAAIHKOANwzbtOe4s
uXj2vXLX1uRi27Jac8918vS9SQ+HkbLesKu/3nMhP22RnKVPBz2oCe0JfJHH5Np/ekJWvOY8WdAV
yfr7HpTn9YLejzlSfqOta9zHlm1oXD/W/t3H7l2/h2/4N/nJjUON4Emjvd1zpJ/iHy3Xfa+38h3K
cUN5tCzmaXnlehYG4wfq5XtcvvmPj8sJZ14o8zoqwfiFfRdrWIops4+R2bpmcy3PzOb75Ev/44GU
7Qny4d98l8zRf2WtDG1zXiPvOu9h+db9W+r5vPzgjfLPD31fZM4SOWXhDMlU9sjmzU/rmCRJejdo
BuEbHEO/T5YfAwIIIIAAAggggAAC4yFg19o5vRzN6mjz4co0p8+y2siAAAIIIICACvAvAr8GCCCA
wAEIpBt7k/kpcs77rpazZu39TM/IDfDnymWnzqs3zse5GXLB1W8Ky+liPPvIj+VHGmx4IbVyxcph
72+S6DA3PNvz+XsPWr+r3i8n6c1E4+D18+nss98uH/6lK+vJbP3IedaTjDFz8Me156v8mwpWBsnP
lAuvfvMwYzt3z6y6T+7+8UOyvuZo645rMPZ89ipo5yK5+FwLOYw2DHlZvhY8OPZ175N3XHRcKiiR
7JvZsl6eWLVKnnjiGdmyJQnkJPvYfJsU9Y7OlhkQQAABBBBAAAEEEBhvAbsq9et/v0K1a1V7PagP
XLu6BFMEEECgNQXo4dCa551aI4DAYRCoX1QXZ8slV39Kjn30J/LALffLy7XGYf/OgX0fILP0VLni
3PPk9OPnSVGb4aMoeQLfthVmrZRf+1i33HfrzXL/s1tDydIX6ZklZ8hbLjxfjp83ILev/j/ycEhR
lGwIAvhlvkaQs8VhtSru4ymjbC6dvLPesG3ltpsIn0r7fHnzpz8qSx+4V35w/5P1xm+vf3XmifKm
Sy+QE+d3S2Xro6lMZ0p7bqjh3Tc0lrMtn3xfwo/n04M9bhzPlA49bgg26EHNuDjnZPnVj3bK/bff
Kg+s3eZFCWmC9ZLT5S3nnSsnLizLbav/qWZc0LfRDg1+TmxqAYRlr7tKfr7tTrnurkfr+di24HLq
culp03RREixI9i3K8vPfLp9YvlZ++vDD8uBTL4fM0/n60eYsOUVOPXmlnHTycplZSOfhKZgigAAC
CCCAAAIIIHB0BTzQEEf6nTkdbbBrWeuoXa0kvbJtnV+H2zwDAggggEDrCWT0H4K9W4Naz4EaI4DA
JBCof0C5XJa+wYrc+3TScHzB8TOlqy0vyUd29RU6+gqaIzFYw7UN9pFh+0/n4OBgaMwua3ls2Rqa
Mxn9CPHAgOweKElGy1EotEmnfrS4sz1fb6j3svl+pVIp5GN5VEp7ZKB/UJ/Qt7xy0tbVLd0dhbDd
jqszYvtli+2aZzHk6Q30oVzVsvQPliWnHxzu6ugIZWprawvp7GbAjmH7W10GtJxVnS9XYym0FaS9
mORnjjZY/Tx9vX7VQdnT1y/9FQ2UaLpCx1Q9jtZN8/V6RFpO3SwdXR2SVxM/vh3T8rF0caqcne3t
oXz5fBIDdxefBtcDOG57Z3s4rv8e+HEtPxtizatv9x7tIWK/J9nwHQ0z9uOF8msd8u0ahMnrdi1f
cm6T4I7XM9RD66MnXPr61Mo+zJ0rSE9PTzg34WD6wx09veVlQ05/V/r798hgWQNSIVChnm1F6erq
Cse1dcl6+10Y+r22+SM57PV3tib5O7vwxFnh78zOU7o8R7Is5I0AAggggAACCCAwfgJ27W6D3WfY
NXVfX59Efdsl+9DXJLtrg0x94S67uJY+fX1oNHW+DFzwMclOmSXd3d3h+tnvK4709ev4CXFkBBBA
AIGRBOjhMJIK6xBAAIERBPxC2Rv4rUHb1nmDdvINBn2DjzZUT9PRt8d6EV4qReGi27L1hnDPz6aW
p+2fL3bK1PYp4ejeAO8BjnDBr2kLGkDI6ktTbT8fbYdQrkxR2rUh3dfbtHHwbZY+o0GGnN5I2Lqw
nEpv5bRjDqtfpiCdPRrs0Ey9HlULhOjgNyQW7LCmfAs2WJ4+eFlGK6enDdv1uD6148sBHDc3kkut
jlaWTL5duqe1h4CJly1dzxAo0rrna68yci8vv59XX45yGlSa2lYPeNl+ds7cxx3tfNpx/PdEcnnp
nNIjXbXyelky+vtSLuvvQq1h34/j25kigAACCCCAAAIIIDCeAvoYk367YejZ1XAdn7ruH8+ycWwE
EEAAgfEXIOAw/ueAEiCAwCQV8AbyxgZhb3i3qY2+PT2frrJvT6+zec/H14+WrnG7pRsrrW9Pp/F5
n1qe1lBujf3pdbbey9U4tW2e1qY+70623QZfn07j62z7oRzX9rfjeX429XKm5y2dr7d5H3w/W7Z8
0mX3/W3qo+9n05Hys/Wep09tnQ2W3kYPSNg6S+Pmo+Vn6RgQQAABBBBAAAEEEBgPAbtGtUeabAzz
Gnew0EMIPwzFIMajaBwTAQQQQGCCCBBwmCAngmIggMDEF/AGY2+E9oZhexLd5+2i2+Zt8Kmnb9zf
11s6b1z2qe3v857Ol/3Jd5/6dntljx3Dj+PbfZ2vt7xHWufpLT/bbk/i29TWj1Q/L48fvzF/W+/b
7Jg2b/s0HttfheX7WwO8pXUX38899+e4lpd34bZ6+D429R4Gvs6Pa/X0wdbZcW307V4O38/S27wv
+76+7PtZfWzwtJ6P18fLY+sZEEAAAQQQQAABBBCYyAJJ/2m739EHk6yg+sNeLWpjsmIil56yIYAA
AggcDYGh1pWjcTSOgQACCDSRgDcoe0NxY0Ozb7epj57Wt9k+/kS/N0g35uNknocvW16ej63zJ+XT
+6e3W5r0sqdvXO9pfOplTufbuE/jsu1r+3kZbdn39+P6sm1Lj94Qn3ZJ529p00N62ebTx7R0tmzH
8nw9fePU87T1nk9jXul9bJvl6fXx/SyfdDpbtuOPVh/bPtKQzm+k7axDAAEEEEAAAQQQQOCoC9il
uF7bhlHnM3HyciXr3KBX0Ue9OBwQAQQQQGDiCRBwmHjnhBIhgMAEF/DGZH8i3pa9Qdum/sS6V8Ma
pm2wBmdvRPaprW/cf7SGcUtrQ7oRfKR8bJ0Nvs2Omx78yXw/bjqtrfPy+tTTWbm8nun8bLvn4dP0
OnfyfTy/dBqb93L61D/i7OV1l3Q+fjyfpvP08tvUG/xHOj++TzpfW+ejl9/z8/LYdsvPvteQHmy7
72tT3897Wlj90o42nx48vU19f5syIIAAAggggAACCCAwngJ23WpjRu8LbLQhBBrsk2u2WLuGDhv4
gQACCCDQsgIEHFr21FNxBBA4XALeGGwNxH4Rns7bG459nTco+34+9f09na/3qa33eZuOlI+t9wZs
3+75pafpfHz9aOk9bWP5fD/fblMbw01Ibd7TpKfpdLZ+X8f1PNN52Lyt96mn8bx9fUigP2y9Byy8
wT+9zedtOloejWl8OZ2f7etDY718W6Ojn6/0fp7W1qXnPQ1TBBBAAAEEEEAAAQTGT8DCDKmHZuwa
OHUdPH7l4sgIIIAAAhNBgIDDRDgLlAEBBCaVQGMDsD8B7z0b/Al9r5Sn9wZoX27c7g3ijQ3Qo6X3
/DyfxmXfz6eN6fwbB77e0/nUy9FYP1/v6Rr3b1w+0HSev5fPXX39gebn5Wn03Vd+fpzGqTt7+Rrz
9fSNvwe+n6f3qZfPp76/p/dln3o6pggggAACCCCAAAIIHG0Be7zGww31+Yw+eKUjAwIIIIAAAiZA
wIHfAwQQQOAwCYzWIDza+sbDjpaucX3jcmM+R2q58bj7Wj5c5djXcRq3j3bc0dI1rm9cHi0/X9+Y
vnHZ0/nUt/vU1/t0tPW+nSkCCCCAAAIIIIAAAuMlYA/tWKAhBBsaXg06XmXiuAgggAACE0uAgMPE
Oh+UBgEEJpFAY8OwP9HuT843VqUxvW9vXN+4f+N2369xeqDp9pW+cXtj/Rq3N5ZntOV97de4/XAf
92B9vT5ePp8eaH6+n08938bpvrY3pmcZAQQQQAABBBBAAIGjIhBXtZuDjj5k9JtxNtYGu47lWtY1
mCKAAAKtJ0Cft9Y759QYAQQQQAABBBBAAAEEEEAAAQQQOHQB+3ZD/R1L1u+BAQEEEECg1QXo4dDq
vwHUHwEEDrvAoT7Nc6j7H/YKNWQ4XuU7XMc9XPk4y8Hmd7D7+XGZIoAAAggggAACCCBwNAWsZ2/o
3Rtp7wYba0NsMQdiDc7BFAEEEGh5AXo4tPyvAAAIIIAAAggggAACCCCAAAIIIIDAvgUsruCBhxBj
sN4N1svBezrsOwtSIIAAAgg0uQABhyY/wVQPAQQQQAABBBBAAAEEEEAAAQQQOBwCFmzIZjNhDL0d
NNM4kw2j9eClF+/hUCYPBBBAYHILEHCY3OeP0iOAAAIIIIAAAggggAACCCCAAAJHRyDp4mDdHLRX
g070qB5osHkGBBBAAAEECDjwO4AAAggggAACCCCAAAIIIIAAAgggMKKAv0KpvrEaidhYGzzg4MtM
EUAAAQRaW4CAQ2uff2qPAAIIIIAAAggggAACCCCAAAII7LeAf7LBdrBgg/Vs8J4O+50JCRFAAAEE
mlYg37Q1o2IIIIAAAk0lEN4RG5Vk56vbpXfPoESSlUJbu0ydPkO6ilneF9tUZ5vKIIAAAggggAAC
CExEAXujUhRV9UfV3qiUBBsyef2GQ77+aqWJWG7KhAACCCBw9AQIOBw9a46EAAIIIHAIAjvXPSRf
+9cbZPNeeSyVD/7GB+TYKbmhLdbDmz58Qx7MIYAAAggggAACCCBwGARiDTPE+XaJCx1SKXQnH4wu
6HK+LQQfDsMhyAIBBBBAYJILEHCY5CeQ4iOAAALNLhBFkQy8dL/89Ve+P0pVn5ON2/plaWenbF19
m/zdtXeHdJm5Z8uHP/QWWdRhz14xIIAAAggggAACCCCAwMEI+DcabCoaaOhfeKbEA7ukt2dFkt3c
5ZJpnypFDTqENAdzEPZBAAEEEGgaAZ7/bJpTSUUQQACBZhXok0eu/0G9cslH65bIGWecIktie1us
duW2mx8pyQsPJsGGsHLzw/Ly1oEwyw8EEEAAAQQQQAABBBA4DAJ63V1t65FK+wypdM2Sctdsidt7
RNqmaA/jHAGHw0BMFggggMBkF6CHw2Q/g5QfAQQQaFIB69lgw8DGZ+TGDZGEbzjocjTzXPnIB18v
c9s1Zn7FG6U8GEtbV17K5ZJ26470nbJht+QdslLV5WRFNkuMPZHhJwIIIIAAAggggAAC+y/gPRwK
hYLu1CnVGcukWqlIaerScM0dt3dIXrdlC21i19y5HIGH/dclJQIIINB8AgQcmu+cUiMEEECgqQSq
1cEQbPCAw3mvP1Nm5j2wkJW2Dv1AnfZ0iCUnU/ThqvRQzKe+65DewDwCCCCAAAIIIIAAAgjst4C/
Ksmm2WKHxDn7aHQSWMgW9VVKGmSwQAMP+ew3KQkRQACBphUg4NC0p5aKIYAAApNTwAML1jPB5vt3
9oZptVoNFWpvy0pFn6jyJ6dsPtz46NNUyy/9jHziNdulvxxpr+6ZMntaVmw/fyrLMvCbpcmpQ6kR
QAABBBBAAAEjuvLgAABAAElEQVQEEDg6An7dbEEEuy4vFouSzyfNSHat3tHREQpiPR8sjW23qV97
+/5Hp7QcBQEEEEBgoggQcJgoZ4JyIIAAAgiMKNC7dUO4wbGNcTxLprbn6svpHZJARUGmzpgtU3WD
BSQ8eJFOxzwCCCCAAAIIIIAAAggcmIAHESygYEEHCzjYvA3es8EDDD49sCOQGgEEEECgWQQIODTL
maQeCCDQ8gLWuF6p6HcMKnbxn5d8MS92C7C/F/z1xvlI38daqkjtywchn3ztSaVDQbb8Iy1fScun
X5TTfPUJKS1gY/m8HNYzweazmVy4oUl6OMyQninJU1NeFrvBscG/1eBTy9dGvxHy9I3TpFwVqYRv
PSQ3ULV7p2FJG8s5bCMLCCCAAAIIIIAAAgg0qYBfB3vvBlu2a2hf7/PJNx70Sn+ki+kmtaFaCCCA
AAJ7CxBw2NuENQgggMCkEqj0bpInH31cHn7kR/L85nTR58gJZ62UM884TY47ZkYIPqS3DpuP+uWl
px+XJ376hPx4zfPDNtnCnBPOkrNOOUVWnrRMusf4lyPa+axc97VbpLdTd+o+Td7+9gulJxvJ1nWP
yn133isPDy+gnHrRm+Wi88+SuV3DP+jc/8qjcv0dj0m+syAPPfREqjxPyq3XZWVqm74xthZo8Knd
6NjgAYfclCXyhsvOkumpvYfNlnbKmkdXyU8euEPWDHMTWXrCqdJdHJZaMuWyLDz3Sjl3WcOHIoYn
YwkBBBBAAAEEEEAAgaYU8ACDBxT8+tuXm7LSVAoBBBBA4IAFxmg2OuC82AEBBBBA4CgI+IW9Tbeu
vkv+7to7wlF9/VARNsqTD26Upx7S7Se8UT7z3vOlO9WjwNMPbnlKvv13X5enajv6+qF8RDY++aDc
+NRDcqMslfd84ipZObe9/kSTp7P9yn3b5ZGNG2urFkjvG7bImlv/Vm54zF6HlAQEPL1NH7nre/Lo
jx6Ud3/qGjl5dlvYZAGDbS88IY+tWRP28Z4Ovt+Lz64Ox/ZAg9/gNOafyfTLOW94rcyo9XTw/S3d
wKbV8vV/+KY8rysb97N0zz35iE2GDXaDlT/pDfX0fsM1LBELCCCAAAIIIIAAAgg0mYBf9zZOG6vp
2xvXs4wAAggg0FoCwx8pba26U1sEEEBgUgtsXX1TCDZYg3m60XzE5ad+IHc+9epe9S1tWiVfqAUb
RtwvFSRItq+Ta//xL2TVptJeeYUVqX9V4vhh+ae//hu5/tHh5dt7x01y7d/dIJsqQ1tyMhDqtK96
De0x0lybJC9batjWt16+8Y/XyroGt9lLjpcls5OyukX6+JbLtj3lhsxYRAABBBBAAAEEEEAAAQQQ
QAABBBBwAXo4uARTBBBAYIILeON3mPatk298497wnYX6+sXnywd+9hyZN61NotIe2b5hnTxw+/Xy
xJbkWwZbtu2WarWn/k7VqLRRvvv335ZoWMP78fKm91wgKxbMkvZiVioDvbLh+afk1u/cLltqPQWs
x8G3//6HsvSPL5f0y4VsfUVH66HgZUqTnn3Zu+TsExdJe3aPvPjEj+U/b11V7yWRyaySh5/8Gbni
pOlh/+mnvkU+MG2rfoFOZN29X5HbVuv3HzTfTGa2XPbuK2VBW1ay+rE6e4rKn6TKZGLZsOr7ctOq
LeGwtTcu1YuQvGopkmfu+Z6s1XLaYOWcffbb5N0Xn1R7VVQkO195XK7/6g2yvran5X/F1R+X4zsy
UuiZUX9lk/es8OPXkjNBAAEEEEAAAQQQQKCpBbj+berTS+UQQACBQxZIPYt6yHmRAQIIIIDAURJY
//BdYp8dsAbzMJ78Rvm1X3idLJzeHr7VkC92ypylp8hbrvlv8v4rTg2lWjine1jptjx+jzyq+/sQ
x+fLx37znXLK0jkh2GDr8+3dsvikc+SDv/xOmZ0KTMTx3fLQs72+a5haOaJoqDdDvWzxYvn5j31G
Lj1rufR0FaXY3iPLz3qjfPjNp9cb7y2DHz/yvAyEDzfrh6QLU2X+McfI3LkLZPGiE1MBjNkyd/48
mT13rixYsCCM8+bNk2TUtAvmpNIOK16yUNkkj969KcyH8s2+RK66NAk2WEDCDt897xR5+/uTVycl
dYpk07ZYps+apd91yI6d/wiHZBUCCCCAAAIIIIAAAk0lEOtFs42RPsRjo91TpO4rmqquVAYBBBBA
4IAF6OFwwGTsgAACCIyPgDV+21AZeFF+dNtzobE+aRBfLr/4+lMkXyqJvejInziyaSaTkwWnXymf
OeVyKXZ2ag+Hamgwj+Md8sh3Hg3zts6Gt39Mv/EQlaRSO44fL2zsWiJvf+sZ8g/XPRR6SFjed92/
Rs5ferr2WEga4a3B3vIaOoaVd7G8+xPvkGVTYilp+WzwfHuOe42cWn2oHvTIDQxIRfOwf5gsjeVj
eZbLSY8JWxfH+qqlqk41keWX1DFTz3dgsBL2SQwqum9ZqvrxZ08XV6oyoPlYrw7L+7zXnyAFTWMv
SvJy2frc7GVydqUiP9b11pNhV2+fVHTZ5j0v7+EQDs4PBBBAAAEEEEAAAQSaXCBcL1ugYWCXxhuq
kg2X4RmJ8vp9t6x2Tc6FC+9wvdzkFFQPAQQQQGAMAXo4jIHDJgQQQGAiCgxue0XWhMb3Wm+C00+T
+W3JfNIoX1ufKnyuUAg9H2xVaMTftE7uruVh6+IVb5Il+n6k9P6N891LT5TjLK0fe8062TaY7iEx
VIaQp6a74D1vkWXdmaF9fF+bZqbIvBVDZY2fXydbNT/P3/LYn8HTjzS1uvpg85amkCrD1I5C/Xjp
/aMoL8VZyZ7p9TbPgAACCCCAAAIIIIBAywpYj4a+VyWze4vE21+WeOcGyWgAQgb7lIRr5Zb9vaDi
CCCAQEqAHg4pDGYRQACBiSjgjdzeYC5R0oDvy+evmCmRPn2f128a2JB+8n60p/HjuDKsJ8Jpx82R
vDbIW/N8rvbxg6SXgIR0lm8lO00WL6zK0y/5U/4DIXhRqSQ3FqF3g+bhPRxsn/Z8JixbXp6vBwGq
1ZzMPGa5RM+srT0Fpb0vtB5xIReCAF6PrD465WXJZPzY+j0FDaLY4D7WA8EHX2dTO57vH1ci6bd6
1tZv3qw3RzNnhN38eKF8pe3y0hYNftQyjHUfHywvz8/XMUUAAQQQQAABBBBAoFkF/No6XG9rsCF7
75dENNCQ2/a89jxul+iMd4n0zJd4+c9Ipq2rfj/CNXOz/kZQLwQQQGBsAXo4jO3DVgQQQGDCCeze
sa3+VL4VrqtNuy7rYBf03mju8+mppfGbhd3bd9hiGGzd3FlTfHFYPrbS8kxuFvIyfdHi+j6236A2
4Ptgy56/rbP5Spy8rsmWLY/0aOuyuaGgQeP+9bSSvDLJ0ttQXz9CfkmK5GcoS61Mnnes+1gPBx8e
/u4DsiV501M9X9v20qr7Za0n0mnXlLbUErMIIIAAAggggAACCLSeQLim1h4OsQYd4t1bRXZtlEzv
JokGeiWyHg76uqVwDd56NNQYAQQQQCAlQA+HFAazCCCAwEQW8B4NvTs2h6f2vRE90tCx9R6w0Rrj
vaeDN8xbOpu3weatB8LuXUkevq6s62w/39/3te32HQTbL7xmSOMD3mMgivqlNKCt9V0dlmyvmwsL
VNhoPRF83vL1etg+Od2eLp+t82P7cbK5oV4N9k2KYrEobW3Zen1tf88jX+udYfloiZKfuj0sWbrs
LHntz54kj934RK28q+Qr/2tA3vy+i+TY2VMl6t8h6x69V26477m6WSZznJyxfMawOngZQ8b8QAAB
BBBAAAEEEECgiQX8+t16OMR6b9Cu30XLVGvBhXCfoNfbkV5r6/ZMXr/toNf4Ntg1MwMCCCCAQOsJ
EHBovXNOjRFAYJIKJI3+2qOg1mnAlpMhuaBPN+qnL+79gn+kanseBW3I98EDF77N9rebDBu8v0Ky
rSiFYrItfTxLV1/Wmwyf91cqeb6Wzof0Opu3fWz0snseIX3txiWdn+1jZczWtiX5jnyD05HER/zQ
On1GbvyPZ+vL6bLYyvPecZnMTTqR1NMwgwACCCCAAAIIIIBAqwmEe4LwelJ9Zan2ZrAGJbsjsdeV
2itI/RUafj3faj7UFwEEEEAgESDgwG8CAgggMMEFGhvAu+cs0BKvqZdam+frPRzSQQdvrPeE1rPB
BsuvZ84Sna6u9wzY1V+uP8Fv+3mDv98s2M1Ftdov2ze85NnVp7bN0lvaSJ9sSg+23gIDlqcHCGxq
+9iY094L6SFdV9vHli2I4PlbWpv3MtqyzVte+xosr7h/vdz8rSeGJfVjWr7Dh1nyhne+Xc49flr9
mH7cvdMO35MlBBBAAAEEEEAAAQQmu4BfJ/u1e+j5XCpJoaL3DlXt7WDX11rJSkl7ROuoXaP1lanl
+nX/ZK8/5UcAAQQQODgBAg4H58ZeCCCAwFEV8It9O2hWXymUXl79/Ga5YNGyenmsUXxfQzY71KPB
0v543Ua59MSZoWHdGtPTozfmZ6q75KVn0jn3SDHXGGAY2p7OIz3v+YXG+4bvMwztPfJcOh+fNwuf
t71sPu2Tzmn3K89pfwZ//dNp8p5rzpbc9ldk/StbpFeDLiIF6Zg+TRbOO0bmL5gjnfqvpOWXNrVl
BgQQQAABBBBAAAEEWk3AruOtJ4NebCdjDSD0cLBrcgtA2DYGBBBAAIGWFiDg0NKnn8ojgMBkErCL
99C4nk8+tOxl3/yjJ2Xbhctkfi1Q4I3j3jBu+0T6JFJVexZYmMGWc+1dMlvnN9cyyTz8mGy9/FRZ
0D7Uu6Gx4X73+tWyOt3YfvoxMj0V27D0PoZy6rKVJT3adg84ePlt3ViDb0+mQ8ewZd9m+zcuj5Tn
7lf143a1IV40U+ZOny5FHRcuH/r2hZXdB8uzsfzpY3o6pggggAACCCCAAAIINKuAXb/7aAGH2D4c
raMP1snZLqGz+sOupdPX056GKQIIIIBA6wikmopap9LUFAEEEJjMAvlpx8qli9M1WCU3PfBCekVq
PpJNq++Uz3/hC/Kthz28oDcDPUvk7BWpZPKsXH/nU1JJr0rP73lRbvrmfek18sYzl9Xf0zpswz4W
vBF/H8mOyOZh35Ref7v81033y7oNm2TLq6/KVh137uyV3Xv2yMDAgJQqyWuaPJDh0yNSMDJFAAEE
EEAAAQQQQGACC3gQwR4VCj0dNLAQHhuqPasTtqfnJ3BdKBoCCCCAwJEVoIfDkfUldwQQQOCwCXiD
dybTIce/9ny55fl76k/4v3DH1+Ta6jvl8vNOkNlTtR9DVJHd21+Sn972r3LHU0kRpnXkU08bFWXF
eRfr95J/GDbaDcKmB74lX670yjsvOVPmTu0IecfVQdm6/gm58avflbWa0m80ZPEVctKctnqvAitb
emhcTm8bz/npi4/TOiTfrrC6vPjoXfLSYz+qO1rZvOzWsyEz53i56Kyz5OyzTpB2W26o53jWhWMj
gAACCCCAAAIIIHA0BUKgwb4Ll9HIgo52PW3/0/4Oov0ewoek7bVKDAgggAACrS1AwKG1zz+1RwCB
SSKQbui2+akrzpSLZ98jd24ZuqBfc8918vS9Q68Z8n08SLCxd2BYbdvnny4/95ofyncfTVZbuk0/
uVn+9yO3icxZKks7RZ5//vnkRmLYjcMKueptp0l7LTc/zrDMJ+hCfuZp8uErn5Ev3bj3h6PT9ajP
b3lG7rvlOR2Xyvs+/X45Ycbw11lN0GpSLAQQQAABBBBAAAEEjpyA3RvU7g/07kNDDbqoo80zIIAA
AgggwCuV+B1AAAEEJoGABw2sqNYYns1OlXPed7WcrR9i8Pep2rSqTxx5F+f0fBy/Vi47ZW7YZvsn
Y5uc8MZfkTedObMeVLDjhPw2Pifr1q0L6z2fJN/T5H2ffLss6crV8hj6xoHneyicyUuMGnMoDVsx
cpphSeoL+vxVfbC6xXGvvPjC6vo6m5m1/CR5zcqVsmLFClmxeLEsWTJnhJ4Mz8vX/+ZO2VG7sRqW
AQsIIIAAAggggAACCLSQQCaOQm8Gq7IFGnKZbBhtngEBBBBAAAF6OPA7gAACCEwCAWvMt8Eb9a3x
PNM2Ry65+lOy7NGH5YGb75eXa43hYVstfbz4ZLni3PPk9OPnSTHcDtjDSEO3AnHcISddcrXMP+5J
+clPH5JHnt1a326vFLIggw3x7BXy+rNPl1NPWKyvFgqr6mVJlpKf2WwxvShFzWOkwcuQ1X+Fho7T
JYURkhc6pqXSFPb6boTl5WOmmP5nrTgsP0vz0n3fkZtT8YaTLvsFefPpC+sBBvMtFAp6A1WVHZue
kTv+7XuyVvez9XF8tzz1ykVywSLt+sGAAAIIIIAAAggggEArCuhtid2ZhLuT5Bal3sOhFTmoMwII
IIDA3gLplpm9t7IGAQQQQGDcBTzYYA3z1mheLBalUqmEUaRLlpx6kY4XSEk/dtzbPygzZs6UaT3T
5NUdvdLZnvxnPh4clEgb0n3o6OgIDet9fX0hn2nHnCRv0PF1pQEZHByQapzVJ/2XyOYt26SsQYcp
7cVa8CHSxv98aIDP5/PS3t4upVKp3uCfm7FSPvsby2SwXJWcHq+nuzscx9JY8CJpuB8KeMw89a3y
J+e+V/bs6ZdKpPvU3gVr5fQgwoyTLpM/O+fnZdur27VcWuPCUIDB65PTr0F3dXVJfPKV8pllF0tZ
E1rZ7CPRHjTp7MhJ+4yzdZd1Ybf42CvkDafOq2+3QMOMGTNk9+7dalCWqXNPkCveuVn+9j9/HMpt
x5jaJqEXiWVgyzb4+QkL/EAAAQQQQAABBBBAoEkFwvV5pD2iq3pdr2PteSaJs7kw2nUx18ZNevKp
FgIIIHAAAiM8S3oAe5MUAQQQQOCoC1jgwRrXrcHfLvqTISuFji5ZtGiRzJs7Vxvb22TOrGn1xnRL
469GsoZ4DxZ0diZP63vjfr7YLt09M+TYY48NgY2FC+bJ9O6ueiO75WNprXHeghZWFguAeCAhlEcD
ErZu6pQpIY0dy5Ztmzf++/GmaBrbNm1ajwZH/KsQdpTkOJZvT0+P5DSPWbNmSltBb2Y0Hx8tPyuD
HcMCAJZfRqcFTaer6/mEAEtxiiw/5xx55zvfGdZfcPYy7fWRDJaHBRssHzteW1tbqHNcTB7bsuMt
X75cTp495FXblQkCCCCAAAIIIIAAAi0k4PcfVuXavF6z6w1BCxlQVQQQQACBsQQIOIylwzYEEEBg
Agh447pPo+9cK/GmDTJ16tTQQG6N7hZMsEbybu1RMHjrD2Tgv31c7Pl7a4D33hCexhrVy3/5OSn9
+7+EgIDtY4MHA6ZPny6Z/j0y+NH3SeXxR0IDvAUY7Pg2WIDA8o2eWi2VX36/ZPp2h3X+NJMdxwIZ
Npa+/q9S+vM/rAcEbJuVx9NYGQd/45NSuvnGkN6OY9vL5XI4luURb9kkpWveK/ErL2lgYloIblhZ
LZ0d0+pTvfcuKf36RyWr+Yfy63o/lgVYLN+B//4HsvZzvyvnnXdeCDqsWbtBe0IkX3mYNWuWZLUX
yKDWp/yTB5IgR64sD912ZziOBWDe//73y+Aza6R6y/dD3pa/lcPPSygwPxBAAAEEEEAAAQQQaHIB
e7DHH+4JgYZIgw02EnRo8jNP9RBAAIH9EyDgsH9OpEIAAQTGXcAbtjMvrJP4l94Vgg7WAG+N6dYw
bw3tA9oYXvzMx6X9pu9pA/zH9BsG2dB4bg3jlsbSlr74R1L46j9J4c9/X0r/98thvQUdrPF+pr6O
KTvQL+Vr3iNt994p2Y/+Qgg62NP/FtCwYIOlrT71hGQ+/B7J332HVD98VQg6hFcaaVDCghE2P/gf
X5XC539Hiv/+z1L6098PgQHb38oSelno8coabGj7/nek8JufCEEH29fSeC8O2bo51LV4/906fadE
L78Yjm9ltR4NltaCDblfvUaKt9woZZ3mtQxmYYOV1cpd+n+/IO1f+bIs/+ZX5dk//h05//zz5ZKl
Bbn5wSf1FVSzJKevfCp/7BelTeuT+/gHpP/+H2ke86V35uly3HHHyYc+9CHZ9fiTUvzIe0IAxOrA
gAACCCCAAAIIIIBAKwr4fUm97hZosJEBAQQQQAABFSDgwK8BAgggMEEF/ELepv4kvU0HzzpXsps3
1oMOFgywwMOANrgXf0Mb7ufNl21vfZe03XGTDHz6I5LXi38LJFjj/KD2Nij+25ek7w1vlMHTzpTC
F/5ABnTZAgRz9VVMIdjwofdIcfVjsvmqqyXWRn0LOpQfWxWOYcep6LaMBiT0U8qy/YMfk9yTj0lF
97GeDvY6Istr4GtfkeKf/q4MnPwa2X3plVL8j3+Rwc//Xgg6WFAh9GzQwEjxlhtkx9veLaUFi0LQ
YeCm60MAxNJYz4bqB98h2Y2vyFY9TnbHdhENOlRfWh8CCRa0KN/9Q8n+6oekokGDHe9+vxQ1YDD4
qatD0MHqbGkG/urPpPilv5XeCy6WbcculRXX/qs880e/LRdccIFc/dZLJKffrHj57ZdLcdWDcuOy
k2SXvZP2lz8oG2/5QejVcM0118jOVY9I96/8okipLINap3SvkQn660OxEEAAAQQQQAABBBA4IgKZ
WK+XdfQh1vsNGxkQQAABBBAwgdwf6wAFAgggMBkErOHdBmt0L2uj8Ivb+sPyopmdUsxnwxPv9uS7
PR3fTIPX217hY/ODM2ZJ6aRTpPN7/ynRzTdIfNmbpPTjezTY8Ekpz1sg6/7wv0vvuReFiHLPjd+W
wTWrJX/FW2Twi38s7V/7suzWYMOWX/892X3hJdL+1OPS/l//IQPdPZJfcXzo2VDUAMKGT/2mbH3j
26T3zHNl2o9ulex3/1Mq514o8bYtkv3IVfoEU1Ze+bP/JX3aiF9dcIxM0bJU7rlLsle+TQa+9R/S
/me/r8GG0+SVP/xL2aPHyWtPhc7vXiuDr26T3IWvl9JnPiHtt35ftr/7A7L5Ax+V3vMvlu6HfyxF
LUtp+fGS7Z4qkQYXchs3yCu/86ey65I3ysApr5Gp2nMj/oGOWofqoz+V/Kc/LNWZs2XDn/9NqHNU
0G9H3PBfMqgBkryVRXs2dPzLP8juiy6Rl37td6TvkstF9JVJi7T3xjObt8i0154vm971s3LMK+vl
68e/Rm5btEIenTVfzt6sPSluvl62HXeilHr3SM+v/ZLkqhXZ/MW/lcwJK8PvmL3KyXta2O+bzTfD
4L9vjX9ni2clf2f299WMf2fNcO6oAwIIIIAAAgggcCQE6vch+gpSGdwtHWvv0NeR7pZsZUAfUGqT
/gWni3RMldyMxZLV63HrVc314pE4E+SJAAIITA6BjDYspL/4MzlKTSkRQKAlBfxC197v3zdYkXuf
3hYcLjh+pnS15esXtvaqnWYY/D/P3rthYGAgfDugv78/TDP33yPzPv9bUp02Q3LakF+aO1/W/sFf
SGVqT6i+XeTP/c9/k7nf+pqUFi6Sor6OaOfFl8krn/pseALJ8s/o0/1L/uIPpfPxVVLWwEFhw8vy
4i//P/Lqz1xab0Bvf+VFOfbzvy3ZKPneQazBhhc+9z9kz/xjwnHMu+dHt8mCv/kLDXgs1Dxekv6V
p8q63/pTibWHgZVD/7GRBf/41zJNe114Wbb8/FWy6aoPhQCSZVTs65Wln/ustOn+FQ0i5F7dKi/9
1udl5yl6A6OD5dO15glZ8ue/K9GUqZLdtTP0bFj/ub+SsgZh7PfDhtnf+abM/Zq+xqlW5x3nvU7W
/8pnxbZanWN1XP4/Py/TnnhUdul+3Xqc76w4Vb4/b0nY33qMLM4X5YO3XCttlbLExTbJ6PSlP/lr
qaw4IfSusGCDvaLKGt+t54gNVr5mGPb6O1uT/J1deOKs8HfWGGhphjpTBwQQQAABBBBAAIG9Bfx+
pKSvH7VrxF27dons3CA9N/+B5Ho3SnFgh1SL3fLqWXpNP3W+FFdcKLmOKeE7cXad3Cz3ZXvLsAYB
BBBAYCwBejiMpcM2BBCYUAJ+wdv45HWr9HCw1/iYgQVczGCPNpb3H3eS9NxyvZQ12PDc739RKj3T
hp2zPn39T1YbwqfqNxB2vk6DDdbwbo3uOtoQ5/LhVUOd2guifd2z8sonPhOCDbbNG9Ar2vuh98xz
ZNrdt9taef6P/lIGj1lSDxRY2oHFy6Qyf6FMu/37suekU2X97/6Z3ny02aYw2NH6XnuBFLSnQ9ej
P5Gt7/gF2fjeq5NttbJIe4fsPO9npFt7IBT0dUrrP/s52f2as4Ydp6SBiEENQEy79QapaP0t2DCo
ARerj9epX48f61NVPdqLYef5F4dgQ6w3PL49Uo/t51wkXS+slanPr5UXP/QpKV7zcTnjjDPkrLPO
kpUrV8rCE0+Q3WefJzPu014b5ZKs/b0vSNl6Xmg+9k0Im/qTW34j5V6hUpP4R92poScRPRwm8Uml
6AgggAACCCCAwCEI+AMpg9rDIR7olY7ntIdDSXs4lPv1urtd+ufpA0Lt2sNhpvZw0Ad37IEcuza2
a2YGBBBAAIHWE6CHQ+udc2qMwKQV8AvdVunh4CcqXW+b7+vrC08Y7d69OzTGF7QBf1B7FlSnzwi7
NDZ8W3Bi6gP3SK82+OtV/15PGlme1tOh64lHpPeMc/a6MfAG6MKLz1sXASlrcMEGv4Hw7Tadsuoh
6TvxlNCzwRviQ2L9YcfRAkv3g/fKrnMurO/v5bVy2pDRbzW063ca+vUVSjZ4Pn4cS9f59Gopz54b
gg5ejpBYf4Tj6LRb67xLXwmV0d4INth+loePkfZ0mPrEKtmldbbB8/Hj2LRt0wYpaMBhcNmK8KSW
Pd0/derU8C2Kjo6OsI+ts8HrERYm8Q/zs7rX/87o4TCJzyZFRwABBBBAAAEEDl7Ar4u9h8POnTsl
3vGKzLol6eGQHdgpUXuP9nD4sMQ9C6Sw/DzJtXeFnsB2bezX8QdfAvZEAAEEEJiMAkkryWQsOWVG
AAEEWkzALtpHGvtXnhYaiL3B3Kd+g2BT+6aDN4j7ducLDf3au2C3Nc7rSt/u6T0QUNJeDTbkak8q
eTo/jqXrO+O1IU06n7BCf4R89PVLoSy67Pv7cTxdVXtp7NFxtOPY8fpPODmxSOXj+3t5ejWokS6H
Hce2WTlsGmtPBftGhfUAscHL4/vbtKKvmarqdktjN0yWxvJpLLMfmykCCCCAAAIIIIAAAs0k4NfG
Vqcwr5fOdvUcrqCTy+hmqi51QQABBBA4DAIEHA4DIlkggAACR1LAG8LtyXObt1f62Ly9Yskaz+3V
Pnbxbw3i1hDujeL+pLo3sPt6T2f72OjbbZre39LZds/Hpjb4/j717Z6PH8enlmc6n9GO4/tbvUY6
jm/3qaWxvL0cIx0nnY9tt8HKa3nYE/xWLltvo5fX0riLzfs269Fgx7Iu4jZNH9fSMSCAAAIIIIAA
Aggg0GwCfg1t9fL5SL/tltHRG5Qyem2sF8fNVnXqgwACCCBwkAL+78NB7s5uCCCAAAJHS8Abvq1h
3BrELdDgQQArgzeYp1/x4w39tt32t9H2s8G22eDfhrD9bfCGdJv6YGn9BsOP4/n4eg8UeD7pcqTz
8e2Nx/FyeNrG41iQwAY/jqdrLIett/L6cTwfr4+V17b7aMs2enl8fw+k2HrLw0df9uMzRQABBBBA
AAEEEECgWQXsmtkHm08e4bF1yXq9jA5ztmTzDAgggAACCBBw4HcAAQQQmOAC3qBvDfh+wR8u9vWK
3qa+Lt1wblXyngA+TW+3ed/XG9ZtH1vvDfQ2tcG37+9xbB/Lxxvw/VjpfA7mOKOVt/E4Xl+bpo/j
5fB8PHBh623w+no9fWrbbbSeDZbGzoMt23EZEEAAAQQQQAABBBBoNQG7S/DPQYcQhD0XpKOHI1rN
g/oigAACCAwXIOAw3IMlBBBAYEILeOO3FdIDENawboM3mHtDuKW1wRr6bfBl73ngDephY+qH7+/5
+ab9PY6n9+P4cX29H/dAj+P7eT4+bTyOBxK8/H4cL4cHJHzZ8rV5T+/H8amns3xs3kc/PlMEEEAA
AQQQQAABBFpFwK+Rrb7JvPZtsPuOcO+R9HpoFQvqiQACCCAwsgABh5FdWIsAAghMOAFvEPdXCHlD
emMgwBvI/WbAt/t6z8cr6Pl5et/u6X295zPadk/n+Xo6X/bAgKfz7Qd6HC+v5+v7+3R/j9MYiPH9
PV8vpy+7d2O5fTtTBBBAAAEEEEAAAQSaWSBcH9srlmLrzpA89BTqm9Wevzra9XTjNXUze1A3BBBA
AIGRBQg4jOzCWgQQQGDCC/jFfGMDuK/3Cvh2X27c7sujTX0/z6cxnW9vnHo6X+/Lo0093cEeZ7R8
G9ePdhxf71Pfb7RlX88UAQQQQAABBBBAAIFWEUh/piHM+8cbrIcDHRxa5deAeiKAAAJjChBwGJOH
jQgggMDEE/CGcH/i3p/E9/WNJd7Xdm/g31e6Q91+uI/j9Wys9/4ex9ONlo/Xd7Ttvp4pAggggAAC
CCCAAAKtJBDrBxtstCHEGOzbbzoSb2il3wLqigACCIwu4N/5GT0FWxBAAAEEEEAAAQQQQAABBBBA
AAEEEAg9GTS0YK9Wqr1CKbxlKSym+z9AhQACCCDQqgL0cGjVM0+9EUCgaQQan/BvrNi+tnv6faU7
1O3NehyvF1MEEEAAAQQQQAABBJpeQKML2doYgg5W4Yw+y2ojAwIIIIAAAirAvwj8GiCAAAIIIIAA
AggggAACCCCAAAII7FPAXptk/RhstHkbbOrzYQU/EEAAAQRaWoAeDi19+qk8AggggAACCCCAAAII
IIAAAgggsH8CFmiIoqpkdPQnWLPZvMQ6Wo/offWK3r+jkAoBBBBAYDILEHCYzGePsiOAAAIIIIAA
AggggAACCCCAAAJHSCAdQLD5WPs2xG3dEpf3SLlSkaio8xZwyOS02wPfcDhCp4FsEUAAgUklQMBh
Up0uCosAAggggAACCCCAAAIIIIAAAggcHYHYvghdG0LAob1bti6/UmSgVz/hUBUpdEg8dYFkO3v0
Mw5JLwdPzxQBBBBAoDUFCDi05nmn1ggggAACCCCAAAIIIIAAAggggMCYAukeDtlsViINKlS7Zkmc
79RXK1UkU2iTXL5DMrkiPRzGlGQjAggg0DoCBBxa51xTUwQQQAABBBBAAAEEEEAAAQQQQOCABCzQ
YEM+r69OauuUgXmnSlVfp1St6ncccjnp6p6ugYeCBh501GULUqQDFQd0MBIjgAACCEx6AQIOk/4U
UgEEEEAAAQQQQAABBBBAAAEEEEDgyApY4CGnQQd7jVImF0k20tHWFYoh8GDzBBqO7DkgdwQQQGAy
CBBwmAxniTIigAACCCCAAAIIIIAAAggggAACR1HAgwceSGhra5OC9mSw9ZEGG+z7DjZv66xng6ez
KQMCCCCAQOsKEHBo3XNPzRFAAAEEEEAAAQQQQAABBBBAAIH9EvBAQni1kgYbLOhgAQdb9mCDByn2
K0MSIYAAAgg0pQABh6Y8rVQKAQQQQAABBBBAAAEEEEAAAQQQOHQBDzRYTtarwXoz2NQGCzD4aIEH
Xxdm+IEAAggg0JICBBxa8rRTaQQQQAABBBBAAAEEEEAAAQQQQGD/BTyw4K9S8j3TAQlfxxQBBBBA
oHUFCDi07rmn5ggggAACCCCAAAIIIIAAAggggMCYAv6aJOvZYMNoAQZPN2ZmbEQAAQQQaHoBAg5N
f4qpIALNLxDZ+0PDO0Tto2XWrTfp3tv8NaeGCBx+gSiKQxd5m9rIgAACCCCAAAIIIIAAAggggAAC
COyvAAGH/ZUiHQIITEgBaxDdU7IG0kgKhUrytE0m+XjZhCwwhUJgAguEd/GG4F0klUok/ZUk6JDN
aiSPAQEEEEAAAQQQQAABFaAnA78GCCCAAAJjCRBwGEuHbQggMHEF9MHrXK0RdLCkAQb9n7aN6sVv
JNlaV9+JW/jWKpk1Yuv/pVyN9Ctztbpr+3Uhl631SKExeyL9RkTVaujhUNXzFf629PSEPzU/dxOp
sJQFAQQQQAABBBBA4OgLRJXaMWvX8dnkVUtHvyAcEQEEEEBgIgoQcJiIZ4UyIYDAPgWyWZEp7XkZ
LEfy4qu7Q8Ahr4EGf9rGp/vMiARHXKCqvVDsafmN2/dIxYIOOliwaP6MLsnns6Exm/N1xE/Dfh0g
9HDQlDatVDTwoP9rL+alrWDBoeRVS/uVEYkQQAABBBBAAAEEmk9Ae5VLpNeIfdvCVDJ6U6bBhkzn
9DANy81Xa2qEAAIIIHCAAgQcDhCM5AggMDEErIG6Pa/9GvSp60qsjaGhWMkj2KN9xGxilLy1SuEN
2JE2XJfLFSnVAg5F7d1Q1RuWfKznUIMP9u0NhvEXsL+rKLKgUKyvJ8voz4wUspG02d8aJ2n8TxAl
QAABBBBAAAEExlEg1mCDVEoiuzbqdFC7l2uTUr4ocbFTp22S0Wt8BgQQQAABBAg48DuAAAKTTsAa
Pq3B+tjZHclHbWsNoR5ooGF0YpxSa7gOr1Iql2WP3o9sDQ9CJT0citqYvXRGXjrbcvpqpXxo3Pbz
NzFK37qlqAeJQuBBQw86teCD/c3xt9W6vxfUHAEEEEAAAQRaVyBc11uwYWCXyM4Nkr3+jyTTu1lB
9AGV7jkSvfXzIj3zRdp79GGiXPJdvdblouYIIIBAywsQcGj5XwEAEJh8AtboGRpA9XU8NlgDabIu
WaZRdGKcU2uvto96ZyUn9lolbbm2W5JQOJsWc0kjtr2ux84nAYeJcd6GAg7+t5VcKtg54m9rYpwj
SoEAAggggAACCIyHQFzVbzdYD4feLdrLYVO9CJGt0230b6iTMIMAAgi0tAABh5Y+/VQegcklkG7s
9HkPNlhNqvqxW1vv2yZX7ZqntEMN1lEIOJRKJRkYKIXvN5T1uwA25LXxenBwUPL6kW+bj/XVSr4f
5298fxfsPPjflZ2L9LyVjL+x8T0/HB0BBBBAAAEEEDhaAn59bvdZFmwoDwxoL4cB6bRuzLXB0lT1
e22iY1TRoIN+P9qv533qaZkigAACCLSGAAGH1jjP1BKBphFIX7Tm9CPRdoGbvHN+6MK2aSrbJBXx
GxWb+ryfM6tiso6POEyk0934d5ZeTs9PpDJTFgQQQAABBBBAAIEjI2DX6+H6PenCnDyQkjpUuJ7X
NLqhfr2f2swsAggggECLCRBwaLETTnURmMwC3tCZz+eTi9za09feiD2Z69ZMZffzUdEnnPSlSuFV
SeF1SbWbEKurhRfsfNpogaOcfh/AzmvYpusYJo5A+jz5/MQpHSVBAAEEEEAAAQQQOFICfl1vUws4
lMvaw0HHdruuTw17tOeydl+Wzs4k4OD72bUjAwIIIIBA6wkQcGi9c06NEWgKgfTFqzVm+0VtU1Su
SSoxUuN0+rx5NT2db/Opb2c6fgJ2Lvxvi/MyfueBIyOAAAIIIIAAAuMlMHQtqG9N0geKMuE1tkOl
Cdutc4N+s83T2pRrxyEj5hBAAIFWEyDg0GpnnPoiMIkF/KLVPy5cKBRCbdIXtpO4ek1TdD8fVqGM
fqPBejBks/p9Df1WQ+jaYOt1PqsveM3l8qFnAz0cJt7p97+30aYTr8SUCAEEEEAAAQQQQOBICFjv
BvuOg0Ycwpi+3rfjVeNIgw02DgUdjkQ5yBMBBBBAYHIIEHCYHOeJUiKAwBgC3iA6RhI2jYOAnZf0
2FiE9DaftzQ2zzD+ApyH8T8HlAABBBBAAAEEEJhIAhZU0K4Mw4qUfrtSen5YIhYQQAABBFpKgIBD
S51uKotAcwh4Q6hPm6NWzVMLf+Ipmfo3GqyXQzaMVlObT77dYL0ckm842NQGzmtg4AcCCCCAAAII
IIAAAhNCwK7rrZeDBxz8et8LF8X2Gs7kVZy2za7nuaZ3HaYIIIBA6wkQcGi9c06NEUAAAQQQQAAB
BBBAAAEEEEAAgf0WsD7IIdBgAYXUXhZYsD4P9hlpggwpGGYRQACBFhbItnDdqToCCCCAAAIIIIAA
AggggAACCCCAwP4IRPodBxv3GqxpKUvPhr1cWIEAAgi0pgABh9Y879QaAQQQQAABBBBAAAEEEEAA
AQQQOCQB69ngQ3re1zFFAAEEEGg9AQIOrXfOqTECCCCAAAIIIIAAAggggAACCCCwXwL2KqXkdUp7
fzTaMoizuTDuV2YkQgABBBBoegG+4dD0p5gKIoAAAggggAACCCCAAAIIIIAAAgcvkHwM2r7TUPuW
Qyqr8O0G28CAAAIIIICAChBw4NcAAQQQQAABBBBAAAEEEEAAAQQQQGBUgfDR6Eh7OOjYGFqI4oz2
gGhcO2pWbEAAAQQQaHIBXqnU5CeY6iGAAAIIIIAAAggggAACCCCAAAKHJBAiDvqVBn29UjriEHo3
1DJOzx/SsdgZAQQQQGBSCxBwmNSnj8IjgAACCCCAAAIIIIAAAggggAACR0EgqmoPBx19yGiTko21
wQIOBB1cgykCCCDQugJD/zK0rgE1RwABBBBAAAEEEEAAAQQQQAABBBAYS8B6N9jIgAACCCCAwBgC
fMNhDBw2IYAAAggggAACCCCAAAIIIIAAAi0voIGGTE57MOjoQYc4mxMbQ68GPhrd8r8iACCAAAIu
QA8Hl2CKAAIIIIAAAggggAACCCCAAAIIIDCyQKqHQywagKj9z+YZEEAAAQQQcAECDi7BFAEEEEAA
AQQQQAABBBBAAAEEEEAgCMQaYEiP4fsN9W84ZEKYIQk12BelGRBAAAEEEEgECDjwm4AAAggggAAC
CCCAAAIIIIAAAgggMLZAqoeDhRgs2GAj4Yax2diKAAIItJoAAYdWO+PUFwEEEEAAAQQQQAABBBBA
AAEEEDhQgVTAwXaNM9kwHmg2pEcAAQQQaG4BAg7NfX6pHQIIIIAAAggggAACCCCAAAIIIHBoAhZs
sK4MoWtD8iIl7+FwaBmzNwIIIIBAswnkm61C1AcBBBBAAAEEEEAAAQQQQAABBBBA4PAKZKJIbLTB
gg25bE5ExyT8EFbzAwEEEEAAAaGHA78ECCCAAAIIIIAAAggggAACCCCAAAKjC2RSX2rweZv6/Oh7
sgUBBBBAoMUE6OHQYiec6iKAAAIIIIAAAggggAACCCCAAAL7KxDr65TiOJK4WhaxsdanIYpisTFD
4GF/KUmHAAIItIQAPRxa4jRTSQQQQAABBBBAAAEEEEAAAQQQQOAgBdLvTdJ5CzLYKhtDwOEgs2U3
BBBAAIHmEyDg0HznlBohgAACCCCAAAIIIIAAAggggAACh1Vgr44MGf2Gg40MCCCAAAIIpAQIOKQw
mEUAAQQQQAABBBBAAAEEEEAAAQQQGEFAX62k71YKG2qTveZH2ItVCCCAAAItJkDAocVOONVFAAEE
EEAAAQQQQAABBBBAAAEEDlhAv+MgNtpg34vO5cJo8wwIIIAAAgi4AAEHl2CKAAIIIIAAAggggAAC
CCCAAAIIIDCyQKqHg328wb7dEL7fkHR6GHkf1iKAAAIItJxAvuVqTIURQAABBBBAAAEEEEAAAQQQ
QAABBPZLIK4FGmKx3g1R6NBggYZSFEtVx2w2K7F94IEBAQQQQAABFSDgwK8BAggggAACCCCAAAII
IIAAAggggMCoAtaJIZMrSCZflHKxW7IadojauiUqTtFggy6lAg7p+VEzZAMCCCCAQNMKEHBo2lNL
xRBAAAEEEEAAAQQQQAABBBBAAIFDE7AAQiZfkPKUBRLlpsjACT8ncXlQcm3tIm0acCh2STYVcLAe
EQQdDs2cvRFAAIHJLEDAYTKfPcqOAAIIIIAAAggggAACCCCAAAIIHHEBfWVSsV2/GV2Vaucsiasl
iQodkil2SF4/Hm2vVfKBYINLMEUAAQRaU4CAQ2ued2qNAAIIIIAAAggggAACCCCAAAIIjCrggYN8
Pp98ILpjur6Ye4qUFnRq4MG+55CRnG5rb+sSS5NrCDyMmjEbEEAAAQSaWoCAQ1OfXiqHAAIIIIAA
AggggAACCCCAAAIIHLxAeKWSvjIpq69Vytn3GsoVEX1tkvVqCCOBhoPHZU8EEECgCQUIODThSaVK
CCCAAAIIIIAAAggggAACCCCAwKEI1AMNGliw+Y6ODom0Z4P1ZrDvNFiwwdfbfL0nROp7DodyfPZF
AAEEEJicAgQcJud5o9QIIIAAAggggAACCCCAAAIIIIDAERewoIIN9sokmy8UCiHgYPM2ek+HI14Q
DoAAAgggMCkECDhMitNEIRFAAAEEEEAAAQQQQAABBBBAAIGjJ+CBBuu5YIMtW8+GYrEYlm3e1lkg
wgYLPDAggAACCCBAwIHfAQQQQAABBBBAAAEEEEAAAQQQQACBMQUsuGCjvVbJBg8w2DoGBBBAAAEE
XICAg0swRQABBBBAAAEEEEAAAQQQQAABBBAYJuABBe/J4FNP5Nt9mSkCCCCAQGsL0N+ttc8/tUcA
AQQQQAABBBBAAAEEEEAAAQQQQAABBBBA4LAI0MPhsDCSCQIIIIAAAggggAACCCCAAAIIINC8AvRk
aN5zS80QQACBwylAwOFwapIXAggggAACCCCAAAIIIIAAAggg0IwCcfLthjiqhtplMrWXZmSTj0Y3
Y5WpEwIIIIDAgQsQcDhwM/ZAAAEEEEAAAQQQQAABBBBAAAEEWkIgjmMRG8t7RKKKyECfLkcSF4r6
5WhtVmrv0WkufFC6JUCoJAIIIIDAmAIEHMbkYSMCCCCAAAIIIIAAAggggAACCCDQ4gLWu6GkAYfK
oMjOjRp40F4O7VNE8m0iRZ3Sy6HFf0GoPgIIIDAkQMBhyII5BBBAAAEEEEAAAQQQQAABBBBAAAEV
CD0bdBpF2pthcI9kn39Qgw0bRH7yTe3t0C8y61iRnvlSufjTkpkyS/L5pImJbz3w64MAAgi0tgAB
h9Y+/9QeAQQQQAABBBBAAAEEEEAAAQQQGFUgeaVSJJEGHWRgt+R3b9HeDv1S7dBXKRXaLSJRD06M
mgkbEEAAAQRaRoCAQ8ucaiqKAAIIIIAAAggggAACCCCAAAII7J+ABRpsrFarElf02w3lQclUSpLT
dRnNIrLtGmyo2DYds9ls+I5DLsdHpPdPmFQIIIBAcwoQcGjO80qtEEAAAQQQQAABBBBAAAEEEEAA
gUMWsKCDvVYpo6P3ZrCAg35GOoy2zdYzIIAAAgggYAIEHPg9QAABBBBAAAEEEEAAAQQQQAABBBAY
JuA9HMrlskSlkmTLJcnoWLSeDZoy1u9GR5VYytq7IaOj9YSwXg422sC3HAIDPxBAAIGWEyDg0HKn
nAojgAACCCCAAAIIIIAAAggggAAC+ycQAg8aYog0oJDRMbxPSXdN93AIvR/2LztSIYAAAgg0uQAB
hyY/wVQPAQQQQAABBBBAAAEEEEAAAQQQOFABf5WS7RdHGl7Qng7Wk8HmwzccdL29SMl6NlggwntE
WHoGBBBAAIHWFUj6ubVu/ak5AggggAACCCCAAAIIIIAAAggggMAoAhZIsP4MHlDIWLQh9G/Qn7Vt
YU2YtzkGBBBAAIFWFqCHQyuffeqOAAIIIIAAAggggAACCCCAAAIIjCHggYYo1t4NOiZDRkMOuWQM
8Qj7wYAAAggggIAIPRz4LUAAAQQQQAABBBBAAAEEEEAAAQQQGFvAejDUejEkn41Okqfnx86ArQgg
gAACrSBAwKEVzjJ1RAABBBBAAAEEEEAAAQQQQAABBA5CwHs4WANSuhEpo+9WspEBAQQQQACBtED6
34r0euYRQAABBBBAAAEEEEAAAQQQQAABBBAI32qw0IKN4bsN9gYlCzbYyNuU+A1BAAEEEEgJ8A2H
FAazCCCAAAIIIIAAAggggAACCCCAQCsLJB+CTgILPm+BBvuGg+ho8/Yj1mCDjZksPR1a+feFuiOA
AAKNAvRwaBRhGQEEEEAAAQQQQAABBBBAAAEEEEBgSMACC7qUBBts3j4anXRuSLYMJWUOAQQQQKC1
BQg4tPb5p/YIIIAAAggggAACCCCAAAIIIIDA2AL2segoSkadD29UkpyGHXK8UWlsObYigAACLSdA
wKHlTjkVRgABBBBAAAEEEEAAAQQQQAABBA5AIHyrQcMMFniweR0s6GAjAwIIIIAAAmkBAg5pDeYR
QAABBBBAAAEEEEAAAQQQQAABBOoC9h2HSHs36KcawujfdZCcNinZyIAAAggggEBKgH8ZUhjMIoAA
AggggAACCCCAAAIIIIAAAggMF7A+DRZosDHp32AdHTKSzQ41K9kyAwIIIIAAAnkIEEAAAQQQQAAB
BBBAAAEEEEAAAQQQGEsgjqpiow0WXKjqbLWiAQh/xZK9bokBAQQQQKDlBYZC0S1PAQACCCCAAAII
IIAAAggggAACCCCAwL4ELLTgPRw8zOCBh33ty3YEEEAAgeYWoIdDc59faocAAggggAACCCCAAAII
IIAAAggcskBGPxFtow/hdUqpVyr5eqYIIIAAAq0tQA+H1j7/1B4BBBBAAAEEEEAAAQQQQAABBBAY
U8C/3eDfcrC4g4UeQvhhKAYxZh5sRAABBBBoDQECDq1xnqklAggggAACCCCAAAIIIIAAAgggcFAC
yeegI903Sj4arSviXC6M9a9IH1TO7IQAAggg0GwCBBya7YxSHwQQQAABBBBAAAEEEEAAAQQQQOBw
CiRdGzTKoN0ZdD6j//MeDjbPgAACCCCAgAsQcHAJpggggAACCCCAAAIIIIAAAggggAACwwTsdUrh
lUqR9m7Q0QYLNmR01kb9enT4gLStZ0AAAQQQQICAA78DCCCAAAIIIIAAAggggAACCCCAAAL7EPA+
DbVkGmiwYAMDAggggAACaQECDmkN5hFAAAEEEEAAAQQQQAABBBBAAAEEhglYWMHDDR5iiLP6DQcd
GRBAAAEEEEgL5NMLzE8Agepuidc/L7J9hxamKNLdI5kFy0W6OFUT4OxQBAQQQAABBBBAAAEEEEAA
AQRaTiC8UklrHQIP9h0HBgQQQAABBEYRoBV7FJijvdr+8ZYHviTRl78wwqFPkMyff1cyM4ZOVybS
f+Z5kGAEK1YhgAACCCCAAAIIIIAAAggggMBhF4ir2s1Bx/pgL80YenFGhm851GWYQQABBFpZYOhf
hlZWmAh1f+zvRgk2WOHWiLzcG0oZ3/aHEn18uVQ/eaxUP/0rEu+aCIWnDAgggAACCCCAAAIIIIAA
Aggg0DIC9u2G+juW/CVLLVN7KooAAgggMIYAAYcxcI7GpiiKJIo2SfWf/7rhcMdJfOxF9XWRzlUq
OyS++d/r62TgRonWbdP9bSsDAggggAACCCCAAAIIIIAAAgggcHgF7I0M4a0MkfZusLE2xBZzINbg
HEwRQAABBGoCQ+/ogWT8BNbdLpmB1OHb3iuDv/e7Uu3UtyblypLdMSiZmV2SifskbkvemVhPPdnO
4KtrJH7sCYnLWo8ZJ0vmzBPqVWEGAQQQQAABBBBAAAEEEEAAAQQmnoDFFTzwkMzrCuvl4D0dJl6R
KRECCCCAwDgJTLbm6nFiOvyH9V4J5XJZ4v4dUkgdovyzV8kuDS6I/j+bzUq2WJDioAYd9B/y4nSR
/OahxFE+L3GlInmd2mDpJ+IQnobQgsU3/brEP9RXRNm86Lcp/upGyXTZNQqPRQQUfiCAAAIIIIAA
AggggAACCCAwwQTsnj6bzYQx3N/rPXwml09Gm+eefoKdMYqDAAIIjJ8AAYfxs0+6JNrxt6QiCLpY
ndKhr0+qDPsH2wIUmUxWBj9yt1ReWC/ZknZjnLZUMgvbtOeDvThxkgzFeVrQJOAgMmWSFJpiIoAA
AggggAACCCCAAAIIINDCAvpwY5TVVy7k2qXS1qNPDepyvl2inK6boA8+tvDZouoIIIDAuAoQcBgn
fgsg2FMBpVJJsusfSfVwmCH9uYrs2bMnBBza29vrvRbsiYE41lM299iwzZbbTFGavgAAQABJREFU
tIdE6AWh/8Dbsj9V4NNxql79sN6zoVpN3vMYVSPJDW3V1z9WtIeG9tqo9dCYKOWuF5EZBBBAAAEE
EEAAAQQQQAABBFpYwNoc4kKH7F54jkQDvZKdcWL4XnRm+iLJtndLId9Wb7doYSaqjgACCCBQE5h8
AYfB3SKD+gGAXIdIV/vBnciqfjChr7+2r77MyPLRroCHPHjZLHzQpU/vD7Wsj5i1NcbbWM3pxxrq
w1IZnKZPCmhAIvyjXkvjaT1Z43ZfP+p0UOusvSa0aV9Egxj7Ktuo+RzkBi+/VmfYEGX0g9cH+5Up
9z6U34VhpTmIBS+D7Tqe5TiIorMLAodTwP7GK/bnrH/jFQ0khgBoFOt/yxr+6P2gqbeoRbZTVffX
6KPlk88VdH/9r5W+IY4gpIMxRQABBBBAAAEEEEBgfATCNXk2J3H7VIkyObEHCsP1vi5LW5dk7dVK
dgHPgAACCCCAgAochlb2I+tojU+y+XGJb/6mxA/9u0j648oyV2TFWyTzxvdK5tTloSCj/SMXV16V
+O5vSXz7f4ls8lf6pMo+90rJnP9O+f/Z+w4Auaqq/9/0me276YUkhF6jiIBYQCyIIiIWUFHRzwI2
ig35RAU/pVgQ26cCIir+UbDAp1IEESmigkY6JKSShPTtO/39z+++OTNvJrvJJtnNzm7OTd7e9245
99zfLe/NOffcG3rlK+WFuaWQy/Gx5g4UL/uSCOwlX8tbEf7seSJkFgHZP34B7zc/ADrXBgjK7Qs+
h9Dbz5DDkSsvX0dHooqP34Dwjb9DsiGByPK/BfL9C1OuuwCT46KtoMWCvNSdX0qh+d1j44uRfv/7
UIxTyFct1HPPfSvkzISfw/vrNTW4Se5px7h6BgoWRU4fQm/4GkJHzBmxjwVnyfGvqxG65QGEmjyE
ltwXKPJfiFz+QXcQdlHMMZ1LHI7wuR+tKERqMb9AMO97GsX/PRdYHGjHpLTdxZcjJN87zq35vbTV
V6Wt2uRRLELO+zpCU5ND1CuP4q8/Jzg9Juk7gZmfQOTsd5QIVXsO18wa6Y//D979N23Z5sn9gJd8
AKETThJeKu1eTcWeDIGJhQDHRU60Dc9t6EM6m0dXX06UBmHsPaMBMfGpdKido7gkimGME10DMvKj
ZfGqXlFWFNHSGEMiFsGcKU2yWsq33ppYiFltDAFDwBAwBAwBQ8AQMAQMgfpHwCkVRC4RiYiyIZ6E
1zrLnSGZbZrlmI8nZEeGmCwWisbdgkmmG0omU/+1NQ4NAUPAEDAERgqB+lc43PVVeDeKwHxQJwL+
xdfA4zXtPIS/IILqwWq0VITPl35iUArlwLW3wvsdLznI+JPXI7RvRzmqfNO5QgT3UiaVHp1L4G18
Frj6tfAkeFC38BJ4C38MfPYOhOY3l5M4wdtjv0NovQjcy6GVm0jXwsrDVu/WI5zxFQ5bJFv0GxS/
8ektgssBa+8p3wZvvE0DGPF1CYvuRGjdw6I4CpZUul9/X015/fDSH3UHSbsUtZiv/Ae8rwyiDEj/
WhRJXxBFUOlciM7nS21FJZAoJjZ+GRCFw+CuB/iH5Ge7urb9Kby+d1R4CGZ68gYUr/zvYEj1fVrK
uvvT8OTCh6RuL5pZHW9PhsAERYAqz3QmjwG5+sQKjdYJmVzKKRU8T0wfhnBFicvlRWEhWofedEYU
Dh7izCwEneXDEPks2BAwBAwBQ8AQMAQMAUPAEDAERh8BVTq4rZypdIgUEBYrB7pIQrZSEiUDFQ2M
N2cIGAKGgCFgCBCBwcTzdYEMV8bjrs/Au0ksEobj1n4TxT8fj/Br9q5KXXz6OuCKi6vCtv7wNLxv
HI7CeQsR2qeprJ13/ISDQjNRTnzh1q2TcrFr4V32cRS/9WNnUUBlg7+qt2dQZcMwCAaSNMlOULKK
XlYQ60eAU2Zsul/qMIiyofUwkQD+yxeqB6hU3W7udeaR4c6H4F3/BznXeSghfVWu6ocsrQTE4uCN
R7jDr1Hs3o6O1u3OdUDBV3t4IfmYKVMXzL8yNOZyKoZsy+KfFVGdT2SXPDOjtE1VmZzcOLykJWgl
UlG0NMmqa6Ej//WjyaV78mp43740mN2/b91HSu5CqKtao+L96GUofORvYn0zpUxny8wWYgiMXwT8
8cNhV0AuV8D6nrQoDXLo6+eWSjJ+Qp1IiaXC9NbollsrSTzz0zJi9ZpODGQL2NCVdunSQqspGRML
hwanuOAPGDpbLTV++4pxbggYAoaAIWAIGAKGgCEwfhDQ727d5jkej8t3un8OpfuGl7Mk6RjOtPSZ
VuUSmn/81Ng4NQQMAUPAEBhJBOpW4YBNf9lS2dB6KnJnnInC7DaE+jcg/MSfEb35EoS4Kp1uzQb5
E1A4ZGSLnC2UDYehcNonkdtfhMQNUYR7nkfk4d8i+serHInyn29+Dfjfi8qPKlirCKXLUe7Ge9nX
kD/mJSiGNyFy93cRve+OQIK/wrtXrCFeNb+02lf2Kj/+WyjMW450IYf4XWejoSyrbkP3qz6FbGtK
tiSJIBqTF3jYPwzai8je5n++EIkVrOdQTs5puPEz1ZH7fwmZd52EotRXdlcX3H6F+DWXBgTsspL4
g79FsSmE8HTBT4SAWPtP4AnZwmpH3cI2eCe+2OUuvuYK9M9+DoWYnEtx1+fRuGpTiWoH0id+Cdnm
MOJcGSEKnUhyNpCSrZe4XFocWRnKeYddgKJYooQW3YHwwwPwWsTMUz6C+HHDbVoqigqfgrZhkJ4f
tmUhLjwYLH1pC2XD/hcg+7Y3o9heUspsfgbx689CeEm5MYHvf7eqHwXLtntDYKIgwPFCawSOOaoG
ctzTVdRw6ayMSbFgKBbpy3imUrDkmIdhHKv9YhGRydHSoSB0RFEhESG5SNMfo5rLfEPAEDAEDAFD
wBAwBAwBQ8AQ2JUIqPKAflQWPFLxoGFUMqiigTxp+K7kz8oyBAwBQ8AQqD8E6k7h4CwJBKfCby+v
FhjP+AS6Pvou5OTlhoG0iK0aETroJMRecDwSt1yA5N8eQHHOVBRE015+yd36jWoaeCt6LvwUMjEK
seTshX5JGxXlxVHvR3TPuWj73ucDLXQ9ivf+F7yjZY9CCr5YrgjD5DjoGrcX0h++Gn2z/a1DgCnA
ay9CIpJD8z13V9Le+1dRSMxxz6SVi01Hfv/J6OrqQmLeYaJwEMsD5+aga+7+SLc2OLNEXTHAlzhd
Ys78KoWDL7SrCOVyvf9GZOHaijIh8T50nX6C4JaB15t2K5Ex6w2InLoeU355jaPJP96yPPpFIRIX
bMJyuHRh0LqWkw/jpoC8tEWOtJKz0LN3i6yAFrynzwkoHPZA57y9MZCKoqlJrDVEwZIQxUMok3H3
LKSQzaFhkNKyp96MnoOnubYOHfIKxE7lIbNiDZH1BZpeLl9lVVGUQ2yLJeuHcv8Qunnhz/OEL8lW
GQwiIGV4ycqCxRfv/N8qixRvwdfQdeqxfv6eHr/PxWYi/P4b0XjVW5BYrkoh6Uf//hjwQukX4rQd
3YP9MQTGOQKqDOCcJic1YIqcW5ISxeLmHs8pENaJxQLPYmhJUlXrn9dQyeOhZyAr4SE835mR9DJn
yNZK8WgI01rjaErJKimhSdqaJzh2xzl0xr4hYAgYAoaAIWAIGAKGgCFQ9wjo93dMzmmg09+z+n2u
z2qRrM91XzFj0BAwBAwBQ2BUEajIWEe1mO0j7qX/hdBDzwQyLUDfu9+BrAiMuXUHHV98vHK5BApv
uALF14nQuKkFMVEO+G4lwrf9tXTve+mPnIt0lFvryCGlJTqMIR1v6nHoOv4EtN5e2bIndOddKBx1
usvshF5ymGm1wmE++j/2E/RNkdW7JXpKt/DyM9AgCgd/IxAhkel2q++lMEeP6Xi5F3VOeWbUAIoi
eGM4y2QavrR5TxevSisiPCeME/5LK4H1xe8Sy5/8iW9yuFGwTqdl5vc6DllcA9lJyLlQ12YnPOeK
BdKITH8lCseJdYVYWNCVYXVPW/4pVUsipH45ESJOe6lbyxysp+Otiv9+SSt1jPtYsB20vq5NHAZB
bPxy86+8Dp0HTGZlyv2AGPEq15/LpAOO7UMM9UOIUZrW+VXJSwomT3FfgvDvbw9QezV63/gyp0Bh
Xl7aPtFoDD0nfwKJK79QTh96eCG8F7za8VoOtBtDYIIgoOOI1aGyIMED7zlh8GyGAhWlBWRFAcgg
32LBrzifqWTg3JGVeYBnNzCPHEknSoqwHDbtz81MzTI4J5gzBAwBQ8AQMAQMAUPAEDAEDIGxQ0AV
CvobwL7Rx64trGRDwBAwBOoZgbpROOgLi6vgvSX/qBbszz4J670eFGXVrKbji40XNe3upZdMygHK
GRfGcG/RXShtdOPj3/5xbGxJI93t7zVY2yiO3j6vQpMoHMpKgnV/gdd9GgqyxD4jtD3Z9iNIM33C
V/B8UoTmcuaw8qV+ONyMxjY5AkGOM3Cu668odr4fOaHFNCqIJ92oKDIqToTXIhxnOIXjSo/xvI/I
gawVR0E9rREkXNKyDjkR7JF/Fc1l4iH09fW58pifgnG//CLaRXsSL8Hh5dIYGBhwpEkrnJgLHD/X
pWV6VVjwPuhYZtCxPRyWDJc6BOvJto1VKQJk/3ZJk4lGXDsyLfOyPXnPsrIDGTQFC5jycTz3QrFk
KVkVaPszreblfaEmXzGXQTabLadhWqYjzoVCGnFpgooySVZaM1yEnlTAhNb+G4kAD8UFJ2FTrg+e
WFOoooG06Fzd44egUc4cT+nOUYsekzY6lpGunpqOvjlDYCIg4MafqBibE7INHH2ZKHnuc/eAbJUk
OuLnNvpzd8GNf3+s5GUuem6DHFIv4yItlkySDc2pCMSwQeiEkJJLRqkbpxMBI6uDIWAIGAKGgCFg
CBgChoAhMN4Q4Lc6Xa1fWw+Nrw23Z0PAEDAEDIHdE4G6UTgQfhXayqYaVa2RXnCArH71LRucYEte
evpC43PwogCYcZ6XqaKRO+hgt9JfywhGKk3E90S6EWjs09heZ0EgJH1BfZWwXBbnJ6JOMO6XVxE4
k16hkETf3ANE4fCkEisJ+31BdzlwiBvSUGE2k1AAT8cVwhUndRfmikWeWeArLYpZrhCuuNjq9SjM
nF3GiOnc1b8MiSrdS0UZwXjF199yqBJXi5+mY4m8Z3r6FNTTkRbz6OUCy3+CdfEDNZ363N896HqP
fpkIMH2rj2DZTM/nYHnBfNwYnmmCLvjso6exiqvPf2jzRo1wfkiwS62kQqUCoCPNP+x7kQFRfgWy
xGOOr5AoUswZAhMRAY49KgrDsjcZr6SYJ3Dsuq3rZFjQkoHDww/zESiKRUNGDoyWrKJk5fiVLeNE
S8G8ERkqvEgzOM4nInZWJ0PAEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEDAEJhICdaNwUEExV8Fj5aIq
jHMxf5sfCp54poGzaJAUfNaV/ZpBBfPeyuUa5Pz09ElOGK4CLN2DUAXqvh/FwCw5Y+CZFaW8YkEg
e4xnBSWujhcCVTS9LC0HxLJChGJBATsTsR75UNAeQrYMka2GPM9XppB3XswXqRJEi+BOLAyStNiQ
cNaPjmkdRu5J/4hiQ3iiLsLhJsFZEdzxzAO10ojfcy0aD/o8+hv87YaUTtN9PwucWSACv+aUU2qo
ZYH6pMtyFSfeBx3p0Wk7sD7B9tG0io+fWkNFQCn1YxzbgzTUQkLL5VYsQVfMDUhd4+V+wLL0Ii+q
qMiKgDPoink5T0LqwjMiVNFAn/UpiIVJuEoX4bdVNlvCTM77SAWIhRZ9E1Oru2ggdpDbYtbve1I/
4ko+tV0HSW1BhsC4QUDHvzLMfp2QKW5GR1IOgs5jU6/Mn6JU6B2g4lHmGdkyiT6dJ5NBX9rp6NyY
jImGYZbkaxBFbiIu86LQUsdyasvSOPMNAUPAEDAEDAFDwBAwBAwBQ2DXIGDf5LsGZyvFEDAEDIHx
jkDdKBwUSAqAQxuD5zeIQEoO9aVToRN9FUbR13ClQUFyaPNifXR+WLYeomNaCqjp01HYrQJ1iunz
FRmXxIqFQzqLYqOfxqva+oi5K1JqpanCbD5XO3/VPMNYdjBdtRCeq3ordVJBvcNF8lWnlfJLQnMt
qxDZB90vOwLt9/2jFHQ/pn//PPS+4Ux07zEdXtdyNP/9WrQsCWK8HzYdvIeSKPmy1dO69dRkOCuK
iOBHnnn+RZUr4RgOkzdpF7fFlfitM1FoSZXbRttIcVcaESpcpA310nSMV4w0bdDXdMwXVDiUFU4q
1Sxn4mpr/2KQ0taw6uSVdKQXe0KxLBPbvpte2Y5L+nWxhNX2ZbbUhkB9IxAc0/5Y9MRSgdZOsoWY
KBEKogTNleaN4DjjvbPYEj8WEWWyWDdExY9JXiphg3NosIz6RsO4MwQMAUPAEDAEDAFDwBAwBCYw
AsXSgkD9sBfZhXOhWvnHBMbAqmYIGAKGgCGwTQTGXOGggl8K1FXwH5G98YPOK4bdinYKl1OplBNE
URBPIRTzq/C5IjyWles1yoGirOenAKuxsdH5upKeK/dVmO9Wn+uL0zHQgHzMP7/ACbKr4kRxIPS4
Yp680Fd+mLa/v1+EZkH1gFgjiPBebBccZaZnubSciHKz87KTw1Jp3dDQ4ITwaolB3kk3XCO01i2V
HH9Cw1kipKqtEIAn0fSHs6vPQiiXJ8dUv1wO026OiaDPtzRgWaEl16Hlqh8EUm3v7fvRf/nHURDM
SI/1Zft53Cel7ETAGE+INUfUWXSo0oHRWp9y0tJNSHiklUtTU5Ojp5YgKpBMp2XJ9BBO02g0+wvb
gGVVzm/wY4vSL3JykK3jeeY+EvigZkNh7nvQPX8ywgXfGkUa3ilbPFm9zTb26YolAxUw4Rjy+71C
zukoICrpWB7xYBq6Wp7KhdiNITAOEND+y3Gic1Q04qEpKRZLMv1NbomJpUMY67rS4JTM/l/rOCV0
NNKyIYLWVFTObojJnOgrIXWe13Jq89qzIWAIGAKGgCFgCBgChoAhYAiMPgLu92tRdhHok+2GReng
ye4N7ndwQ6usmBSxUlz2WRClg323j35bWAmGgCFgCIwHBMZc4VALkhMAz3kB8PdHylFhebHxxcWL
AigKtnhpmCbkS5DCY/qZPY4QGfFjGoVYb7/kaXH5KBwjHXXM4wuBe5Fas1KDxeeKfv+MhEBg5VZe
qMqLCsZUUD7Ui5a8+WX5AmdfUBdUTEg9pW4M14sF8t65YFI/pPzXfQT0PoQpf3qoHLb1m3b0HHMx
Vh4yA02CLZ3iKrupbz3rtmIT/iEGpKdCdndfk491ZbiWy3q6etSk00fFhukVH2LNZ+ar7ROaj3FB
YefWytA89JmukKo6thq5mS/B+gVzXPmquGK5pE+FB31u38QwKkTYN9qEznDLDJZv94bAeEKA45CO
Fk8R0SSkZGskntsQciueOOfx0knMv3fjRA5oZ1rm8fP6CgzSMmcIGAKGgCFgCBgChoAhYAgYAnWA
gEeFw2ZZ5Si/9TM98lkvMgp+2kdFdhCTTYj1M78OWDUWDAFDwBAwBMYWgYrUfWz5cEJaVRYUGqoF
vA2LFqHnRXOd4Jar24OCZrJNQS4vCnpV4J8PVVctuehpJI6YU7aUIB0Kupie+WgZkO9fi1RXEIgZ
yIUlXLYGoWP6oAtFfMsGCpTVwoH0ePl8BlfzB3P696Tnrqo3M1fNi1KldKYB6Tiht9BkWq/KaqLC
j2IQW3RP+fwG4ChsOPXdCK35F5pXLEJkYEAKlrMaOmajf9YCdO57EDKytD8mQkLWgZcK/kOJ5i0Z
3p6QybPLihPyRksO8k+BYsXJs9QzJmd0UHBfVqpIAt6zXWpdOJZwWKsgX9uR6ZheFQ+1+SCYDu22
jPMVTb6lRShdfR5E7PmV0sazXLuQT9aLTtuAvmtXtlepb6o/NA8WYwiMXwR03Ol4cIo4mVdmthfQ
l4lgfXcGaRkLGQ5p8ek4bGgFwYOiZ07yz25IJcViTOYI0iFNnY9cBvtjCBgChoAhYAgYAoaAIWAI
GAK7FAH+jqWjvITKhvBD1wNdaxBZ9ww8UTQUF5wCtM6At+8rEUo0ue93ptffyLw3ZwgYAoaAIbD7
IbClpHUMMNCXGIum0NiLN1ZxEXrmT0gWX4OCE1j7gigV6DIh7ws9oilINpRfbIWmKVVrabHsd2hI
vxbhlsqKeualYIuOgq3EE3+o3lpnxgKkS4YFLlHNn1BJ2MzyVTBG/ivP1RmC9WQaOuf7t+XEDKu9
NFJi9HZQP/r8kkp4wzx0TZ+Lwox56Ds66Wiq4DuTkXMF5ONBywkK9xjmzXkLei47xSkKmI5KFM1b
KaByp/VXQaEqYDSFluN/rpRDy7XReI2hz7Bax5XSQV61XFVODJaHNOKLlgJ7i+WMONZDHe8jj/8C
zZ0aUvE1XX76fqDKQbtCZOmf0JQ/En2y3ZamYS7es3zyVN0PKu1ZoW53hsDEQiA49jgPcDzE43Iu
jvg8oyEvV1Z+p1RGnyg75byGOK9YxF08u0HnZKITpDmx0LLaGAKGgCFgCBgChoAhYAgYAuMHAfe7
l7Kafvnh3LcJ6FmPkCgcCmmxdEjKThKMk+9+c4aAIWAIGAKGABEILjcfM0RqhUqF6a9Ar2wBWHEP
oPX3D1QJn1SwHQ7Lqva7L0P0/Bcj/n9PupccX3SFSYejt61CAXgcrb+5TVbP+lsVBYXWLD/U9U+0
//7mYAb0HP0Sd6jp0C9Of4snWgaQH734vKWTl6/wRVq8XJksl1dVYnkqCa2Vx6AvUYM6pecFDyPo
vwHzbvgx2p5+BLElTyK6YjHCq55DeMPziPV1I5aXky2EV65G1jqwLNIijxSaU9HA1QzcIogXLRWC
F8MYr2Fq4cEw3qtT/sIFWlmoexLJld2uPA3RdPpc64dKq5/JM68gNso7aRQjVR0I4b/dgHimWkFA
2pHHrkHHr66qLabcTi4itT86pwWT/BMz7v53OY22J8vXPkCFC6+UmJnSGqPSX21fyyCSdj8xENBx
G5xPOD4TMr+kxIJpRnsK09tkezEZv+W0cj+1JYFprQk0yHZKSWfp5Fta6ZykaScGSlYLQ8AQMAQM
AUPAEDAEDAFDYHwhUCsT8PI52QZAznBQ2YZsn8rzM/X3P9MzzpwhYAgYAobA7o3AYJLxXY5I8IXk
37di04tfh6Z7bivzElr4GbRlPofi208GJrXIS04OB17xILzrPgCs9ZN5zf6BzP5TIzYdcyqab/5l
hcbSS5D6Xjdy73wHMGOKH17oRfg/v0XHT75aLfhveC/Wz26Qo6a3vsq2ViDGZzoXXk3RhY/2n8z+
x8n5F4+Xi4ms/Q2m3vqb8vMWN/EDkT34FKRPfCM82UddXfkDQj8kAr6mUZ9pKWyn4wdG0AXbluHZ
GfsBC58oJ0n89ipk534KaM4j9NyjCC8bQPElLynHb3njK2m2DK8OKc58MQbisoGUnGXlu3vQ8u1v
I/fxs+FNbUFo4HlE/ngZWu69QxNsxU9gw1HvwaSbf1pOE33qS9gv81Gse+3rkG6VQ75L9XcKh+7V
aFh0L1ofvBrRvkPQc/4PEW72LTPKBOzGEJjACOh44HkMVDKk5EDoohyqHpVxUpQzefgTJCxzZSoR
RoMcGh+RdHZ2wwTuEFY1Q8AQMAQMAUPAEDAEDIFxjYD7nS+/9emH5KKcxN8ttbKoMmyKhnHdxsa8
IWAIGAIjiUBdKByCFVIB/sALTkXfA7ehURTo6sJPXoLwRZe4x8F05qGN3RI308WTTn7vU7Fp+i/R
8bxSEH/p9xD7yvfE7G8fdy5yuGtRIFJv98f6U09BQYRjcblIq1ZwzpTKq+ZSvxw+hDWCphtJX1cS
5GecjOePfADT//7w8Mhnn0D8X7xuQO6cn6MwJ+HqSnq8uFJBfWLA+6BjXekoYOS9Cho1TS1umT1e
KMLG31ZUMdmb0Xx50LLkMHgvOFLOqtjSGsHRlDIU38F8lu/zMg2bD38pUg/cr6yI2ecNiH31hsrz
kHcVCxRNkp/9JqybewumLq/svRSWvjT9h9KX4nuiMH2eaFM2ILz5UYTkDK2KCyOWEIVEyRojyHMl
jd3tLAK1/Wxn6Vn+HUNA+7fm5hkrYTkHZ0pLHI2iXFjfKWc55GQ+lQRJUXBOaxfrhoRYQSTjzspK
821rHtF05u8aBNiu5kYPAZu/Rg9bo7z7ImDz1ui2vc1bo4uvUd89Eai3eUvHeVAu4MnuBpFCTrZP
8i0c2FJZCWO4bIeAcDRX9U2/e7ak1doQMAQMAUOACNSFwiH4cvWFxRRuTMGKM76J+T85D4mA0mHo
ZjsZudccKsLyoLS3AWvfdh3Cvz0Hbc9trs6aFkWDGEls6Y7G2nd/Gl2tcoBySchC/vSFu2X64YcM
LbIJbjMkiozhkyynJH8+j+vQtKRa2eC1HIqsCPci+QGEeKEHYTnwqdotRuxb34T3zQvdeQWsc/Bi
uwyGgbadtpvmqabtP7m0LYdj8/x2dCypLb86x2BlVacY/ClYfv9Rn0DXM/ejdcPgaTXU2/dCrNz/
ecy55SoNcm1AWuTDpxnF2td/F6E7LsaUZ58pp3M32aWIrFhaHVZ+akQoXtlGyWFQjrObnUGgKG2T
yYlizCnCBlNB7gx1y7sjCOi4zeX8M18yGX9rtVxBtrkTc2vXSjLBqS1VXsJzeU8Oli7I/CQ6YI+H
sMsh8/Ijhs7Gy460wsjnofUJ34cJeY/oe3HkS9k9KMp0haxsN+jmrQKVb/ru3j3qb7U0BHYVAjpv
8awgzls2d+0c8jnZLoXzFndLpa/v+52jarkNAUMgiAC/ezlXReXgQN/XL+ZgqrG7p+LBE4tljz4X
IdYILTgv2Nwwdu1jJRsChoAhUG8I1IXCQV9MfMlyD3CeC8CtadCwLxZ/6FpMvf8GTFp4uy+kmjIH
oQNfDu+e630sW16K/HEfROboBfIBnEU+l3d7+6dSKfT398tLrw2r3nQt+pbdJXSuR6xTDjgSF3rd
mfDuk+2WekuC7/hBGDjiNKw65FBkZHV9Usrv6OhAOp12K+bdCzZSfZg12ppcWcGzCkhb6+MJuqGX
nwbvmb/Ltk8dcq6AfDyUXsT6Qibd5Is/APzrs7IqgMqSlMsfjCcuPA+A5yR4slq+4pJykDYtEWRr
EqkvaYVuPB9N6yspsgd/EU8cfbDDderUqejp6XHpYnL2RYNgMvnXV5SFf0j+EbFVwsceste6tAN5
YNmk6+q/lY8IptP2o/KBe7Dzme1IOgwjDR69vPFN/4vird/C5KcerDCqd7OORT4hwsrSeQteDeae
8DUc5/oP2rHqtJ8h+5drMOWxv2yZLXEUel/9fqzdfw4yS34ViJ+LQqJSH/LNldqFQhvWHn8Zelbe
i5kP/hrJ9csDeWpuW45G4YUnIf/K46Qfi/JK6q8Y1aS0xx1AgH0qLScQP/TsZhFW52XVfE7G/w4Q
siyjgoCbE6WNCqX9XTPpAbGWKqI/nUOB84gILCJyiHSPzNfccimRTJXmC06a/rwxKowZ0e1GgD94
E/LLt1EsUV689ySk5CBwzmXmth8BzltZGQdPPNfl5q1NvRlQiGfOEDAERhYB970l3wS0oDtC5q0G
mbdiMZm7pBibv7YPa85bXBywZnO/m7eeXduLTL5yRtv2UbPUhoAhsC0EEjJXHTCrzX13TWoWC2BZ
9DHW8xbnAV78vvfkCsmPLl7qCpQVSLiIOpzjb2f+9jVnCBgChoAhsHsjEJKXR+VtMQZYaPEUpqtQ
my+olStXlg8j5ku2oUG23hjowfR9D0ZYhO4Da1YjI0LpQuncBn0RU9Dc0tLiXoqrV6/G5s2b3T0F
6KTbFMphUrsITabORKG/Fz1PP41cYwu65GXO8jOZjBOSz58/3x3229fXh87OzvLWQv09mxERQWdD
x2TMmjvX0aQQXwXsugVRd3e3UwJMmjRJlCA5rFmzRlb4FtHU1OTok1/WnQcKU1nQJzRWLZJDnVNc
ER9Ba2urS0e6DQ0NrhzSJB0vIxYRWXnhJ1JINTe4+ClT5EwKWXGQ+9a7EXm6JMhveS8effvrkZey
5syZAyocWL/ly5c7eg6PJ76LSf/3O9nfpAnhs69DMTYf2ckUrgt9/bAo+ewe2l61XYX14UX86VNA
T1/zsFxiw/YgbSqVkOtG20AGMaGfapkEtE1CqK3V5WE807HOhWw/whlJHxesBBdi0tzcXMaHGbTv
DAxQsJl3ihX6VDrRxWX5dGqTWH94wlM0Bq95BrIdLeiV9mU5zBfKphGXTyWvsQFNQp/4qOKlt7fX
lcF+SucOghZrkRbhLZr2+4w0HNDYjEL7ZFmq7StctN/RJx706RQb92B/thsB9kMqGu585Hn0ihCb
XW2ovrndxC3DTiPAHx1sD3deg/jZTNqNn4E0za+lrWTH13BIznZI8uB3mS9kTueYCIf9+SMs84i5
ekHAn8ebpK1edch0NMmZGzZ/7VjbcEwMlBSlvTIWNvX1O8ufSIj9fUw/xXasQpbLEKhjBLJiPUdF
6TEHTpV5S76l5Swhzl02f21fo3HeyomidIkoGnoGcli8tscpHCIOy+2jZakNAUNgaAT4FUDlHhUO
B89pR7PMW7M6kojJwpyxmrf0t5X+LufvYa97LZruvgyRnucR71wuZ0Cm0HnQKSi2zEDkoBNEltHi
ZBv6O3roGluMIWAIGAKGwERHYHjLxXchCt6SRUgevAAzZ87Ec889516w7mNXtk6Zsv8CeH29SP/9
AaRecRz6NmxAjwik+RKmoJuCeSob8o8uBFrbMHOPuc4qgC9HJ+CWekzdYw+kxHJh4LbfI3nca5A6
8GBsEOUGLRlYDmnNmzcPCaGXljSNrzvR1X6DlEXnhUUk3drslA3FNatQXLcWzS883AmsVdlA4Xdj
YyPa29sxcO/diB14CGZIfagsYBwdX8JMQ8uF9B9+h4YTTsKMffZ2aWgFQVp0rE9ooB/Zh/6OlmNe
5fhct072SXQ/nMQ6QhQWVDbkn3wMiMn/j12D4nf/CxClQ88Lj0RGylNlQ99t/4eU0ODzsmXLHC+R
qKw+KCkbsMdBKNz3H+Tb9ndCfZZP4T6dfnC4hyH+6MeQtofmY51ZX16+pYCvcPCizeiVtmB4VpQu
EfmgSoqigfmpBNB8/JApRhIunGm1HGWDzwwnj+SX9/QZTgE/6eSKMeTbZ2OgJPhnnFfqF4xnXi+W
QFEUJexLzEefF+PYTuTJpZNnlyeSRE+LKCba9NwIn4+QbAcTzlRWdpAf0lE86NfWwUXan20iQNzp
nFKpP4t/PrsR/aJ4OGLvDlt5vU30dl0CT7ZGolMLh4JsK0YlRFOSCge/DUOicIjJOKNywY0PN179
+cbGx65rq22V1C/K7X8s3uRWCh+5dztE31Cezzi3mds2Anxv0HHe6hvI4pGVm52idFpTEnGxHmmQ
801su5dt42gpDIHhIpCWbf2eWdMr4yuMfWc1oaOQkPuUs6iz98vwUNR5yy3KEUXpknU96JLvrvXd
WWcpMkPOYKIg1JwhYAiMDAK0eFze6W+z3CS/81sb4pjcJL9HRXGq31tjNX/p71/1i2LBHJKr4jgX
2HxQwcPuDAFDwBAwBIhAXSgc9KOWDIX+eDOyv/0lGi/8KmbNmoUlS5Y44e9ee+0l5w6I4uCMtyGx
dBH6L/k2Jr/+TU4A3NXV5ZQN3AIp/8i/EfnQO1FsbELh2hsxV6wQli5dCiodZs+e7bZJ6r3m+2j8
5lcwcOTLkPrBT1344sWLWTxo2ZASYXX6Y+9D6r67kV75OTR+8GNOwEylAwXPTENlg/fetyDa3YX8
D36G1GFHuNX0/DCnUJ3KhPSdtyHxyTORFcVH7Ke/wYwZM5y1BOuryoaBr34BqeuvQe89d6Lp0m+7
OlMxwQ8KKizCshVJ4QPvQOyx/yD9lSsw9aS3uDqvXSuKDlmFP23aNOSeeBQRSeNFxMT5O1cjXFI6
NMpZA3OOfasrt/u6q9D8tYvQ/4LDkbrqF5gnSpWlSx9Cxz13OMsGKhtw2jEIvexd8F60n8NCP2ro
B9vIRQ7xZ7APomAY7yk0Vr/84SJhg5XDMKZlOvp81oss8D7oNI5p9WI8BT1aFp9r68O0dJonSEfD
mYeCURV6M1xpMizIC+lonKYLxjPM3I4jQGyJeVoUkRlZeSff5TJubeXijiM6sjmleZwrlsZBQSwX
PLEuyuVoku2PNY6HWIyr5WWsitBCWg8R2WubzsaKg6Eu/nDLPgrv2CbBOa0umBtnTCh+aVHi8PyZ
qJxXEpMtHFPubIxxVhlj1xCoZwT4vpFtfzzZ8qNYuvS9VM9s1yNvbt4SDDPyHuCWcAIo5LXt5q2Y
bI1ozhAwBEYGAd9qiN/JspGBjDVe+t0wMiWMHBWOfB39pU9+Rzx4P3KlGSVDwBAwBAyB8YrAmCsc
KDTUlyn9Yksr4t/5IQZEy9/0pUux5557OiE/lQ2Z974VKbGAyEyeguT5n0Cv5J1y4pudQqKtrQ3Z
hQ8j+uHTZVsgWeXeJVv3nPFWp3QgDW7NQwF+94++i+YrL0Fm2gw0/P0+9H7odDT88GdOicBGpLKh
/yNnoPGBvyA7YxaS37oEA8JX84c+7tqYVhSF1c8BVDZs3uQUG5Ez3+2UDg2idKClBLdISv/pVsQ/
dZZYC7QjsXwJskx/3a8dD7S2cJYNJWVDZvpMNP3ht+iRt3TTZd921h1uhb5YNuT+6zTEHv8PcsJv
4r/PQZ+sJpj25lOdUoPbLmUfe0QULKJsEO5CstIbH3gncPUvnNIh9MifnWXFwI++g+ZvX4b05Glo
/Pc/0fe+tyP14xuwX/t0hD54nZzZUFI2PLUCA29rddYgaiFAn25HBYDatmrZQJ9CeyoAVHAfFGSp
4J5pKLRnetcv+APHCShjLr8qBhxzJf4Yz4txtPxgGVQA8WIYHWnRMR0dLRkYxnLoWF+WrXwG6690
yKNurVRLn3mVD96r0/LU13Dzh4eAtpvOF2xbVSJRRj23NYy2FPH2+4nhPDxcRzsVhdV0+bwKq6l4
8EvlEKSygW2lW43pOPVT2N+xQoDjjRfbhovtouKz3fxxV5njdJypP1b81nu5Om/p+8K9S8TSZ0Zb
BFzFOCklViN1sEdzveNo/BkCW0MgOG/1ZEJ4TCzrKBnnN3c2S8vZhFgS+fMa6di8tTU0qxfUcM5y
3+fya2NSQwRJUZLu2SYG0qVFAobn1rG0WENgKASC89ZATr65eiJile9bCOfk29n/bvB/25LGWM9b
yi+3cXZXqWIys8rs4H/zD1VXCx87BNhuQbe9/UjzW74gilvKlapjh34yPAfHZlfjMjgXFjrSCIy5
wkErxA7Gq//NpyG86Ck03Pgz9MvLrPmiy1Ho3FxWNiz6wMfRecChOPgbF6HhAhHAiyCk/Q0nIy2C
9JgoGzwRHK/48hWIitXD7C9/BnkqHX5yE9rnzUfPVb6yoVvyP/Xxz2L6Xbdi7q9/jt4Pv9spHUKy
Crf/o76yYd3b34NNwsseYhXQeOWl6Bchc/OZZyO7cnlZ2bDkMxchPHMW9vjCeVClQ+pFRyL759ud
soFKgsWfvwQNTz2Oed+5FKp0SHZMQvqSLyAplg2dL38VVp51Hqb/+PuY8sffolfq03jplfD6+0TZ
IIqFxx/B+k+cj87DjsQeF30aDV/4FPoEtHZROqQf/Q+iomygW3rh5XIGQT/mX/RJhFTpcPgbULz8
U0he9/9kbybZJ31vUZA0R9H46L/hvfklwK/vBybN8S0bRNnQ9/rT0PuKVyEqPyzUsU229+WieYM+
aaiSgDR1qyP3A6YUxzTBi/kptFcegjSCtIP3wTTMy3IYpgIfTcuwWscwpiefzKv8Mh2fGa8+05Ev
0g06pglewTi7HzkEiLtizzMAIiJEiMpKYW7LRcc2MDf2CKjCISJCH44XWjnQpwuOEx4gTce2NDf2
CPhN5M+bHFvaLsFxN/Zcjj8OiB+FB85JV6esLi59PyY39XAo5PhD1Dg2BCoIVM1bsviA3wPuTPbS
O4fjj+8gc9uHgHt3iyjRvbsFy5B8a4Xl4twVN4XD9oFpqQ2BGgR03uL4ogERf8bkxaJIRJnl3znM
wvh6+W3jeBGeOJv680Llm17YNlcnCLBvZcTSryg3Rfn0lFm8zBn7ErfylF09S77/+5kJmC9LJbPL
R0VSaf6XOMtnuPj9Znz3F08WRFJUlHAW5vZdWJ4YRulmzBUOfFHx8jX4/iDefO5/uxVJrTddj145
pDciWwbRsmHRBz+BdS8SQbm4xz/1JRz09S8h9bmz0bP4aTRc/2Nn2fDshZchO2kqQrKaP/e5r2De
V//bWTp0n/AmNP/0R+g64BA89TFRRESiWPnaNzpaqnSQ5e1oeuAerHnLu7D2TadC5CxYdt7nMefr
F6H5O5ejVywaYn/6A2KbN+KZcy9E7z4HuBXxSz5/GeZ/+bMIi6VD/xlnIvmjbyM7bTqeFWVDWg4R
Tr/oKODj55eVDukXvhiNv/4FukS4v+yD5ziT72Wnf9DhMPUPv0GvTPLRFUuRePJRrD7rk+h86Svd
ytLF538Z86U+VDr0LFuK1C+vc6+OxRd8Fb1Tprn8fZ+8EId8/X+c0qF4zEsRuv2vTtlQPEgsFeTH
gTdTtgSSWoeXbIL3lpeKSUUTQqJs6Dz+LVj5njPQJmVT0M4fZkGB4M585DCvCvC5lRRpq8JBhS8q
3KdlgaZnv1DBPhuK4bQ4UIUAn3kFnaZnXq0DfVokaF9jetLQ/OozXBUK5EN50vSkwzDSCdLjszql
RT6YVukoXU1n/o4hwDbgpfOFtqmGB9uVJdT2jx0r1XLtKAKKP/s/nY53pafh+qzp9dn8XYuAzmW1
40qfddzR51irbb9dy239l6Z4cn7iveLn3hPyUz0vPwSd9U9RFOvyKiOmdDYO6r9tjcP6Q4DjS+cq
+kWRsFDBUBCtA69gHLm3cTZ4GxInOsXLWbblaFXK+Ypzv9iSRvxvbJnayu8Bnb8Gp2qhhoAhMBgC
/D6g0+8D6hoKgW3gaKGVl0/oevrecr+8KSSRy7+XeVZ+jxfl4rZQ5sYeASoLuHXn43JmWJ/sgNHZ
J/2o1NeUOx5OfuCsVjTKGSEdzQm38IVx3D7vyVU9Lt/GnoGSAkxzUUhr+QyX8dtfePYnz6NiP37x
XpPcGYXR0sLHSi+3u5FEYMwVDrWVcT8SZJJc+9FPu4/dtltulB/iYSz+0NnYdMTL5IAif3VgvrkF
T3z6Ihz49S+iWQT8Odm6iMqG9LSZ8v7zP5apEFhCIf2lF6KFyoYDD8XTIvj3YiLULk26q084WV6Y
siXLTT93rKymsuHN7/BfoBJSjMaw/JNfEKXDxWj5+dVyqHACiz75RfTsd5BLQ37TU6djxcXfxByx
dGj4/jeQmTXHKRtyLW3lcrqOeCmWf+JzmPvtS5AQ5QktG1Z95NP8wvBVyVLW8nd/SFYOhTDltpul
ziGsOvM8dB7zGlFIlD5GRHnxzGcuxr6XfwHNV38HOcFg0ee+ivTsufBKZxT0zDsQC8+7CIde+T+I
irIhP6kZ+UMSiOR7ykc5Fea0o5BqlK2alkmpm7DydSdjw+nvcwd66A8MJxAZwY8G/WGnP0hUMaDh
/JDiPePVF+ZcH6BPp+H0eQ3lNJ60lC4VFVo3pUVfP+A0D8OYbzA+lB4/DpUef4gFnebTctUPprH7
nUcg2JZBatqO2g5Mt7W+Esxr9yOPAPHfmmM7BZ21VRCNXXvPtmJ7DDW2yM3W4nYtt+OvtOBYcAqI
4Eqz0nZKNm+Nv3Y1jusDAZ2/VHgX5IpxwXA+27smiNAw7oOf3KV7/d6q9YdBzZIYAoaAIKDzls5J
HEu8D151C5TwKYw69vhXfpm7f1v/6q/b2kwoxth/qLTiIeRdfVmnOOjPyBbTNQoHfoZmRYkcj4rs
JYAA2zDHM0RE8TAgZ47lnalgdQLLZ7hojxhv/YWKuE19GSTEvIfWZFTOcXHKVkSLWlXzdxCBMVc4
6Ee/Cjq0Huy8q0XgTnFuj1gldB/5cvA0Aa4Yp+NkCtmaiAL3eT/4Bla/9yw5c2G2mzCVJtP1i2Jg
yWe/jCm/vwlLPvIpREVhQKdp+CNk/Rvf5gTPYVlFsO6UdzrTMk3DcopiDbHsvAsx57uXYd1rTkSf
8BMTwYzSoN/bPkm2T7oUs3/8PayUcvKtomwQIhQ4kwbTUOmwTBQerQv/iec+dI57USsN1ovpnpN6
cM/ZgXl7YbMoJVQxQn7oQkL3WbHcmPu9r2HVae9DZs68qnK4QqJ//j5Y+PHPYd6tv8PjZ3wExWTK
la9l+ZSAmXffjmRPJ1ZInRtKgVQEqBBe0+2Mr2XWChYVF9J2bSk+06rARfORn6BTOuoH43iv4Xr2
gpbDMvTSPFqG+sH8SqfWr6UX/BHL/KSl9OgrluprnPJg/vYhoG1I3BV7xZl9JZmUPZoDCiPDe/vw
He3UOta1HGsfRaI+/NrxxTOJIrKSVdtJx52mqw+u658LxUvxU4655UtUPnj5/o/JPd9birX6mtZ8
Q8AQGBwBHV/0OcYymQyiOf97jAIVHXeabnAqFlqLgOKlfjCe8xPnq3jcn7/4rFcwnd0bAobA4AgE
xxXnKGfJIFKPUCjjfwfIfCY/XMu/XZm+nlxItr3mpY7brAjj+mj+GCHAvkRlQ6coGrr6c3j8uW5n
sbDn1EY0xH2Ziv99KdviiaIhIZf8dxY2IoVx/a0osqREjILYkDtnrFCsyLykU1o+w2Xc9pekiJH7
RYn2lIwLWjW8YG6rLOxOoKVBznAtyY/GaOhO6GKrpbljWFX9UKVPgaHzRVi/+oNnux8LPLSy1vHl
WxQB/NLzZQshide8wXScePv3PwjL9jvQWT7whch06lgW6VDpoDToq4CY+fnMg6iXnfPf7p6bgwTT
kpb7WJDDn5de8BVHWktQgTXj6XqOerm7mJ8uGM8w8rL6jLN8+hJfm44KhWJTM5aJ5QadWnOQX5ah
9Pr23AePnfUpR09puAylPwxbc9zrfOGs3DMfaTCc95pH/WDenblXesqn4qs0NVzTabj6Q4VrfK3P
9Ly0nNoPNi1P8yl99TVc/Vp6Q6VTukPFKz3zRwYBbRfizkv7suE/MviOFJXa8WftM1LIjgwdtk+w
jXQ8jQx1o1KFgMgOyvOWLDLgnEW8GUbfnCFgCAwPAZ239Dvb5q3h4bajqXTe0rlK5y3OYeYMAUNg
eAjot5b+PqXFvI4tUuB93Tphjdw5DktsUh1SXyqRukVvlzDm+pd80/vn7ISQkvN2eF4YnfazuCx4
4ZkhPD5P+xvzMVVMhLEFSd8oSuXgVkxMZ/kMl/HaX6hcc+fkiAUPz5nMiVw1L5csaefQMDdKCIy5
wkE7rP7A5ko/CtX54qUfjOe9ftDyBc1JkWnUMb7KAkIiuGJAX+pMp4JILY/lMF7T6IezrqzXONKh
4zPL0RX0yp9uraN0NL+Wo/xqOuUjWB/S13J4T6f10XL07AA/1ldYaBzL5soulsWVqVqm8qx51Gc+
0icPPFuBPPOZPsMUC02/M77yqPVVXIaiqekVT02n4fo8lK/0Nb2WO1T62nDNp+H6rHSVL/Vr0w31
rOHmjywCsbistEvIKmFRDLKt2YfZZtpuI1uaUTMEJiYCnM946fuXfiRSWcE2MWs9RrWSX3R8n7j5
KhaVuct//3LO0vfMGHFmxRoC4woBnbfcghz5/qXPect///vf7PYtMHJNKlOUYOv/PonLill+d+lc
ZjiPHM5GaWIjoPMWf6vr7/Wcx8UG9S26d3xzGxLZZifErXZKWgYvLDs6yMU5wOaBXd932S507Evy
IS8KBg+xhhBOOFi20ZZ28k/wrPDF38lh0TQkZfsQuZX2lD1FpP+RjizTxPTmmPwWCGNaipaDFTkZ
v1ktn+EyHvsLvILr1/FQEfGYLPJmT+c3o1xOPiuaCJ271K+MGLvbGQTGXOFA5oONqoJh+gzXF7IK
EPlRy3B9OWsaDa/NR/qkwfRMG6TjJtVSGaq4CMYrbeVB0wfpKH31NY3yoYID0mecphuqHI2nz3KU
jvLCD3vScS8USaN0GKYXy9LyVMHB/LVO68EygpdiWZvenrdEYDBct0xlIaOJQLAN2I+1/zI8GDea
PBhtQ2AiIaDvLa2TjSNFYuR8mZ3KxMJi4aDzlfrlSLsxBAyBYSGg85aNoWHBtVOJ9J1AX7+5FP+d
ImyZDYHdCAGOH/52D44j3vOqb1fSMjgmS/fkue75rm9UR5K7CM8Gk+XcTQnugCHWCu7IUL+t2L8i
YsHAOZvbygQtHMgD47kSPCwWDqGSEoL9lI5bgbp4y1eWuxku9d1ftO+y34ZFmRaRw+65lZjo0ara
0HVw+zMqCIy5woGNT6eCdD5TmM5JkB1EBeZBwTvTM46XKgqYj5em0zQqeNfOpvH6YayKC6UzVLwK
+El3e8phWuUlyK+Wo/GaRuur4ZrOEZE/yq/yw3h1pM/8jKOlA5/VYkLrr2lVUUGfWKRSKYddIuHv
gR+kq3lG0tf6bYvmcNMNRWdn8+9qukOVZ+HDQ4DtzUvHzWi1//C4sVSGwPhCgO8JXnyHcOzw3aDv
yvFVk/rm1p+n/G8Jna84Z+m8ZZjXd/sZd/WFgH7f0gKYjuOIYyjkFHklYVh9sTyuudH3gj+PVb63
iLs5Q8AQGB4COm8xNceU/l53+4jLClyZwPxreOR2eSphWfguFUteRajtLt6bG3ME9HtefWVI5+1a
n/HBPslnTTNUOOPphoofKtzyVX+XKM6Gy+jgwj7K37W8nJxVLB326EhKvxX5c1h+78qzx3ibugjV
qLgxVzgEa6UDji9efriyY1ARQReM4zPjOJExLf1gfHDA8p7xwTQM0w9jVUiQDp3SqY3nM2loGqYf
TjlKN8iv0mB+jQ/yWMur8sR8yq/yF4zTfCxLL9JX2sxPp3nocwslpiE9XrxnuDlDYDwhwD6rY4l8
Wx8eT61nvNYTAsGxE7yvJx6NF0PAEDAEahHgfGVzVi0qo/dseI8etkZ590NgvI2nWtmCTL788bX7
NVyd15jbxqCkfA/2MZX3BMN4z3alYzxlSQzTew3XPPTpLJ+Pl+FSn/1F+6j2V57n25wUObP09Rhl
oOz3ujec69H2Z6QRGHOFgza++lxxT6cCfp34GMY0KlTUF53G02e8CuKZnk4F9Eqfvl6DxdfSUfqc
dINue8thfqVFOoOVwzBNo/FaX+W/tj6kpfVhHi2HlgrBZ6WrdDSPKhlYDsNUwaPlkr45Q8AQMAQM
AUPAEDAEDAFDwBAwBAwBQ8AQ2L0RCHlcGVyRjXgiQ+BlbmwRUDlPOCJbcIuljOx7IYIiIJmQHS1K
MjByqDtdqPxH5VqUF/EiHfrBcObT9OoH4y2fL6ckdoZLRXFFPMayv7BfUn6q7dKQAF64RwO7M1KJ
sDsgnWPD3OghMOYKh9qqsTPQ0eelgn52VA13N6U0W4tnOs3HzhZ81nK2Fe8yBejos+bX523R0fit
8bu1+mp5Sqe2PuSDaTScLxIdYIzTcKWjvr5w+KxhTG/OEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEDAE
DIEyApSrlGQrbnEw5QiU1fjiFpMplIHa9TdsFq7ezhc8dKfz0hYiWI3FRQhekfVQnqSyn1r5T/CZ
gnPKkFSOZPn89jRcKv263vtLkD/234j051Tc3wIyJmeS8LwTc6OLQN0pHFSgrp1DNYRDwVAbr/k0
vdLTZ/U13bbidYLVfOprfn0eio7Gqz8Uv1pObbzm0/K2VY7mV8WG0lVf6QxFtzZe05lvCBgChoAh
YAgYAoaAIWAIGAKGgCFgCBgCuycCFM9xCxL+K4vqZNuewJMDxmQKu65/KNb0PTkUt3sgj67+HO54
ZJ0cAB3GW4+chVQyVl6Iq+lVblTLqcqbVBdSuFMAAEAASURBVJ6k8ZpP4zVcfQ23fIqI7xsueuDL
2ODCfs42YL+kr+2h97oAu5o7exopBOpO4TBSFdvd6egLoRaH2vDa59r09mwIGAKGgCFgCBgChoAh
YAgYAoaAIWAIGAK7NwJcxEhFg1M8yL1bQk+PIVxOz7iS7x7sz65FQNqiIO2SE+FqrygeorKKmxYP
dNou6m+Lsdp0tc9D5a9NV/ts+XwEDJfBcRgtXKhg4FDIy0HRdDFPZzKfD/s7OgjUrcJhuB1tW7Bs
i87Oxmv526Kj6Ybyh5t/pNMNxY9aRNTGD7f82nz2bAgYAoaAIWAIGAKGgCFgCBgChoAhYAgYAuMP
AcoHeIXl/AZeZReWLUp4mRsTBFRuo+3DPet51TqV4+gKb30eKl1t+Laeh6Jn+XxF3LZwqI03PGsR
8Z+3Fxft7xwfeZm21nQVnOJhzhTZaixG64eI6koHL9BCdwqBulU47FStLPMIIZAHNm0WWtJNWtvl
JO8RImtkDAFDwBAwBAwBQ8AQMAQMAUPAEDAEDAFDoG4RUGE2GXT3NGSQeydC3TE5at3WdaIwpooH
1qe2/bZXWDtRMLF6GALs+7T14ZZjtPopFFMyPhhGqy2bzEarh5jCYbSQHad0dc+9YrEfoW8eCjyr
FXkzildeikjpkBXVFGqs+YaAIWAIGAKGgCFgCBgChoAhYAgYAoaAITAxEAgKqPW+WCwgJJcKkkKy
R7qcSjwxKjyOa0Grhnye1g1F/2I7yfkauVxOrlB57/pxXEVj3RDYbgR03mLGTM7D3xZvFGVDETPa
GuA1hhCLyhkTtg3cduM63AyDn+Ax3NyWbsIi4Hk5eD3B6i0H0v7+f8FQuzcEDAFDwBAwBAwBQ8AQ
MAQMAUPAEDAEDIGJhUDtCnm/dpQJ+HIByun0yWR2Y9v2atnA1dv+AblUMsgKbhGuBttxbLm00g2B
sUGAY6AgSrh0tiiX3MtZDrRuKNlrjQ1Tu0GpqpjeDapqVdwaAvoSomac97lcFlEZf5UOUkQ+m0VR
tILUEsZiMUcuqDHcGn2LMwQMAUPAEDAEDAFDwBAwBAwBQ8AQMAQMgfGLAFes6qpVd4Q0j3OQyz9O
evzWa7xyrnIc5Z/na0RDHhpiYURE4eCUQmUlhLacpjbfEJjYCFD5xjGil/8sh0fTIkguPnNLpYhZ
aY1KR6jIk0eFvBEdbwjUDsQg/9SO+9pye1EFcbF7Q8AQMAQMAUPAEDAEDAFDwBAwBAwBQ2AiI0BZ
AXc758V7Z99AibYzb+CzubFAwG8Lv2TRMSAqf5qTEadwkIYqtdVYcGZlGgL1gYDKOclNcLz495zR
zI0GAqZwGA1UxyFNHYD0qVRIpzMIyzeDb8fAChWQy6QR86JugDpNoHxYmIXDOGxsY9kQMAQMAUPA
EDAEDAFDwBAwBAwBQ8AQGCYCTjDnZAX+GQ7lJYhhOb9BLsoFTDYwTDBHKRmVDY2JMJLRGI7dr8W1
R2Miau0ySngb2fpFwFckiPFVycIhK7u18FK5Zz6flzNPIhIfQ1HGjZ5Ra3PYyLapKRxGFs9xT00V
Dv4HRXV11MLBBmE1LvZkCBgChoAhYAgYAoaAIWAIGAKGgCFgCExkBILrgN09jRrUwsEMHMas6VU+
Qz8WCcuWV55YOMScooHNQ6dp/Cf7awjsPgio8oE15hnRYRkUqnjYfVAYm5qawmGEcA924sFI1sbr
hK/+YHmCYZpffY2rzV/7rOlqfaWjvmr+eIYDL2r8uB1jxRVRyOUQkjg6zafx23pWvtTXfLW+0lG/
Nl7zq18bb8+GgCFgCBgChoAhYAgYAoaAIWAIGAKGgCEw8giE5HwAXnTub5gSPIq4zY0FAioXoc9V
2tyLXu/JTzQadeEM07RjwaeVaQiMNQLRSAh7dCRFlgmI4Q8inMdsy7FRbRZTOIwqvBXiXroHyOQk
QDYpamxCKBZcH1BJt607Lz8A9MnlnNBqSslI2XEzOaXnFWVvv3gjPBl0FPb7CogtuRlKEaApXXym
F1466wdFhb+G5Ha/3BydQrpS14TQSWw/HeXLfEPAEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEBgeAkEB
Ne+9UBiFRDOQ60chnEQx0QovEocX9lfTD4+qpRoNBLSt6Lt7aSs6KiF0u5jRKNdoGgLjBQFaNvBs
k6LIO2NUznFOM1XpqDafKRx2El4K5umKq25H6OsXi1BctGQtp6D4yXPk5ZsH/vn/EL75KoS61lWV
VDz0Myi+9T0IT0648KFeArQ2QKETxXtvRPie3yG0blEVHbeSYOrxKB51CrxjjkU4VXmxMKG+eFRR
oPwWnr4N4d9fi9Cz//LLL1FNTX41Mq/9KArzmmqGnq+ECJc0gErP8Sd5C/3PIXTnLxH622+2qCuS
+6JwxPvhHX8iwu2D17dCL4PQP38D3PozqeszJa5KHum88HR4J56CiGgm6YbCrZTDPEPAEDAEDAFD
wBAwBAwBQ8AQMAQMAUPAENhOBPQ3OrPxd3ch2YKNe58kCyn7UMjLAsNYEuHWeSKDECVExJQO2wnv
iCZn+7C9orGE7FhRRCabd7KgkCgeGEfLBzqVD41o4UbMEBgHCCSiIRw2p9FxmkxEEJP9laiEMDd6
CJjCYYSw9TqXI5ReC8iifHQthbdhMUI/EQH7c0MU8MjlCD/yE3ifuhXYU17QQzhv6R8Q/vq58F8P
QyRaJ8qOW3jtC5z7c3h7tw2RkBZDYmXxqzMRueevg6fZcCcSv7gTM/Z+JwolI4XBE/qhfKl5T/4S
ke9eOHSy9DMI/fV8d3kf+AvwwplbpPU/ZtYDV5wsSpBq5Uw5Men87Qty/QneFT9GKGmTQxkbuzEE
DAFDwBAwBAwBQ8AQMAQMAUPAEDAERgiBoHCaQuui7KyQa5gML9qIYkG2WxbrBiodQtE4ZF39CJVq
ZHYUARHNuNXbedm9onsgL4qGEBriCVMy7Ciglm9CIKDzWETmsFQ84hRz8WjEjY8JUcE6roS/HL6O
GaxX1pygXWZ0nnWQk7MNskWxZii72xH5n60oG8rp1olVxNko9vGE9Lw7O4EWCLwczSd+7JQN5eTb
vBGLgCuOgPdU5xb0lM/8zecgNJSyIUA/svgXiPdJgOzaVHZULpQuPeeh8PhVCA+mbGiej2Lz5HJW
vQldfSy8hWsG5a/w0/ciXKtsSMyHJ7SqXS8K6ZzDSPGqjrcnQ8AQMAQMAUPAEDAEDAFDwBAwBAwB
Q8AQ2BkEdHU8V8hH4inkpuyNzLQDkJtxKHLTD0SkeQqiDa2IxuPuvAAK91TAtzPlWt7hIaB40+fu
Fz3pAtZ2Z/HHf6/BbQufRzrvOQsHTTc8qpbKEJgYCHD+4hWLxdwVl3kqkUg4ix/OaTzjRM89sXlr
5NvcLBx2ElMK4J3QW/yhXP6Ii9B9xItQiHSi4f6r0PjQPYGk9yF8/7MovnqfcpgT6qcfQ+TbXymH
+TeHIH3Sx9C3z97IymKCcO9aND52Kxrvlu2HAinD3/kGit+5qGpLJEdz058Qu+OOQEq5bX4dek86
A33TWxBe+wSa77gEyXUbXRpPlA0hHjtRcqRB52jJfSj7BCLf/1op1ve8vc5F10lvRLrZ11REupeg
5defRGLlhnK68FXfE/4uLvNXru+Dwe2ijkL/f12A7lntLl8434PE4nvQfPNlCGd6HA/CnfNtYihD
azeGgCFgCBgChoAhYAgYAoaAIWAIGAKGwIgi4AR3IqALx3iGpL9I0oVFZSulMFcLh03RMKKI7xix
glg35GRLpd50HtGIWKVsRU61YyVYLkNg/CHgywxDEP2bczGPEtSgFHX81Wk8cGwKh+1sJRW6U8nA
e7VMSMshyQ1b0JqL7nd+CxtnicmhO+thMrpecT6awnlM/8f95dSh+/6CwrF7you6YnBSuP0KVDfO
G7D27LPRG+WZEaIF4HZH8Q70HvYuhGfNwryfXxoYLr8E7vsA8i+ZWSoXjs/QHddU02x8B1Z+8D3I
kBMZeN6UA7H5nT9F84Nfx4wH765SNjCBKhro0wIj8ucfVhlAFA+4CCtOfImkzIvVBhkUF5mG7rdf
g6k3vA/Nqzb5YfiVWDl8DLmD2t2HCellly1EcGOp9OvPwfNy3kNoYMB9uEQiSeT2OQHZC16HaH8R
qWQRYYGCec0ZAoaAIWAIGAKGgCFgCBgChoAhYAgYAobAyCCgi/pUkZBMyiHRItPgM3+Dc8cDpuFq
YYbpKmHem9t1CKg8hD6vfEF2z5BLHduJl7aLtqvGm28ITEQEtJ/T58X+nyt4WNNVkHECzJkSl2Nn
qCiNSPxERKA+6mRvg51sB2fdIC9eHsxT7eZg03u+h3XT/RczJ39VUvQc9U6qDCou2+NeAnwR+OmW
I3ZnRSHBhJ3vOgs9ET9eXybqF6YegzXHvKpCT+7Cf74TXkkp4tNcgej9C6vSdL7lXU7ZoHQYSR42
H34Olh7x6qq0+uDT4oqGJYjddqcGi/9ybDz+aBSkTK2n+p4Xx7rjP0SdRtlFHl7o0il+3oBvVaEJ
irFQFR0NJ61iU6PDibyYMwQMAUPAEDAEDAFDwBAwBAwBQ8AQMAQMgdFDgAI7XtyChJduUeK2WhLL
BxXsjR4HRnk4CARlO0F5SfB+OHQsjSEwkRDg/ETpIc826RrIidySi5cZZjLF0WxnUzjsILqcsFWg
Tj+TrWiRSbLvVV/C8y2FMnV9Qbt8oSnoby1HyUZ798PrzCCT8a/sk3+uPiS67cPYPNVvquDLnfd0
pNm936vEriDg1t+Dwqa0s0SgNUL6+adR1dgN78OmNl8Lrho/8sgPBvqbD30XNgdNDliO1JMWHe48
iOcWVvFYPPBEdMr+S/oi0w8RxSnTsAA9wTo/+xiy6Qp//S17IqiyaZCtk9o2Zxw//JhRenqveAZq
bLeGgCFgCBgChoAhYAgYAoaAIWAIGAKGgCEwQgiojIByAv4Wp6VDKpVCY2MjGhoa3DP3RefvdbVy
oHzB3K5FgAtH/d03/MWwhWJBtlOqyG/KCz1FdqQym13LoZVmCOx6BIKK0EzOw98Wb8QDizZgc28e
/Rl/Qfeu52r3KbF6157dp94jVlNO1noFieaTcReuHZwvXxW+A43onb0fWrueLmfxXwClR89tclSO
y+5/sFMm8LWtgnZ9SeiLA8m90C97OrX0a7Y+KU+2fSpZOWDdU4Etl4DiXnLQk3wIROQij/xACNaD
YW5bMyVX8rUO4c5qi4RQeiWaVok5Zb7oTJLCEelagg1ffPSzxW7EgmYd8rFC3sMl/IrNezirj0S5
vH9h8rUno/UQORPipa9CYVqbq7viqX45ud0YAoaAIWAIGAKGgCFgCBgChoAhYAgYAobAiCPA3990
lEcEnYYHw+x+1yOgshye2eDkLGFuIyO7Rog8hs/mDIHdGQGODyrh0llRyMk5JwVPlA1uw3lTjo5m
vzCFww6iqxO6+rVkIrGw28+QWn/V9DNtNpv1hfCx4IkP0unFCiGX8w9aiq5aUUUuPXMquGqAdLii
QFcZkF5arAQo1B8YKCA7ew7wjOYVbXZfGvmkbyKU96o/DDIzpzklg/KnHw7KX6Eg5Wwx9irKlXyx
yp4CoSXfxYwlVWxv48HXwHulDxfPm4kN7z4Xs352RVW+2KNXYLJc3oxTkHn1O1A4dJ+y4oEJle+q
TPZgCBgChoAhYAgYAoaAIWAIGAKGgCFgCBgCO4WAKhQoi6Cr/f2t8TtViGXeYQQoEwq6sCw6jYY8
NIg8KiICHYpbmMZXQlTLhIL57N4QmIgIsN+z/+vlP8sZt7QIKinjZJQ4WetErP9Y18lmnFFrAf9g
Er6Y+VLWLYH4QnZXTbk6AOiHNz9bFRsWTRxpBOmQrl4MD4WiKFapj/oQysjeZDKIeNW8h5BvbnR8
BPlTehq2hb5BuFI+Y4seruJxux96xYqjhqnCrBOx+G2fqj7fokQ4tOY3SP7sbWj8/IWIbkhvd3GW
wRAwBAwBQ8AQMAQMAUPAEDAEDAFDwBAwBAyBiYQAZTTquGg0Kn+akxF3UeYSjNd05hsCuxMCKsdk
nYPjIXi/O+Gxq+paJaLeVYVOtHIG66TheMJZJSQSCacYoFKA6ahR4956teYDRXc2gp8mUnMAtReK
u/0SqbQgPV/BIFselV4eDOf5D+GStYCPbwNyMf8QaD7nctUWCalVmxDfd1LZcoL7MdJR2UAFRTYb
r2XRxTve5S43dS/5+5AL45/C3Hdj85x2MUqKOkVGuLQColCQcsVkiaZ88qoT3aH8o7XFIa8GT7iI
CS50LJcuNOfVWHbuS5F48i+Y9refItG12YWX/2T+D7FLnkThizfDmzSYSqSc0m4MAUPAEDAEDAFD
wBAwBAwBQ8AQMAQMAUNghBAwi4YRAnIUyFDZ0JgIIxmN4dj9WpxcpjHhy2dGoTgjaQjULQIqo1UL
B+7kwktlqJRr5vMRkc/KVu8ybihjpbP5bWSb1BQOI4DnYJ2SgnV2WlUO0GfndtYNohgY6nwEspPZ
48XAPx4vcxbr7S/nU+sDHUB89un2I7lqeTmPuwloszW9JggV0mXeyJPSCfKpaWt90io2NFUF52Yc
hecPmVlWiFAJQscDq5lefcWkqampfH4E0zGczscniYH9XoNlciV7nsHke65G47NPuHj/z2JErvkd
cp9+cxnTQKTdGgKGgCFgCBgChkDdI5DH5tWrsGkgj2iqA7NmctGCuYmLgLX3xG1bq5khION7/WY5
czCKZHs7mutuMq93/sZZDypkHcPyE9+5UDQ+ziow8dhVeRT9WERkULLQszkZK8lWSu1UtTh14mFg
NTIEhkIgKAuNitiRC7UZFgwfKq+F7xwCvpR352hY7kEQCIkiQLdRok+BPi91VEgEXbCze5Hql3by
6Sdk/z3Zgy+QX2krjWjxeSQ79Yn+DOSicjZEaUulYAzvI6uekxeRmNsJb7zofGG/z1c0mpRnF1z1
RwdmUU54D7rYuufLg1bT0Nd604KC51DwDIpUKuXu+cxwXgzjxXhe5IlKiGzr/lh90tex4pQz5bUZ
cOufQL50Hoa/ZZRNGAF07NYQMAQMAUPAEKhLBPQbofuRq9Exax723ntvzJvVge893G0f/nXZYjvH
lLX3zuFnuQ2BekbAH98DuOnDMXRMnYqpUzvQEjsXi+V3IuPG2tU7f2ONz/aW78k2z14ujeLGlSiu
k8MbNy0DulbBy/TBy1dWDm8vXUu/cwgEZTi8p/yFshTKWOjzmXKVYLqdK9FyGwLjE4FoJIQ9OpKY
I5cY/sgCaHlPmeJhVBvTFA6jCq9PnJO7Op3s9Xkwv9g8pVq4vuJmxPurP9z0B5zmjz/xh+qVgTMW
YKCi30B+2kHVZyOs+jOS/uIEJVHlxx/9KZpqdjMKJshP3w/FQEBkyR1oFVskfZGpz/qq0kFffvrS
Y5zGa/rgS5FxdKxrZu5J2DS/o1JiRs5xyPtbVNXDB22FMbszBAyB0UZg9d9/iONkXvXnjQX49p+X
j3aRRt8QMARGHYHqrR9HvTgrYIwRsPYe4waYcMXbt8FYNWkOG9YGy16KDQPB57G+r3f+xhqf4Zfv
8fDVfA7ofh7oXOVfXWt8ZYMoIyi4Mzd2CKg8RX2ERJYil8pcxo4zK9kQqA8EaNnAs02akmG3tXtE
nkXKWh/MTVAuTOEwWg1bFoZVlA1alP8S0KeKr4Jzb8qR6G6thANPovnGP8K95EsaOLVccIqHzQ+i
4w+3BDOg7xUvB89RUGE/4vPQPyWY5CG03P6QO09Cz2VwtIR+5NGrMeWW64OJy/f6Ags37I/uGeVg
ufk7Zt7zH7elEs+ZUEuGhoYG8GpubkZLS4u7bxSzS7VmUAVDomsZUkvXunCmb2xsdJfG5/N9iHRv
qhQYjyIn5py6J5vyXklgd4aAITDRENBxvvwvN+DucuUewW//ubpqLihH2Y0hYAjUDQI6fvne9s+z
4klOFceVk2axWMFjvN9Ze4/3Fhxf/HNOGezbQPvh+KpN/XOruOp8Lkb1AVdEpDTPa7pA5C651XLr
lb9dAsIIFkIcC7LfuZfrh9e9CqE7LkP4lguA350P79avwtuwFF5/p5zZKGlM6TCCyG8fKZX7RGNy
hmg04bY4K4RionCoyISofFB5zvZRt9SGwPhHIBEN4bA5jTh8bpNTPMRlf6Xqc3DHfx3rrQamcNgF
LcJJXd3WJvhKukZsfPnbNIvzQ0u+gvarfgys3Vj5QZ7vQWjhL9B6+ccQMGYAGs7AZhlEWpbvN6L7
Ba+vohn+zyfR9Md7Ecp4jmaxdzliv/oomn7xg6p0tQ8+nwlsOvp9VVHRp76E2Tf9HsnubFmTrhr1
aPcapP5xPdq/dhTaLjoL0QFdnez74b9+BrEfvh7NX7sEyaWr3BZSmjcczqH9b99D24ZAcfEO5OXj
R5193CgS5hsCEx+BzZ0bqyrZmqx6tAdDwBCoYwT4vqbwolYm4YfZKqM6brodYs3ae4dgs0w7gEBn
zbdBS2LXzSfp9U/htltuwk033YTb7n0KYoe9Wzh/fG+5PtTzOMfvOvyHArve+RuK73oMpziDSoeC
bGkc6pfv8N71CPXI1bcRxVwGRVo+mBtzBDjsivInX/TQLWdk9aRFCSRbeVfkTGPOojFgCOxyBLT/
c5v6VDyCZCyMeFQUcTxl3dyoIlB3RzqNam1Hkbh24uEUMdgHWKi0vRCF7PzRnd33NHTOuBFtayoU
Qyt+hMSlPwISe8FLiIVc97MQr8btjw3veAsPZ5ADgyJu7z6WR6uDwovejb6//BGNge+ByL3novHe
GhJbeaTFAR15LO71dqyf9ztMWVbZeym8+ApM/u4VwuN8FKfNk22PNiK88T9yErbLVvojB2oLb54M
cMXCi04TpckiYMONSPxILkxGYc4hUk4vos/9s+bECyB9wmvEwqHg+Nge7INc2L0hYAiMDwR0ntDV
z7PnHyyMP1pmvihWU7TU0vnJ5oQyNHZjCNQNArXjOJur3lKnKGOY45jjlxdX6pkbvwhYe4/fthtP
nPP3CB3njlk13waerPLVOUXnk5H+PtB+/tgvzsIJ5/zF8QIci791/RlHNvvn45UCJ5THevPyv8sK
yFXWgEk9/dXw+bwvyBmL+bze+RsvnUH7t2tnsULMZ+QHvVwxaXsV0zENf5NLZ0BExqGsny8Lt0d6
vI0X3HY1n4ozfar/etIFdPXncPvCNYjKAdKnHj0Hibhv2bCrebPyDIGxRoDyVc5TPNNEvxnIky5u
pvyAY0fH0VjzO9HKN4XDGLSo/zKoLlhf2trZQ6FGrD/t5/Bu/Djan6sI9F2uzLNilVCd3386Guvf
ez66WqNoCCgwGOfTnYaV7/kq9rrmAsQGyx4I8/Y4Bytf0Is5/3d1OZQ86kDkAAXi2HjSDxC+9YuY
tOipcjp3k1mC8Iol1WHlp0Y5ocU/m0HpFZOpcqx/swGRFXdXW26UUuQOuQQb9+2oPrOiJrc9GgKG
wMRDQH9A7nP6D7H48HPxfH8W8YbpOOCAWWXl5cSrtdXIEJg4CKjwgn6hJCjU2rmFDDVhGmf++ETA
2nt8ttt45Jp9bd93/6jq22D//Wfusm+DWGJWALaWbf7OCiQe17fEnXO3eAFXspwvjv1GCvXOXwC0
ur5VHGV/Z/kB71uvqOyCjDOenYC+u6/r2kx85gpi3ZArFNEr1g1UONDiwVy9IZDH5tWrsEmsUKKp
Dsya2T4OZVtSh/Wb3dZdyfZ2NNe5ZNmXO4Z4DKxzMc9JN+utY0w4fuq8W9Qv3r4AX1bqq2A/LstY
As6LxV2cptMoTV+MBV/THQjJMemxWMTl4YvaWSQUpmPdW36G3mduxbQHfoF4V43iQYnGD0D/i96O
tYcfAbEPQlxWBfIMBd3Hj/T4MchVPrG2w7DsrB9i6q3/i9ZlC5VCxY+/CD3H/RdW7DUTWB08F2I+
vIaYo8k6sR6kmcu1YtOJ30Tv0rsx7b5fIrlhRYVWzZ3XfCTyC05E5uXHyvlFOYRk5QvpkL/sK76I
XNOhSN11HSKbgnsnVYh4ra9E53FnyOHR09AkmkhqIxXPSiq7MwQMgYmGAOcIncc476TlA7p97l5y
UH3RKUG9XA55mUt0vqVPp/5Ew8PqYwiMJwQ4dul8oZT8CJbxytWS6XTA3FLiC/msi+O3S/DdbuPY
wTdu/lh7j5umGteM1vYz/sYpipCtbc58tMqcwzkkn04jKr+HeM/5R78RRqLiWj7nMrq8CPcqzkNa
9rIXliac5aXWW+fzrGyvUyhkkK06kkfqzu+yvL9v/K6cz+udv0ofGR93iid9niWZzshp4HIlS+91
rUVa+oEnlg+NTCfXSI83Lcf8wRGoaifBP8/5Ry51nKd4cSzS2XeVIjM2PturR85M7VhwVpmBbz3U
hU8c5ssT6719/P6Wxq/PbMDbZPMV352DRdlvYi+RLtcL/8oHfV7s/7mChzVdBZmngDlT4og4+WtE
4rUe5o80AqZw2AlEtRM7EnuchBWffrUcmCS7diZSSLU0IVrq3IxnWg5O7fDpYy7D8iPlpZ2TbYFS
STTKSek8sERfBPSZnj+8B/Z7PZbuewKimR4kezsRk20IQiF5YUSSSDe1Id2QcnRZDpUNwR/rQXoa
7qXmYM1JX8bqbBeaN28UegWEREHitcxAb3OD04KH5EPRm3kSnvjgaxEthpCcPEm2QQqVLSdYFh1p
0mXmHYsVckUKaSTkcOcUt0pwIzcGr7EZxfbJKCZizpSJPMVdLn9FBOvpyR5R2QVvR9+Bb4bXtxnh
rk0I9/W7w6eKsSZkmlqRSSYcPtx7jTR4aRuoXyJrniEwYRDIp3vQw9UP0ZQcvj62hxUoL/ITGik5
CD45Am+Q7aHpzxX+jxne6w8a+tvrtqfcoWhTmDEgcyVkLWNK5vHSjnNDJbdwQ6AuEKj0fWFH5pX2
EZpXgnRTze1Dzg86jmtX3BXlx7AKsZhG6YXkwMOdnW+UlmuAEapzumczZGoeFob5fBo9PfLNJ3Nn
c3vzTq1iG+m6KL3hvmNYl4GBASdM5aTXLO+Crb0KttXerk3sjyGwkwhw7tCLfU5/F2j/Gy55HQ/D
/c5R+tHSikktJxLmKvDtl2BUyhdKIzRXVWju5LebjP3N3f2uiuF4AxpkixZ1ouupchROe14lviqy
5qHCn0TsTJ1Hib8adne7R/ZxdXxPh2q+ud0YkARMxTEYCqTXfObvWgR0XmKpwfbjvc6Nu5YjK23b
CFQURJp29d9/iNOPOhN3u4BDceVdt+ATx83V6DH2c9iwNsjCUmyQz9y9qtdgBxOM+T37Pucpnm3C
3yCFYsq9p0WywI3gxpy/icrA8L4EJmrtd6Je7LC8KPSm0D0ejyPR0IJoWwdiDQ1OsK77ibMYTavp
acEQbxaT2/Y2JFMpl9/RkHDGpSSMFy0V1FrBa2jDwNR56J61N7pmzkfXtJnINDY42szLdMF8pMO9
yngpHY1n+ljDJKRn7YueeQegZ/be6GttcmcrkG/lJdnajlhHOxIlPpQeafNqampyF++ZB/FGZCbv
IedP7InO6fPQM2sO+to7kJGeRs26/hiohV5fjFyhlIs1YqBjFnqFp57Z+6Bv2gzkpZ7ki/XQssiL
toP6tXTt2RAYDwjklt2G0xcswHHHyXX65VgmL0Gv+0lc+eFXIpZqQUdHB1paRLG44Fw8vKkicB9Y
dksp33FYcNyHcdeqgaoPy+q65/HgD87FggXHuXJOPvd6rGM5cqnbgo8c43N48q5r8WHhTXnp6GhB
Sqy0Tr/gB3hkXfUqZaVFn7R3lKbOCYP5meV/wrlvehNOOeUUHPvmj+BPy/ur6sGy88tvr8Z0mHUJ
4kE6Qed46V6GW35wMU5eEBI8UtIuLa5tYoLHK08+HaefXnOdfLJ8IC7bgr8gXbs3BEYTAddvB1bh
tmsvx+lV47gDHW5eOQ7nXnkTntwkCw0C80EtTwPBeerD15bnj2UP3oILTj8uMD90uPnhuNMvxm2P
rCuTIW1+A6hfe4aDV4w5S8yn7v4lPnb8i2W7tFZMmjRJ5r/hzTflgko33tbqfOgry3WuzafPg89d
A3j4livd+E+1CH4yNzsMhd7F196Lbqmjw7vkr3r4Jpxz8qHyHZby00pdYqEF+PDl12PZQPX8q+XW
+o7e1uoic/rW2o/5t6gL+XPvmEq71b5jlA/mX7f4QVx75QU4mf1H6tJSrrtfn5M//P/Z+w44qYrk
/9qcl7gIBsCAktRTRAUkGP9nwIThVEzg6ZkQs+eJGI8z3InhDnNGPe78eYp4KgqoGJATFRAwAqKC
5LBs3p1/fd+b70y/tzO7s7uz7MzSPZ+eTtXVVdXd9fp1erfJa5/97Gk/yFd3fes97zoudPhTWGus
BBojAbYfuBU6NrjmpJOcscGQEy7SscHWUPsiXK2+EOPYgLQRD9r2ivcelhEjzpVzLz5Xzrr8RYKo
O1V+P/Jcufjcc0NjghMvul+WaVl+4+CLd/+OkSeUXZ8BzOr5b8ptF52om9NyHJ0MvdyuIEf6nXKJ
/HP2MtXb6TpxY2JyT9XjnY7yMlPhb6p+Jr7moo/4retKAO3d0de6az4A62s7Ad017FiN96dZGW47
CaCO0O+qtUM6Vr+7UaNXYCEOFvXI57Ktp21XLywJMod158S8+rdaP7rO+qG7fNZLwcUGYJgvr8z9
pUXrj/STvnSf3k9L0PZlzhOW6/Px4+/WyUffrpUNxVVSUu6OQ1lH1o2/BOralBT/0lohRiwgwNDl
IgPCsGYDJxw6KxYpkAY/XMKbeODH1QNIB17AooObhmXw9ALg/LjMcpEOfHjoAI744IdBmumauOAn
3YBBGHhAF/ACF/wwdJ2A/gFvNAsYf5qZD36UBRiUQ15JG+KtsRJIZgmUrlsmk+fPD7JwsKy6ZY5M
6DFAQqcUydz8iTL3p1tlf90hC1O57hcj30xZuGqCHLZjtFMQW+SLKRMlVMzMJ+SGW8+UImMngp+O
dXd9L29e30MunkwCvO7kCRfL5AmT5F+LZ8spPQ1EBlijcS76QEZEwVm2foU89+GHoVK+W3+3HNVd
vw1jmKaUe0qvQgNT2Lthwctyyr6nGoO/cBp8s16NLKi8Uyd4AW3ISmAbSmDDvBfklANGRm23Mn+m
TBwLKzLx/Z/kisHmXeRhQitNPTXzXVlx+6EyfcIoGTlxZhjI8M2cPF5gL3zyf/LwefuHUjA+cG0o
yvFkbP1aXrzmahn73CJvQjAUi75hRvA8ot9Z0XleMEv5hRW5//2fZcxgvUbSZyLpkFcv7SFjX/UB
Iqj4xo8aIuNfnSg/vTJGdpQNMvX2UXLC+EjA8+XR60eqfV/+t+5h6dc+Aj4jKh715+cl1meMbFgg
t5+/j/JlEFTLO19efRR2vJxw1zvyr2sP85x4iFbf4fjwuNGO52oJ10Y0QAIYGzxrjA2+X1/72evv
C00Z5/z6xZsydap5/WyY2IWv/1MWhoPq2yo33DNGuvs+otcc/TtmnnScFW2845JeJbMfOE+GjI08
tlk49Qm5UO3/jRknnbd4mNWAdzLNTI2Hfm5O+kxard8rAZxc0Rd+T6RZ06bfA2QD20QCfK5i9zbm
ZVJTMceUojdGuJs+twkRtpB6JYB64hxcCDgYxzkxxG/YuC6UDE+baK/4HqjmD7Cd+ft7wPm+S+LO
y4Hual2EK6vQBTk9llcd0MUGZ8SauDQ3f202fwl2waGBMubLECa7YTj5jZMDpuLA7nvAcIIf+dDI
EY84GISJj/AmXuADfsDhjky4iGM+5oWL0wV0gYMLA8SHNNICHICHy91lgAOMaUEjw8gLGNCJOBjQ
gbhI+BAHw/xwAUs6iQc4aJCH+EiXiYPlm3goS9JEXNa1EkgGCbCf1KSF+4HoMsOAHrWWGkLs5Gr3
Q/+AqdYj+6bBiwD7kSfe6Wfafz1rAgXi7kQIQ/rpOGDn6HSEc82XU3tdLJ8XPyP75rp6kWmgpdE4
e18sX2x9TvbWwRX7N/o+TEaOe5Uby0lVPck0xDk7R3wyjZmXCOU6emrNbBmhiw2zWGjQ7TtkuLRf
P1Xe984seKC+WVPsqRfy4wGyASuBOEsA/W/DvEelY//wHbGhIoYOleGyTqa+5224Y4fsLPLRKrn8
oKJQv+Nz2tuXJ8sBO0SehAqVEfQ8OuoA6bLzcrlxaGdn3AB8sNR/hL/h5KPprcOtrW/Yn0jnuv89
LEUHXlIbh8PzeuV5gSftiiE7Sc2HK2XMwZ088V5+H5WYdMirY+WSW/Pl/224Xy59wFuOB7kTUJzn
HygbXzlfoJpNHYbkeNVfJD1c1zMmX/UsdCjkuuCZm+pZbHAYCf29ev0R8ueDVspNhxSF4qLVt3vl
SvjZx3oMZbQeK4EYJMB2g/6TluUdg6Slu+9iSKN+8I6bYuzXurOU45x9ctx3IGfHcPXGGCgkyEbt
V9hhHB6/xEM/R+rfMekq8GSMd6h/KCe4C56+NOpiA7mC++YDt7vBPdX5Bl5Xv5s6nngbq5+vGLCD
W0bwP970eZDbQEQJQOaYUORHowmEPoiPsGpyaNzANOtuGwmwf7G0VK2n9JSA5GaoXtQFB0zdAAZ9
kn2dsNbddhKA/FEPeH5UVnk+fKPfvcH3cNyxF9/zd96trxIXHkvWpGc6eVtq/svVAe4JjYBO1ld6
piF0XlH5qtJvtMJAL2A+MhEM5U763TC+vaQngtQirL0kYehNBJnFkwbvyCyemLcTXOhM7FCclOci
BNMoCoRpABsJHg8BWMDCJS5M0MMijHz+eBOWec3y4IdFPuIAPuCii3j6GW/Cw088dImLLvKRPuYF
bcRLOikHhIELLtOQn37ggJ/5iZPlE491rQSSWQJ4AEYzv7vpYXn11X/Jg+NGS185Q3Zol+Y8GJEH
H0j0GncizxvnDjLdh6yZgrzcaRx2TQjTf9m9/5L53/4kPy2dL1PuGWUmqX+yPDXtO1+cW26tSCPi
snumyILvfo6C8wXF+b0BXZfX1W+E4ICCYb/b8HKr5K2Jl3kWG/pe9pQsWrlBPp72gkz7eIMsmjFJ
hvgKuve9L2TRl1/K0+f2dQaYvmQbtBJoXgmULZArfIsNQy57ROYvXSvF06bJi9M+kbVL58m9o/FC
EzZjB06UH8PBkK8uPTX6zskyZ/G38tNPS2XOtPtr9YVbj7pdljjXfPh1Vgi9x3PxX16QL77+UVYs
/TJmfeMgAM++xQbwvHD5+iDPH8u6ZfPknlFenq8cVJvnuvgd99QbsnjpT/LtvLflpuM8pMtrt17g
WWz43U1PybzvlsnSb+fJk9f4gS+Qt7/Xb39FMnGqv7r4QLF4xrzyypTQM6aonTs5i3zmhXl9h18r
k6d/KktXrtHvUei3hTaskaVfzpBxw73E3/K3V2R9Hc80E9qkzfSbMNZvJRCLBNz3guiQaF+00aBi
HeewrfY98x/y5tQ35e2335Dbf9fTQLuX3Prca/LW66/L9OnT5d1335T3P54ke+eF9V+gdH5c9DNp
MQr3eBs+3nGzB1a/KWeP9m06GXKZvPLBIlm5cqUs+Oi/csupfUJl7RlabAhFOR4PfU3Qz8u9aCVe
9PnQ2mAdEtDX9VAfgt80mKzDL9FMuX5Tcvwj/5Uzb3pOzqrDTpsd+WRlovFTFz1mX9M1BknXv4Ls
NMdqxdn3kLqEt43TMMHtf4fHJgxnw1xwUQL12WPkI/LdvE9l9uzZ8um87+SF0X0Soh5BGyftw6Lj
VVGeVYhwcgL4QDf7CV2QZfoTgMxWR4I94dDIKsXAFgaT4zCYCIdhg8UkOQxdJ6B/mDiH4cqlE9A/
wvld4AVOWnRu0wCek+9w/flJJ12mo3zSShd4iQtx9COe+cgn4mBID9KJBy79LpSbn/jg+vEwP+SD
vPhOg2mQbuan3BFnjZVAskmA/QNXpsFfXlH7Q1Hg6Y7XvpTfH9TZafsDBw6Ts6/GCaNqPfHkvrT6
81XrbgnqFrNvuFef6a4Dj/rQOz21fHzzmLClZeb0EqV6iDz50XMyvEd+EHcnGXL2n2VmRqUcOvY5
AskDz78vt5y0mxQE+yT4Ai2V+lH62sbFeezuuUFd4eKclVklw654NgR+/3OzZNzxXaWNTw8qap9x
dQ71ERKrvMwG4RtWbtugfq8qnifP/SW8w0R6j5cpNx8r7WvKpbi4zOGzcM/hMmnqaukzfHyItgVL
qmT0abvryS53NwsSIGu//gtlsB4rgThIgP1g4b8f0qXAsDnkhiky5ZrD0DmcCWOn3+fsKOdMeEM6
VP1Wzn+GL9x/kRc/vEKuG+juUufViX5942I+RJ5470k5rmeb0HO/6/6nyZQvOskpvzlDZoeKf1xe
/+RmuXJgx+BLCvpsKNHwHCyPzHpGjlN94z73d5DBI++sU98ADgZ8L/n3g/KCgW3wH/8tL44dLGmB
Cu2rFW5KNnieJkU1x8h5T38VhL5LeR4rVx/U3uEjul4+Rl769GE5tFuWC5e9t1z62MeyucsAecAo
l95b/vOlXDzAPdkhetHSMdc8JE9s+UFGP0JZi7wya7Gc0G3v0HiSeZtaf9cc3MGhEXLxfy+DZfAZ
g3DG0CNk5FX6bZoMXWgIXufZoe+RcvrpPeTEKy6QI3q4dVdT47Yf5Mnu1EsunfSBLJ86WEKa+7X/
ypJNo+TA/PAYEbDWWAnEUwIct9SFE/2Y+pDwFXWMSeof57ynY5Juok3bee4H8naRPr9p4/SX0j67
a+ySIDm7y2/27iG75aU737nDMx8n4VNV91ZofwQtX7/89ybpZ7N/N3WcdfMJ3YTjHcgMZu4LDxv7
ajVi0M16Lecl0lm9gGnfbR+54L63ZL8B4+SEq56Sb5yTDchZ2wAe48El+kxqrH5+6aOr5BrVz6zH
eNJXm2Ib45cA6hA2ResR1m8CmAcIPov9aS0ZzspIlwtPGiiX3v1vWb2+OCopD035QNMCcuwh4UW0
qMAJnoDFhjw97ZWtJ7yG7VXo9Jm8LPdK7QQnvdWSh74DAz2IZxLGWP5nUWV5mXOjCca0mOdCnkpd
MGvXbXdpE3xuBDRflaZDD9ICL/Ui/M1hSD9ohx83r1RXl0uFRxXoPAPoq3I3N4MPjs+bm75oPEei
m7fGIM05qaj01ug35Gq037Q0vdH4SPZ49y0t2blIAPrZ6f1uNNL8cAz74RGPxk8Xg1bTmmnEATea
IQzyAQ/xIkyLOKQxDJf5/HgZDxgTn0kjcbEsuH5jphGXiYM00PXnt2ErgWSTAB+CcKv1Ae43Ix96
T0YdUOQMTjBAocXDPuTH0WbDBPBxMB8usxzvgYjwTgTixIfFvGaQvPi/l+SY3XKCD2X3o2N4QO95
0gVyjgm8aZNUKC8oj9bB66NH31odnEfvmu3wARgMvGB7nDhaRvpwVio+wJAPJJt+hgFD48jHCLvx
jSuXZW8hcnXH3HaStNM6Ac3uYEWPxqo/b+8jxLzI5dc1G5x0ysNAYb1WAs0qgUDgO3n83MeNMs6T
2/8wRPCygjYNy35XXZ0hR195vZiv2S9M/yIEByRow7X1VG957OPn5Jg9C5y+HMan+qpoiEyYOMIo
X+RP//nEmWwjPk+iEzhQHtdvyxzVzT0yjr4FnOjPdekb4gHPj51j8nyu3HHxEEkN8su+6upPl+fe
zKwueQavkE9tfqFDHpWhu2SE+HVx7ixnPnmBgcn13vzyfGexwSvvNDny3Es9sMWb3Sszzch41R95
8e+kQ1l4xpzfr2NID4MXyIb0wu108Hny8MM3yVF7dQqlEQ6uUz8pu8lpt//WIF9vxNW8KBuGrgFg
vVYCcZcA2lmwyYVxO3HhMUT0fh3jOGfjRuH2EFePhD96Xl5mrqBu1QkZY6wGfRIcx4G4QOB7eexc
U1c1Tj+zf0fWVS9JbOOszc7YjUJzcS6T/7t6KqMc97H7LpAi37gHOqDnsTfI6xMv9MAqh07YrRPX
X1Oj+tnDc0P18+eOLoknfSAS+KxpiAQgL6/MIELOBySiOHfq1Eb+ft0p0qk9lgojm026eeihKbNl
2mxuQogMl8ixnF+Bm5Gmt0Ok4YRDhmM59UKYRObDpK2qqkw3yGyQDRvU6slK6l8TpjH+qrItLk7F
WxYHpA3FF+lZhO9s0CCd+tPVee64HfGwsRiTpg1bopykjQ1RSFbFKixTZ3rnFVQzBOmOBe22hjHp
TtcZcPQPynhb07K9lWcXHJpY45gAjzZBzslxPoThxgrvh8PO/7osJ+eZj2WSPYYJh5VTWHxTwbQs
g+mEp0s8dFke4YmLePwu8TAfXcb74f1hlsPyyZ91rQSSQQJ8sHHAwAmb0tLgzlsycfy9cuUROzi7
kIuLi6WsrEzKy3Unge4oMN0SX76qCheGE0IsB3mAQ99/DaMT5hpPfMBdWual44pn/ir9CktCdGzd
ulVgQdOW0nzRza9h8/4MWbLRnbDiizVwlpV7T02YOJ1rOXQASbxbywul7xFhlPL+TFm0ITxBSnn5
d/PV6L3ILBMueCotj85LTOWud+/SBL4KPYGSa5DVSb9VAZpLSkpCLvybN+vpLFwrEDTVlWWu3FUO
mJhj/dMlnHWtBOIhAbYr9JOyH+bJgwbSgTeeLF2rw/2X7Rft1ukPefvKWUeFMyyc9aWsVTxu+69w
dE+Z7wTUH57QyfcOlY4+MPE5+kH7def+R4p5yYh88ZNsMRY8wqW5vosf+Yv0b6+0q64qLS0N6Rrq
mz4e3RDWN+CXPJunDAb88SSHZ+QP6RjqL6WvOP83cpahwxbOmi9rlD7oLUd3+fil7jLxkde8rn09
7Bw89iU59zd5jmw2b96sumFziIbS/C5isjJ15hzZoOWCB8gbuqL0+8+aXH/gBbgcefr0oQy/J/SM
Qf2DD8DBmnQgP58fTEfdmBaylQzzVKqeqFAdjOcP2yRca6wE4ikBti20M/QbtNtId2KjDSMNfdpt
y9HHJLX6to5zPHrng1mySMcGwMXxFfVFVbXZxrUP6HgM5dGSDrilqp8fMoQx4EZXV6EvkQbo5rr0
c139m7qKYx24IR1Ya5w1w+GJ9DmyXPmNfGLQJwPulP3alYdwgEbqAOiFnYedJzcMNTOEZYF6gqzK
9Po+85nUUP28YOZ8WR0cS1X+8rV8bBbXYPrCmfE+aU1sEkBdQlywtXR6ik4pwQZNor2nt/ZFB1Pe
8GNeBXMmmEeBizDmXEw41lUiuWhXq7/7RJ66/0Y58bB9lf4cKSxsL+3bqy0slIyUfeXEi26T1z77
uXYbNBgpXfamjNx3XzlMcRx20VOyWvEC97JPXpMbRx6m3wIsdHEq3pyMFDls5G3y5vzVBgavN174
QAMs9GxNteelXL9/EB4HIh22fPl0ufKEE+Tkk0+WYSddItOXl9TJd6D0Z3nzqbtlJGRn8Ni+MEdS
9jlUrrz/37J4vfcZ6OXUDTn1MP9Nue2iEyVF66BDhw6ObVeQI/1OuUT+OXuZPlfTdWOOmVtvTgiO
x8mnmZoo/nRdaNilfbZ0VasHfyRNv3WiQq1TrolCe7LSoWK2JpkkgAdFMpim0tnU/MkgI0ujlQBf
WP27024YOViyMRgJDg4pKTzA0TeQD37/rlWcUEC8acywZjOM+xJYo2cIgRNw1Z4XZpF2+elOWchE
mDC+XNnjwMNFpr8bxKkfkXcGSAFnYItIZ0Dlo6dtXpoTT3yAo7+6Olt6HKQ43wnjTFOcgYB7FDjE
t+8kBnaFMA34XLl65dDgcoOTGA4+XakxD2J/9/1qqd59F0dmkIdbnu46KV4qX5jXCmga0sMyAzZr
rASaVwJobyVr13oKWb/xB1n0bYpUloRfNMx2mZFRJis2G1kK9GOr2gdqgvoGbdyvpzq3za5DP+jN
Te176M54vWTk6yDe2StktX7HYeegntKeYRQo0j4/09OPmQg9kpKSU0s3QN9Ap0F/wPh53rBxqSz6
JkPKt5Y76Sa/iMjMVJ63OEnun/KMqyKgJgGLD8mZxtSHZjzok7Zd5TiNfD2YkNfOPQWBIHCZNjWj
jfRWubxDuWxydQhhkKd03To4IdPo+lMMkfThDWcPcZ8xKjtMQqBs05hh5CdtTry+UG4t36oTju4i
akZ2iqxcyqtkgCXMj4nT+q0EmlMCkXQUd4ya7bmufs2xSBhexzm+MYmrd8I7I9k36uONcKAzsq5K
lUrtUzRhGnAdbxT9rMCR+ndDxzs4kQQ84B+2+OdF8gEJUffgI/pKvuq5akNPAN7kKd2rQkI6hTAl
a7zPpMboZ+eZpPRsWfGVcV1fY+gLj8tMORssW28ECeBJ68hL24E5G4E24zw3NR3+RDVcdKjreiWe
dAAPyXi9EuUP1/EH64MbPBO1bhy6NiyQ28/fR8a/WheV8+XVR2HHywl3vSP/vu5wiTSZWblumUye
P99FNPNdWXH7oTJ9wigZOXFmROQzJ48X2Auf+kweOW//WjDxwEddQ53oHwNj7OQ3ZetXyHMffhiK
/m793XJU97xQ2PRsmPeCjOh3lkTmUCEXzJKJY2FF7n//ZxkzeEczu+GvktkPnCdDxk424sLehVOf
kAvV/t+YcdLZHEM7ILV5COdseR9kDw2Fb5vUqD9Dx79p2kdq10XL09qaKIjUR1sTf9ucFyr6+gqO
N1x95fnTYy3fny9auKn4mpo/Gl023kogESWABx5f1uD670avrizVnalZzukjDhLpoq9wsOK/l7sG
O/x09xy+gQIYGJaFSTHvZw2wKxA7alOdHQmA8+MrqSjRXXruKSjg4sQUcDk0pGYjOmjcb0Lg7kYn
TfG5Ox28k3YlOlFVXa13GetDHrtuYCADGNCekpbj+N0/vb/S2dHm7soBHMqu8F4a6RzhRDzyw8Bf
7d12IfWVKz5eKvQuzfJyl64KFZzJ6dOXPyYnf3ar9CxwJ+pQJ6Dto5ee8Az0OhTleV7iXZ4S+4WM
NFo3+SSANoi+5+z0FW+/W/KPsTL8Hw3gqTq40z+ob9Cn/HqK+gH6Bn0AO+hQPmDhVlbmSdFOWiYn
1mWxrNpcLjvquxLS/Qum5fqJYsTDmGOCkM7z9VH3GzThRdYy/baAaZZMulKOnWTG1OPX/M4uaIe2
2nqZ/OIkJ2kCRocXvcvWlHi1LnJAH0XU2xW5UoT3PMol4JZbrfoQeJ3d2L6LAxpef+6pKmhE8OQ/
FVZZXqzlZDv0gR/qY7h+g7jqzcvl3ddfkxlvz5IX3vbsLfaDa1h1sXPaLryYzXqNAGyjrASaJAG0
LVjonUg7RtH+2a6hI6PpMfQDGMASn9NuPXoHZWChM7xTmOMY7bqGca+Z5Q5j7jZG/3bGManu2IIZ
4t2/6xvv+MdZOJFUXe1eswv9U6b8meaAXQsd+YJ+8EI+wAv8kQxkh3TgA0y56jnTNFg/6zMJpyoy
tfx40Ee6QadTzyZx1h9dAnp1q3aCCOloM+F+EQEgIaJa+6IDx2HpeuoQ70Hl5W7/g15L02uWkA7D
9t/SlcK+B3fBs+PqWWzwUvvq9UfInw9eJTcdUhTih/hq0syJ78lywA6RJ8+9GEUePb+f7LjzjzLu
MAxewybe+ECnfwwMfYl4WD6zMnLc+iIlqVp/SEP9wZLfdf97WIoOvIRgYXfoUBku62XqewvCceq7
YshOUvPhSrliwA6eeOBb8PSlURcbTOA3H7jdDeJkv7PZztX54CNRDWSWnZEq+3d1F22ys9IkQ+9X
StV4a5pPAt4RRfOVYzFbCVgJWAlYCfgkwIGFf9BBMA4oMECExSCDgxDAcKBBeOJjvOk6aQR03NoD
A/8OZi3AKcNPB8PmcE6pAUEemkiPWaxChILgBXwRn8mbC+TiI56Qa+AAHAY35gCHg7ZQQeqpr1zQ
EDZh2Ti4M/eSP/z1pHCy/FOO73epvDJnsazTO51XLp0v/5l4uVzwwCwDZpicMaRbaBBsJFhvnCSw
9pv5cu8hRI8VAABAAElEQVRdz8tpl/5DBo6632OPvvoxuebvs+TL1RVxKi150KDNLvvko6YRvFyv
1gliYH+C6zER9AMm2Nif9aCypLc3c+whbTPCL1RmCvz6+uR5kQIuUz+ENQegw/rG6aNK2/I59U2E
I18dZrkuEige6BmYhupDD2bjYlu/noN8PLzoiQ/KGGXD3/T60+v1FA/xwvUYJYD1ZNIHP62bXi2f
Txkvu/QcIBdcMyGGxQa3FEz+0lCeDFvXSiBeEmDbgutYb8/SYjw9zSm21ngrgh6LrncwzHHLYv+h
65+wSEtz9RdwcVGCfC+Lg66qq3/XN94hHa7r8oM+y35LuRKufdvckL4AP7SmvvcMoZhRXcpr+aee
S5oMiBi9qp+rVPYOnT591hT6YizdggUlwPo0BWL2MtNvwiSSn4sOrfWbDtpNnN3bVToO2VxaJVtw
7z5GWNE6aYJUjrtlzCWm7/BrZfL0T2XpyjXutZ8b1sjSL2fIuOFeYsf/9f9kPRj2Gb8OM5NH3zlZ
5iz+Vn76aanMmXa/DDET1X/LkbfLEg6Ag2nxwGfiMP2+4usJRqjHsgVyhW+xYchlj8jC5euleNo0
eXHax7Ju2Ty5Z5T36s8rB02U5b7SAqvflLNHP+qNHXKZvPLBIlm5cqUs+Oi/csupfULpe4YWG0JR
Ceth+0/TcW5OZpqz8JCZrs8zfGXdmmaVgD3h0KzitcitBKwErARqSwADDdP6IdLSM5zTDfn5+c6L
XXa2uxOVD0vcmQsTYYxVa0CJcjDZ5N/x7+TX+EAgvEsCE36mScvIdE5L5Obmhib+gA87BvHS533B
xs5q3Ble40xYhfkzMWL3YJqDEy+q3BkNWODDfcXeBz9OTeCuZHdHMfiIxEvAd5WUy7N3ANqwcpUe
57SIKw/s0Cso8OITeVeuP/tdL3NG6IIH/ih9813ZcuIUE3msQwPUehshgarV8+Xsv8yUTVHybtpQ
Ih999qXaYnn5yeOkSxS41hCN9g7D/oH22m6Pnh7W+o++ST8QXKR9NLxDFW0RebATn3mRSb8YJTsd
OExydNdrhbZZGKQHi3HC+EvPzBLoJuoHtG8YTEahP9fUbJFqz3fqvpbVxZXStVCPMis+v6G+od4D
feAtmr5x70h39QngCnfFm0/Y9L9gnJyzbzvtc67+IH2QD/kGNMpJUbl0H3ikZCvPNXrncST6TH7Z
lyl7fHjbY/QFBncnQxaQEcqgnHFFnF4hGzZKO3ZNg0/AQXbt9ugVTldfQ+tvx/5DJV/5rFZ84Lfa
WAABYuySA13QTaw/6mPEwUAGC5+7So4e86QTNv9+O+Js2b37LlKgC0hVqVUy78/3yowQgMsP8kNO
kBHlFAKxHiuBOEgA/YUGbcy/mMDrFgkTqV9T77AfACdwRdM7OBlaUxNeDOUJIeySDJtUydSTX9nZ
7jiHE/RIx/itQxP1c739u4HjLJxI4jgLesr/LYx5X/0q5+7b0dFn1BPghfKsrq7w6jQkOvURXmBu
00T9vOugoxz9jGcSvqtlmkbRZyKw/nolQD2eqvedp+DOc58JaJuDTRbDRYfWcr0SdaGjv3R5YUtZ
tWzSKzTf+uIXSdeTDacP7CZZmYn3DsKxAfROB/2I3+mn7yEnXnGBHNGjo6NfavTkKb5BA5PdqZdc
OukDWT51sDzLhvbaf2XxxlEyoI3b9jB+Ak7/STYX/BB54r0n5biebUJjkq77nyZTvugkp/zmDOOa
tsfk1dk3yx6HdHLg4oLvw/Fy9aCiED6SX5+rrPhMeP4ACdDBS15+SF4woAb/8d/y4tjBkhao0G8C
BTddZe8o50yYJkU1x8h5T/PD6HfJSx9dJdcc1N4ZewLF3BceFs9ZiEE3yxdTLpHOmgY5tO+2j1xw
31uy34BxcsJVT8k3zskGo/AE9XIsivEtn1sgFfGwiEffYT9KUDaSliy74JC0VWcJtxKwEmitEkjR
hx9eUPEQ5IsqHoJ8YEZ7KGIwYD5IETaNL+gkmTC4z9A0LNOkBfAYGEZ6KKPsQMB86TaxuX7w5n/A
Y4AIEwknyoNFmkmriy38b6aZfkI0tFxTjjUb5sjNF/6HqOpx95Tr/v5XGTm4i8NnJJ7qQWCTY5BA
2dr1URcbvNnXyM/6Tdsuka889YK2khDabqYuVppmr16DZNiwbo4+wUQ42iUsYDEBBpf9GhNKnHQ2
cdTyB3US9QPyoO8hDJOSUiKrzJeRgwfIbsHrlGrh0gjqO+oH4AE+0uXNE9ZVoB1wWQU+nnsOkqFD
d3Qm1IkTOIAPOgcfc6WuQHp+vttIiE9Reo2PX8rPoVMXGMJTn8q7/kx+AAv5oFz4PcA6OYAyaQCT
medtsA2tP8qOOP0uaKBMAAvLMGFTf31HRv/Bu9hw0QNT5aqT+0uhXldAOaL9DM1dIjNu4hcswi/E
lC9xWtdKIJ4SMNuX6W9IGewL7APsO/XpHacfa0H+fsOyzTEHywCNsJl+XdVA/UwaWZbfNcvmREpd
4yzkhw4CL3BNfYS0ksqy0DOD+AiDME6zmfrPVHDkuen6OdeRHfjwLyw1hT7WI/i0pj4JmA9F04/n
PZ5r3lZQH7aWTm9tiw6mPLHJoFKvVCrWhYd0fV773+9M2Jb2U3d3HjhaHu6HxU93PIp4bJiAIUxa
2m5y2u2/lWfHvRkkOyDpCkd9RNhaJ1Sltzz28XNyTPdsZxxm6sOUoiEyYeIIGTz25SBOkRv/M0cu
H3is830I4G4yvlfmyBjFF+uSHPmlS8IQpnXjvpfHznmcyeqeK3dcPES/waZ60pAL+mdKSoYcfeX1
0vvpc2RRMMcL0z+Xqw88zAkFAsvl/66eauASeey+C6RIdS5O/8JAFii/57E3yOupGXLcWPM0RFgn
+On2IG3BAJ5xSr6elnOJyNBNl+bzqgVJa9VF2wWHVl29ljkrASuBRJdApIdyut4ljEk/7kDlneHg
BQ9794EZfrCTx6yMulR6/cMc/7sC6EDZoIUv46AXNGAQ6D2NEKYHMJH4Ap24ZoATmnAxCMLADxZl
eXcJuoNMpBFnNLyUAVx3YOV98WlYucpjkCbgWzlvpkyHxzGnyFPTzpfU7/8nc774WlZuKFXacqT9
rl1l316/kf0P2FvaZ7mTEJjYxcs4ZAdrTRwlUFdT9xXj23vuS209QeelSNst3Br90LlpFn+7QvvY
zk4/Qlt0JgcUwOxX7DdmHPyIj9Tv0jNynD6LfgucaO+ER5/dunSxPGQuOOjOfme3vcJGxBfUN9B7
wEc9F1nfhGnHxCDwVeqLtWm+/v4Xje/iTIwDF+iDAW3ASQP+kG6aiPRpfuCgPqRcgC+1UhdxDASY
8KOe4wkHh3eFrahI15uuDaMntEwdB3918PsxhGps/TG/38Wubj5fKG+2C/K1ad2PstDIOOKON/Qo
/X4qO/0ekH7XBvxAjtgJXloalqfWjHNCjDKGLCPJ00BtvVYC20QCkdphw8Y5Yb1DnYH+Apuhu4jD
RhcYHX2R7uhIwrJP6OdqPKap/VuL95iGjXdcntCfwQdo9E/oz1iyUgIYC+p4BnoN/ECWLix0gepA
k32DGuAFbGP1s4EqpEdUo5jR0hT6gAh8WxODBFTsGBunqPVVgU5uYpyQfHJsLYsO1G1wYav0JBYs
jTOu0HqjLmrpNk96oUMcelVPgEaeLIOLeIzvYAjv0K3fpwgbHYPopofqPPd9EvDAWVbmVbJ/eOJR
GdqhUnf8uzIBDAzxdu5/pPSUl2UJEX/xo2xWGrCNJT74VsgWpa0gqGNZjMdVfkkXdWx5hZePGtSr
yooLv+XLPpMHDCQD/niSdK3eKsX67Q4Y4iNIev5v5KwjRf403Y1ZMHO+rL72EGkPnb76a/FcTDrg
TtmvXbls3erSBVlB/nBRPzsPO09uGPqo/OU9Yg+7Ld2+SAnpgAsLueJ7lis34bkk0q2Tzm/gGw56
OkuTrWkmCUQZHjRTaRatlYCVgJWAlYBHAnwYmpEpKeFTAHxAcpAIuEh5ED/zfz/AcQwHUQjAv27O
8/LH6DcARcEZ3gVr0gE/rVua998s25uitDsP9fCDH3wRl+P3TNvFb6KqYeV6qV6z9NtwRP/dpHe3
btL/iFPlmpvukL/97W9q75A/XfZ7OfKQfZzFBvIDN5Z6CyO3PiuBpksA/S+ne2/pb6D67JH/yg+6
pQdpfst2ynbLPmlkj6gfbrtukvxY7V7RhDy0xPPN+/82Uche++0k3n37nmQNNEzf+PnI6dpTDjRQ
zp00zeGZUYRHmDSavBMuulubPuIx+7mb3wtLuLBbuxS8GJLGnO69mlx/LAsl+V+k3JcrVw9zcceE
R56f5n0IJ2QOGtjLoQ+TAqAVFn5rrASSRQJo47WNt6/69VjkPOGJKn+/cfHrVWa1C3Ji0MfjoZ8j
lxssvQnjLNCX231f/dCoYaa8K9+WR9YXkNeaj5+WcTMM+AjeeOlnhz691uM4s4wG0xduB9Hq10Rv
/UEJqNggOUd6YRF6xgfJKE8uOrSmbzpwLIGag5/G9DMuEVzSy7EFwzq7rhPem2TdunWydu1a2bhl
rX43L7QsoKSHJ8ORh/n9JxI6t80OjVkAQ1iWU9W+hxy1lyGJD1bIqnJ3rAOYKt9Yp+H4fpRffRuB
jNJqeUmXf/GX1wQyvWTNWk/eDRuXyqJvFsmCBQscu3DhQjHtokULZIV7Q5WbryBDT0O447nNK74y
rpUSOfiIvpKvfGOch/JgKF+E4U8PNy1NDb+zE97JlEB/0E84+YErxzbrt02qqkGzLqL4V1ATiObW
QIpdcGgNtWh5sBKwEkhqCfjfgXG/NncMY0ctX4Dp8kUzPcM7fffWDc/LotLwA59CWfXJo9L3xHEM
RnQjDQ5SdTcbdlHQgiZYGuN9w4kCDhOPSyehXRe8+vEBJ+IiGeI03Uhw9cU1rFyXD5aZnmlgn3u3
XDb+cZmp3weYv2iRLP72W1m6dIX8tGqVbN68WUp0QAleUG+w8KPeWGdwrbESaE4JOO02t5f87hSz
lFdk4rOfOf2T7RptEW2T/Ro7V2FxPQZc58SRtmG2XROb418ySQYf+4B8X+rtv8CXunqmXD/uHU+W
807YT++UDb+d+PsC9Z5fPxBJrZ7j0zeS11POPI3QcF+W+5+b5+EZvJNf9E/w6J5AcHciI47p/q4a
TR+68NrHjaJT9CQX5UY9QLyOPjBgTS/oc17ocnrK6U2oP55aYP16v7ejE0Z6BRToMfUuwoDHy6Wz
g67DjiZpsnTZSn3x3+pcRYXdbYABbPmKWXLPnW94YNnG4FpjJZBIEoi1X5Nms18zDi71F/t5VWWJ
kfyuzPl2c0gHEBYATt9oon6ut38r0X496u/vBrG1dGQgs7sM9szovya3PfWphx/qs18/fVz6nX6n
iU79YalRFzRFP6fq1R3ghzoqJXvXJtLnI9cGY5eAnnDTYw5heN0gpQ+UUJj9IRSRJJ7WsujA5ze+
2+dY52od90QintnmhHEiPp8xBgkUr5B3X35UbvrDWbJn796y3379ZeDAgTJo0CA5sN9A+f0jXxut
Sq/70W/QYEwCC/6ccYnvOy8lFSVOOtsn9SN1c2VlnhTtZKCVxfLr5gpnvINrI/3fhGg4vkWySvFx
3OTqRbM81099CTic1sBpUtMEgvyR3/KAd2l7yaQr5dj/d6ycfPLJjh0xYoSYdvjws+ThTwyM1ZV6
QrXUuVq1rCbcjwFxwK6FjixBU2gsabzPGlhCXsqTfIQSWtjDegcZ5ZUB+ejbdfLhN2tlg554KdGF
JdBrTfNJwNuymq8ci9lKwErASsBKIFYJ6BsxH9p1Zcna7SC53NyRIZPlsJF/ky9WFjsPz6rilTL9
H5fL3sP/VBcaJ62+8sx0DDzMcL3IfQDIa+an33HD76m+XE0PNrbc7gfq+VPDzH15olx69hly4nHH
yTFHHSWHHz5UhupA+OCDD5b+++0tex5/ifz12RnyS4W769tfroHKeq0EmkkCWTLoDO8i48z7zpfR
D7whKza4HydGP+ZLRPmm1fL5rCly3bl7Sc+el8pXpeFFsjoJXHyv9Otyhvxz7g9S5gBWyYovX5Wz
+5wWPpqO+D2vkmH4gENdxtAL1AkAj13fKM9njveUMGviKDl/4rQQz8BLnss2/Sqfv/cvufacHtK7
9+UOz5QJ3KYas9+b/Jh+swzvC4/y8rum1R95Mcsw/UgnjaTJpKFwB8/bt0wa9Rd5b9mW0OSkvrbJ
N7OflwOPu0Lmmoit30ogSSXAfgDy2T+isWL2FcAU9ejjAb1TT4DN12sb9LZoWfPD5zJt2oeyMTQ3
1HT9XF//Zt8mUeTNcesdZ+VJ/+G/Z1bH/eiOk+SaZz6QNa6il7LiH2XafaNl3+Nv8sBFDzROP193
zp7Sp4+rn7Hg4Bql77h40xedcptiSAATc610cq41LDpAL8Hy/v5U3VwAy53xRk0mnDclpVrm/fNm
2aXnALngmgnywtsfx0QjFhnIN13EeUxQLtSLXIBlGBtt0tubOfaQNhnhiWj/iQn0AZTF/PXj6yHt
MsN0miXV5ddSPMl+Xpd/aq4eeEBjCywv1+8Z6DWYunnEz2P7trke/sCjn08dUieVQZ1V6yJcmW4O
LKtQf0Dr2JFxkjGSVFLXDRBJRq8l10rASsBKoNVLQKfjQw95DmZMly+aKSk7yPDfny4PXvPPsEw+
vEcO6XFPOBzV5w6W8PCNZkw6/DCgx9jE5k+OHjYmFU2gEH9mZDz9jSiXssnY9SSZ9ufZcuyN3o9p
RSVvyTvyj1thn5Up81+Rk3qF78yPmscmWAnESQLoS9ARuT1Olr+PekkufTJ8Jdinj10vh6uVXgNl
xAG769dA18iiRW/K4sVm4XqqKTdPd5S6k+58wTEhvP7X5fyhar2RntDNt4+QjsEFDtDmvqh5QKD1
QnrPmxLcTVzP+wD4zt/rVOX5BQ/Pcx69Vo5U6/DcbzeR0rUReNY+mpWtJzvE2QXn0OdTcCZ9IX0V
1CtOmkG0P91IcryaLaqhfs/bs/H1l5aTqyeswnftgh6PId2GC55hnRdPfflM3/EAGa2ZnghlfE0u
OPI1OfKMi6Vv23L5eNKTEu1Vt1Z5IRzWYyWQWBIw+7WfMqcd+7qOH4bhTnvtL9j/Edp7u/ghvaLj
ISarO1xmrxoge2ifa6p+jrV/G4U73pBe8icYYcJ0OuRMuWrPx+Rvxnd4nr12hDyrqrR+Ex5XUhfA
bYp+TsvOUf0c1lE7DG4KffVzYCEiSECfDylp2mPUYsIVJqDXd8E69ax1nOyGiw6X3v1vWb2+OCI7
m4rL5KEps520Yw/xLjRGzLANIvHsNk2qfhsqPUWvR8vQU6y64ICqAQzGc9A/iWKoH3ASdP4zY+Xo
MeERB2n87YizZffuu0hBhp7USK2SeX++V8I3uOmYJXhyA3xh/OKOWZnbddMz3e8i5ubmhk5KIQUT
6G6eLVIdXEx1c3wtq4srpVubdAefGxf+byy+HjkZDpL6xtXh8Zh34SSgk+U4/QC6Ydrsuqfj8q//
BePknH3baX1nOn2Sdc3TLfwmBuSeUpUiuw46SrLL9YSIyq7Cdypk3le/yrn7dnTKwqln1hVoh6mu
rhCogmQwlDflyjaCq7JgEcZYgHJNBp6SiUa74JBMtWVptRKwErASUAk4A4XgwL7rcVfLHbP+KTe9
Xrdoel76uPxtyEo55vTwrtnKurN4UjnQQKRZvgkU2rxnRkbx+/FFAYt6D3I0+PriYy3XK5vVMvdj
72JDj6FHy775qbKupERS1RbLRpkzJzTVECTjAzltn7/I95UTpFt9hNl0K4E4SYD9MyUlXQaNeUbu
y7pRrpw0y4t98UfystrIJl/ydLIaLyp8iaVrwp8wdqyUTpwob5uREfyXPvyGnNq70KM3zH4YIUvo
xQZp5McPxz5KXKAXV2+A54nK89hG8Ay1avLtL7OusHmhCuBIVyR/hQ8RdCfh4boviWky8PKntf7+
1OD6y8/E6QV3goF4fUVGDYZeyDJ3k8un3iNPDPfOME5/cZJM9+U+9Nj+MnNa+JwD68YHZoNWAgkt
AbOvwG+GSXiktu3Ate8vV1+4l1z4qH8cwJyuS7xN0c+x9m+TftPvpQhnMCKZTnL+U5Plm0FnST3D
S+k5epLcfdRaOb6O8WXT9HOB5KlOS011r/Zwn0fxpS+SBGxcBAlgYpuLDbozGJN0+Lm7hCPAJ2FU
a1h00DUGSde/gmzdlY6A1lmkcVzCVM/Kt2XURd7FhosemCpXndxfCtPcj0djYQDXGw3NXSIzQi+9
Ll8ct0TlJziuwoQydBGuVEIeTjCnpJTIKmNxVQ4eIDiUG56o9mFuKL4BA6R7jnvCwYepUUHym1WQ
78m/V89BMnTojoKFFVfnuotLWGiA/Mp1cYHtAOn5+blO2F108S5alVSWOc9APDsgL7iQBwzCOBWi
Lcsw4VBdzxsjwzb3Um4omHII+8P0b3PCWnmBibPE2coFbdmzErASsBKIJoGMDO+AIT8jtrVgDJTS
0trJ8br7ftL1IyOj7zVC7n7+bXl1zGBpr7tDwmY35wPH4bDojtjY6cCDOsP8toF0lJwIZKen+3A6
gxSzVK+/MTgLIuBMT9eRomHyI8AYyRF54cDki8eulluM9Yajb3xaXtIPRd88YYI88MAD8tDTT8sz
z7wq33+9SGa9MlF+ayKWe+XVee41JJ5oG7ASiLME8PLAlyn43e8wtJVDL5oo77x0v1x0/EF1lthn
8Gly630vyhfLH5S+ue51S8CDF4dILw/7Hn623P+/V+XWkQMj4t1r+IXy5NSP5eJDunrowosK8NbS
DXXovdr6poPu3HPpAj5a7JJLTc2XQ/9wv8yY8qBcOPzAiLQxss8hp8qtf3tBPl/2oOyd5x4XB22w
DdGHqj0ll0jVzc13X2aNKI830wTeNV+yNRUyNusP97RnZbWLS/3V4iWCPqS+wwul+/JZIwW9T5ZP
3npaRh/q3UUXYmbAmXLP8+/Jg3fdJmeFIvV0Rcgf9jSkvsO5rM9KIHYJ1G5jtVtibZgIA5dgkbX1
TkfJDd7qQ71IHYlLAwZf+azcf+UpkQk+/XDpklMdSounfo6lf4cKVk+kcRb1njuudHVhWrv95M6P
X5fbLzjWzB7298b4crq8dv3hspNeFxI2Or7Mjq9+7pPj4qOOdOhsCn16mg2Ges8N2X+/BCgfus73
G0LfcMBCg8rQydS6Juu46JCMH5LG+kJeVqoU6QeBh+1VKEP2LNSwO2Hsr9+WClN/svwta5fLQgbU
HXHHG3LLqQdIvl6zhN35sBiX4NsFpaWmrgmfcODiACfFDXSSnpHjfLML3+2C7sX4yrSyerE8ZC44
BNJDZaJcv2k4vozQxH4kfH780cL4hgPHaMBTqR8/Ns3X3//ilIMFBljAEj6SXJCXfdu/aDhjyUoJ
BOVFmeXk5AisK7t8HSubpXv9kd4bvBDNHyJvlAO/fcF4ti2mM775Kdu+Sog+ytq+5GC5tRKwErAS
aDEJZO1+vHz91RGypbRCMnQQ1L5NnmeCz3xom368ILoDiEIZdNZ1suTsK2XtqjVSju1qOvGW035H
2alToZTrhz4xMMnsPlw+/ehI3c2WJrkFudJOnwAmvmylY8nCI6S4rDJERzShIN9uJ98rC397m5RX
p0h2fra0Db5gmnmy9jhRcQ4J4czFnSV1mN1PnSgLj7xFSvWjTvlt8yUr+HJvZsnafbjiPDyEs11h
bXm55Q4NwcRS7oIjxjvl5qn8dTOdYwKV38nL98wJFz/0ZvnjyX3DYcMXSMuUrvseL3dP/l7ePOvB
UEogUOEM6EIR1mMl0IwSgF7AZAz6KCfDinoNk6vu+a2M/XOplJZslY3F5UGYTMltUyhFHTtKgR71
Zp5I5PlfRspLSqUmZw85944X5MzrN8jajcVSUlIhlTqZ3aF9J8kN3lcLnMRLeuBm7XacLNZ+vLWs
qkH6RsE9+ob46YJ36MVOvQ+VsXcdLtfcXS0bN2yQrfphOMCkpWVLTmGBw3N+dvij7n6e/XoGepkG
eGBYpmT3lHu/+kpu14/vSXq27i5zj7MTjrCumy+n3PeNHHnLJqlOyZD2hYWqkcN3xkM2hKe8mlp/
0IeLoYdLKyVTXxbr04cOAcG/3C77y5iJ/5LLK4tlzZr1+vyAzLKkoKizdGmX4+w4xPPl6rlz5XKd
DMhu014nN0wMrj+SPCPJp3bOBI0pXyvvvL9USjLSIi6wtAjVlToBUbiDHHNQV62l1m/M9oO+kt3j
pHrHG5HaYTRJAb85zskpyJE2WB1Uw7Lhss+KFMqh598s888cK1s2l0uJ6qHcNh2kY4cOskOHNpjZ
kYogPPPB3db9O9o4izyBP/CEyRfJ3UVOGDNBzrjyNlm1crVsrcZirC6wtt9JduxUEBpfpnY/Xk+C
HiWVAb3OT8eXHYMLwsBp2sbqZ+IAbTBNoS9Px4wdt4cO4ooqvv9oE7Bq8BTE1C9C8Lux6mklhosO
yXK9Evsv3Iw03TihNVKQ7Y7rNMoxhEm0Kvpp3ocekg4a2MvRPxhbQA9hTAd/LCYSj7fpN3WOfOOP
snfwhAP1B2Bhv3n/3x7Ue+23k4RHfJ4kJ9BQfD2D+MBLJPpqlxA9xtHLweTsXfYSbKv5NBieO2ma
/HDB/tIzuCHQhCWvADX9CAMut9s+cpz6Qyfaprwr3044RfZTXc53CtQD8kJ+az5+WsbNQG6aYCPT
YFN5JMZ4uqYscGNsqvKBODM+nuVZXGEJ2MdtWBbWZyVgJWAlsE0kwAc9HtiweJBLVq7k64Q1H+T+
hzXj8WB0d/G6L32Ix+5eDAIqA5nStvPOThjxsGXFxaFdDsibphP+ObpjAWWyfDIdoiPdnZhjOnER
jvGAz8rTu951EIhhBuBg6BIuJSNb8tOznDLNcomXLuEzdEIsPTsgmYrfhHeQ618kOlkmYIAHMA0t
N1OPoGZARsF6Ac7qNcvkCxas7kUjD5EcDFDUz0EKXewmQZ6aXO+jFR9rw0AZdJFXA6X1Wgk0SQJs
+2xf0Acw2JHEe1vRRp0XBZ0Mb9OhQNoVuboHeZ18Oo1cXu7e7YsdYIxHvrD1klldWeEcz3ZgdfdY
x875DizKQZ5KnfxEGvQV+iPwkkbAIL5a+0R+Y/RNkG7gI07wi37GnXB8UcVCYLuiLtJJyyNf4CTV
4bk6pGMoN8DARtIzLMuUBHiFSVH82conYJDXDxvC6UCn66JEoeMDLMtGBOQE2ulSnrHUH8qAHODC
gDbQ4VitowKtf5RH+hBPwzyIQzrCsAij7NSsQumySxuHLsJC57GNpSr/eLbkZHrxUz7A6TznjPom
HtJqhklXYrpb5enbJsujKxOTuk9Lfyd3DNshMYmLI1VsW0SJ9hPtuU+YSO0QbdzJG+w3gEUc+wLH
OegtbKN0AQM62F/RJwKZqmO7tJcOmobdoCgTfRp5AA/DcVxz92/yRZd8+cdZoJFp8GMnKMLo3+Cv
XM9htd+xm3QOPh+cON3MAjjw4OgITStQi/zkFTjgb6p+hrxgIGfgh5yp7xtKX3qQPsoErjUxSgDP
O9igCaRo+1fbWk2yLDqYbRh+sw+ibhBmXzRhW6re0Gdh0IehO9I77OghZemylbJ1l6JQHOHKV8yS
e+58IxQPD3DRehLMwJJJMvjYPPlsxnjp1Sa8kw1yCax8R64f944JLeedsJ+kGe3ck4hAA/GNOqlf
3fhqFRBjRF5POfM0XXCYQviX5f7njpV/XHiwRyYOnwY/CFdWqtyD7wuODs/eVQbrisProRWH1+S2
p86X/4wZ5Ohws139+unj0u/0O1loUrnp+uGJndtlO2pMD/7odyhcncY2mVTMJAmxrfcJkSQVYMm0
ErAS2D4lYA74+JKHOHNASBi6lBTChGVeuHhYYtDAgRf9zEdY5o/ksny6hAEO+OkyHi5gMXihYRph
iQsuLE0kfH5Y4idOuoRjOvEynfF0mU6a6BLejw/xMFWVW8MfgdTwux8ukZqg/JkXcOGBymp54a77
EBUy7fMynHoJRViPlUAzSgBtGf0RrulnkaZ+cF4yVGfgZQ6GafQ7kVH+AEsdAz8n+omT/QO0mPSQ
LqTDb7rMgyLhp8t4wpr6xsRB3IwDvJ9OvriSTpNnf3nEQ9ekA34Ylsk0ExZ+GhMe9NcFjzTKjC7x
kF7SD5f1BxiEAUMDXH6aItFlwjOPmY/pLJ8uYeH6/YyjS3x0GQ/c8CeNWb9M/pmgiw2Q4Yypi/W7
Qq3fsM2wHcFl26JrptHPNLqMh8Tgp8t4uID1wyNMWKbRZf9gP2XYxAXYbdW//byYdNBPlzSBPvLj
MKp/5Icu4wlLnhjvx0U40gO5UGfBH4t+Jg66wEVDuugynrB0GW/dBkgAzxWIGjb4jMGTJvy0aQCu
JALlokMyXK/EfkVXFRqUWkh/JZrYqRfb6GY500wa9Rd5b5l7HS1gRJc8v5n9vBx43BUy1wRsiH/x
vdKvyxnyz7k/iPt96CpZ8eWrcnaf02SJiWfPq2QYPuBQn2kAvkP3yA89W+pD27D0LBl05nhPllkT
R8n5E6fJig0VTploC9B70MVlm36Vz9/7l1x3zp7Sp8/l8lWp+f6eJ/2P+70H10d3nCTXPPOBrAl+
ULus+EeZdt9o2ff4mzxwyRJAW4L6wrdN8rN14ybkovJxtxEmCxfJR6d3G2by0W8pthKwErASSDoJ
8OWIAwDs2MLLEQYDSOOOYP+LEQeQHDzgDkVO8uElDfAw7uAs/OKMHQyIQzkwxM8ddigX6XzpA7xJ
h5NJ/1gu6caONeZBGsJI444JuAgjHvj54kkXeWiYDy74AjzpQxwtymO5Jp1IBzwMYBBuSLmkH+Ui
L8KwOTv2kMMV57sOZpHvnh4jl1VeJ5ecNER677GzXq+QLSkq++Ktm2TF1x/K47dfK6+b94AOuFOG
7ZLm1JOfb5P/IHrrWAk0WgJotzDsd3l6+gj6Ae0MfQI7UWGgK0x9gXbJ9g4c6AOwfmN0VycpRWFN
eLZn0gF9Az93+FI/gBZY9HO4pJF6ieUCH/LDgkb2e9CGNORHGvKRfuCDAX/4uCBg4Ych/+TXxE2c
gCMfoB/xpp5BXhrkhwEc4p2dzQpv4oWfeVgu+WQ5CAMOeMgHyoUB7YgDX6QfcbAsn3gBhzjgg2E6
2wP1KuCRRhd+lot8xAd5Iy/KZplIR5hlwQUMDHEgH3AQD+KRJ5o8UT5pdRAlwV/xqpWyKZHp1La/
RenLT2Qa40Qb2w77IfQJ+g/bH/UDikN8tHZIcti2gRc4/HqH7dts7+gfZvlo7zCAQZm0CAMnDPQz
+zHgm6t/o0wa8OTXB9Q/SKMFvdDboA/54UKuMIwDLNKAD/DUO3DBI/QNXKSTBsoFOBqqn1kecKE8
4Ace0tRQ+qjfyLODyP7VK4EU6P9g+8ZTKi1V27Pa2iOGelHVCTDhqXdk1brNdcJs68SC3CzZuLlU
Kqrcducvf1NxmTw0ZbYTfewhffzJ2ySMPof+kZ6BE581egrVHQOinafpNUvUP+yT24SoCIVAF4BO
9GHYtC79ZLTCPRGCfU0uOPI1OfKMi6Vv23L5eNKT8kkozetpGC+vy/lD1XpReEI33z5COgb1IXGD
1sgmNnwdgpmBjzgj42t4bN6ep8jfR70glz75bSjznEevlSPVSq+BMqLfbiKla2XRojdl8eIQiHp0
nJado8849xmFethh8Jly1Z6Pyd+M99hnrx0hzyqq1mAg++yMVOnXzV1QytZ7mzP0fiVcr2RN80nA
Ljg0n2wtZisBKwErgTolgAEgDF1O3NT3AoQHJmHMFzoO4FhopEEN4vjCibwIE44DVeRHHMswYZCG
eAy+mB9+wtAlHFzihUuccGEAz4Ec0mHoEhZhPxzCMHAJxzjiRj7SSRim+fEBF+EJ49CV1VNGXXu4
vHvPuwBxzNzJd8v5aus3B8nzfz1F2qh8yGP9eSyElUDTJGD2CbRp9He8SMBFO+SkD0sBfCTLdLoK
Ra/jpuo1CpH6FXDBUM8Qhv0YaaSRcHAJR1oQB4N49mOkwY84GBOW+AmP8k2d6O+DzOt3AYc45mc5
kegDHA3hCUeX6SwH8TCgF4ZwSIef5TMdeBtTf6TNLA+4gZdlMs0hRP+YB2HAER7x8MPQZV7mQRh+
5DPLADziKR/gQJg0IJx0RuskoY1OLqzeKtIlhk2aCc1HA4hDm2L7Y7tlm2RbhT6I1g6Zn0UiD/Eg
DX7iAYzfT3jiR1nIh3jiZphlIIy+Ahf5UEas+hl5TDrM/ooyaQEDWOCGAZzpEo50IGzyjTAM4ogD
YcbDD4M08kFcCJNOxhE/5UScdF1sYd1OHHSZ38TH8k0c9dGHdOJkmdatRwLBNudA0Q+X/nqyNyR5
7qIfdcEBy6bJZRJh0QFdvUb/qmoCsrm0SvtqivPdJvbFRJIo+ixsTeZucvnUe+SJ4d6Z7ekvTpLp
PoIPPba/zJw2NxRbGfK5HlMPMOmEsWOldOJEeZsRUdxLH35DTu1dWK9uaAi+0/ro93uCJh51YOKA
HgwEMmTQmGdkYtaNMnbSLBbluos/kpfVRjYFkqcfLExNdZ9trtw6yflPTZZvBp0V/pZD5MzSc/Qk
ufuotXL86eNCEP66CCUkgIdyw7XJuPoT/GamYzwcHscnAJmtkoQEHzG3SplbpqwErAS2UwnwYccX
IQwU4MdOMvMlkzvO+ELFfBQbX0ydQVrwpRb5sUMOce6gwX0hRF7TAgdftLAjj2mIdwcu4V0cpAPl
EQ64EY84GISRBkN4hrEDDXQBLw3KBhxgiAN+xHMnIdJhGG/CsTzyCDikIz8sDNzGlAs8xAvXvSM4
RfqNvlseqblLLvpr6JJMp5w6/w69RF6+4xLZu2OKgwewwEn8dea1iVYCjZAA+53ZjtEP0B/Q7kz9
YLZD5INlP2L/pD5gun7ywGPSM/V7MKq70G/N/kd46gMzHWnsB/CDPhrCgw7iACziEQeDMNJgCE89
6ccL/Qb8mKxHGssibrigm3oQrmkoN8axPNKHeOBlOYBnHHATL+JJM1zqe9ID+gFDPgADvNSHpKMh
9Yc8sDDAi7Lg0iAN/KAswpFG8IfyEWY+uNw5DhyE9edHmPKJVZ4m36TPuk2VQL4URvhwd1OxJlJ+
tkG0X/j9/RC0Mt6kG/Bo3zT+fo08SEd8LHoHfQN5cGIBfuSBC70Dg/JgzXJYNuBIT3P1b/IAGlEW
9QrogWE8wvDDgv9c/aYV6KP+YP+nbjDz0g+X/Rn1gfKoD4CLeeFnfcWin008lFe86AM+8g36rYks
AdRdIKB1WK1TirB6pgFyq6rGLvXghKWG42WAO1lNSyw6UF5wtaZkS1m1bCqplLe++EXS9WTD6QO7
SZZOLhMuUWQLXQAdALeg98nyyVtF8thf/ixPzDS22JPYAWfKPZdeJEf/pkQmTDtaJjvx+u09ptfh
7nv42XLGyENlysS7ZPzztSfg9xp+oVx/4fly4K4Fjt6CXqDeAW1+01B80IPQjbAwqIeMDO8ZxPyg
TjbLSk/3wuAbOaALeNAn+VypqMiXQ/9wv8w49H156bnn5NGp/Iy0ic319znkVDnt5JPk+JMPk11z
oO/D7/+O/m63n9z58ety0BOTZNzj02oj6D1C7r7xD3Ligd1ky1cvGum7SfvguMPVF+HnrAHUIl7I
DDTx+UwizHpGnSRa/yCdye7aBYdkr0FLv5WAlUDSSoAPNjzg8dDDoAZx8Nf34GM6YJ0BgjN4yXAe
qHiowpj4GWYcXOYjPB7E8NdFB/MDH+GRB/GkGy4M8JA+wDAdsCYeB1j/mE56GCY841kuB4HkgziZ
j+kMEw/Lo8t0wqMc2DC+Ahlywa0y54SzZf6nn8r/Fnwj33/9hfz8ydfC06m9evWSnfbcV/bbv7/s
229/6btzO32xD0/wsSzrxkcCdvBStxzZ1tG20T/QtvFignbNqyeIge2f/Ygu04krvaCTHKSRc5yE
/tK5Ta7TZ/nCg2jAEh/6KcLERzxOdv1DPGBBm5kPfhrTz37Pvsly4JrGxEsY5OEEIHGSPsAQB9MA
z/Lqow95kB/lkjbiAV300yVNpNkvH8DBAhfxNqb+WB7xAQcMy2c86TBdpgEWcqAMQBPxgG4YwMAw
D+XPOLixyhOw1sRDAmVSgvnu7URRsu2xv7DvIB6GbqztkPDISz2AvIg3+4+Jm/2A8MTB/o10My9p
RPq27N+kAeXDMAx6TUv62P8BizgzH/PDZV7GmXiZDpf6ATwTBjjr08/ETzfe9IE2a+qRgDl/SD/6
WLCf1ZN7u0rGosP9L30gOxa1lf322mmb816tpxsq9UqlYl14SE/T53awv29zQhpYYG6X/WXMxH/J
5ZXFsmbNet3ngg1lWVJQ1Fm6tMtxrmKDrrh67ly5XDfZZbdpL3kRFtex6GKa8pJSqcnZQ8694wU5
8/oNsnZjsZSUVEiljm86tO8kuZnhBVHoGOgm2GimofiIk/gQztrjRFmycKjWUaVk6Aa9XN284zdZ
uw9XmMNlS2mFZOgGn3YF7rFF6kG6fI506n2ojL3rcLnm7mrZuGGDbC13r8VLS8uWnMICKerYUb9d
4G7SY164NODZ0fG5u8gJYybIGVfeJqtWrpat1e6ieW77nWTHTgVSvnWro7NTux8vcz8+SioDqZJX
mCcdE3zM4fKn32cMNo+MAHgP8085WDe+EkjwZhFfZi02KwErASuBRJAAH+54kYPBQAEm2ouck2j8
cRCEiT4Y5Ede0xKcZdFFPPMzji7Lp0s4usTJcvmCyHjC0fVPTLEcpjNM/hmmXBgmPMsh3mh0Mt2P
l3iI159uyhE4cMKBsCg7u01XOeiobjL4OHeHCXYKMh20YIci8wEeabDAi7IZRpo1KoGqCtmoO7Aa
atLTMmTDhlg/iVolazZtdT4Qp+9dDTT6UbHC7KSbs2M7Zz9FGO2Tlv2DwjDbJdsr0tC/kQf5YXN3
PVKe++abUL/ADlP0VezYRzr7LfzAAwPXjEcccMKw/zGMfDB0nYD+kY/69A3hmR8uccOl34Qj7ybf
TKecmM/ESxi45I/8MI1hysKfn3iZTnjmN+FJP1zSRTjygLDJB/OzHOJneUynS3wMky/AEwfpYFnE
RRfxLId4iJd0ExfT6RIuGVzKJmFpbddZutWeu0hYcptCGNsP64Ttj22S6Swj1nbYUL3D8lA+2zhc
xJuW9JEewrNvkT6mMy/C8DM/+WJZjAcMDNMZ9qdTXv50J7P+MR54WAZpBAzSYRFHWMSzXL+LNBgz
PhJeF8qFYxlw/fSzzMbS58fHcq1btwTQvGBDRq9WFFhrPBLI0Kta9uxaJHvv3tkT31wBf1+qqq7S
0yfhY6kYP8Gy/7H/NBc9seIFPeiL7OsIQwemZhVKl13ahE6KAh/eybBhxknX998c3e2Pq3HM/GE5
eCmorqzQ71mUO+WkZuRIx875ju4CLuSprHQn5qH3gQ8nsEiTf+wJzLHiAx7igwuL8uimZGRLfnr4
u1fgn3WEcgAnWblSoDCgB2HobrgI4z0U9EEurGPgD6RlSruiLtJJ+QEccabqEk65LkIgP+L4nCOd
7sl+Fx/wlEu2tN+xm3QOysOJ08UGvu86daFpOHmRHqSJcoPb0oY0kCbwXKV7b1ZuwreeRLp1Utnj
Gw76HZoEILelxdVs5dsFh2YTrUVsJWAlYCUQmwT4QCS0P8z4aC4fpHjww48BgWk40GAc8ftdptNl
OsN+158eLcx4un48DPvT/eFY4ZjP7zK/3zXh4KccMSCDLBFHi7yIoyUuU+bEB7nDmnkJv927W3+U
ay5/RWofbI63ZErk5psebzzS7v3kjZsPkbaNx9DiOdn+2K7ZPv2EUU8wnfn8Lts02zdfXPgCxD7j
x+cvj+Uw3h9mPF1/uj/sh2P55JvpdJmfcIyny/RoYX+8H57pftcP5w9HggcM+YgGTz786Qz7XX85
/jDhiZfl++GYznjmY5iuP94fJlwyuNldd5X95DP5PEGJbbNb++3ig9Gm+Nme/K4JAz/TGe8PM56u
P90f9sOxP7C/EJ7xhKeLdFg/PNPpMj/xMZ5hv8t0v0s4xvvD/niWS/o41mE+pvvzMZ3xdBnPfMTL
dLp+OMbT9acTT6z0EY91GyABnT8MpOjUUWqGVGUXir5xSE1GrlRn6uSthDcaACPrpwHYWw0oFhv2
3qOLTLzqRJ0cbpmTzugH7At0IWD4E6luQAss9AEsw2wMkWgHHPs78xA+mgs8yAMXlid9GWa5GMdy
TMtygBPppmksPuCkId+gi3yQDsDQTzoIz3iGQQtgSBPy0g8XBosRgIcx8zkRRhzxsEymU97AR5xI
Axxd+p2IBP0D7zjtgyvHnO+c6HVwGWk6b6I/bYkJSnXyk2UXHJK/Di0HVgJWAkkqAf/DmQ9xDgrq
Y4v5CY9BUkMM8/nz1EcH89Fl/mhhxtMlvN8l/fWVz3zR4FiO32U+v8tyKU8MRJEXu0jgYgcJB6cY
dMGgbOzwQDrLYRrzYec3cHPHDPwmvJ+O7Sm89L2PtsFiQxwkuuwzeeOHA+XM3bz3+8cBc7OjYLvk
Tlb2F7okgHAM0wUc0+CiHaOPwDLM9o04tm/2I+Ihjmhh0uOH88P70/3h+uBZjh8uWpjxzNfQ8qLB
Q04w9eFl+Q2tv2jlMp4u8ftdpvtdwtVHN/MR3u/Wl98Pn5Dh9J3khlG7y+lPfp+A5O0gt5+9TwLS
1Twksb1Fc6OVWl879OMjHsYzTJf92q//mE7Xn5/wpIduNHh/fj9ctHTCkU6WEw2e8XSZj3jqc5nP
D8d4ukwnPQz706OFGR8v+li+db0SgJxTdNd0VeGOUp1RIKW9zpBAVbke8dNxbVaepOUUhiYfkRP1
ybrxYootVK3XAXXQaxsTzZSWV0qJXoETzbT0YoO72x2nGfBtBLU1mGjWXd36XlNVFR6/sW7oRuOn
ueJZLvot/HjPwlgH71HcqY+yOdENPQk4jofgZz6kYXyKME+mq9djUhQGcGiXZtuk/sUOf/jx7UHQ
hDDxuTR40Omhntjw8T0Q/AE/cKN8vheiXhCmHMgHSkM86IALvkEPx+HAhzBw8t0TcisrK3Pg4YfB
eyoM8QPepAN+4IFFOeCfeeHy3Rd+lgcX9AAe9MCQH9Yjy3ESE+APNNOUVwbko2/Xad+oca6GDeSp
XPWUgzJIEOvGWQJ2wSHOArXorASsBKwErASSWwIcmGDAhAEVBmowGMgijoZw/jAHcMgHm2gDL9Lb
cm6FLFjwa8sV38CS5y1ZowsO2/4O3gaSGTO4v93WlxHwsOwPgGeYfQNxZt9AONFMQ/lONPpJT0vz
0dLlUw4t7e5yyHHy0cH6gq+EJMzLFCYZsvRqg5YWji2/0RLYXvvX9sp3oxtKS2TEhJxe7RLI0Mnr
vCJdcNDJTF1wSM3MkXS9ksQcAzS1Pv/z19EtwWHUMjE5ed39U2Xe1z9FhWnpxQYQhncWWOzexkR0
airGbrqrW58NnJiOysA2TjDbCMaSfN9CPPwwdNm2mAdh+PmeRdKZrqNWRjluqi66IA8tIgFLeEyg
M42uCdNUfHwXdIjRP46dTb5RLuiBC4P6Al2sN6YxL2DgZzxkRXjKjS5gYQAbyaJMwJr4AI84Ewdp
QxoM0oAP5SIveUBcIhrQi0W4sgosxqk/oFfHOiOmxKQ3EWXYGJrsmLQxUrN5rASsBKwEmkECjX1A
NzZfNBZixRdvONITL7yx4vGXywEVd2wgHbs7MKDCYAULD6ZhORxocdDFHS3cKYN4ayCBGlm/OXkk
8eNGd4dQ8lAcmVK208iptWPRntHe2Q/w0oMwdjwBF3ZCAQb9AmHip1sbY+SYWOFjhWMpDYVnPr8b
K55Y4Yi/ueFZDt2GltfUfMzvdxtLhx9PQoR1si07IQgJEtFC13ckkghibV/xhqMMYsVLeLqNzdfY
/LGWFysc6YjVjRfeeOGJle7tDY7yDT3ncZJBr1Gq0g/5BjChje836Ng2Xe+ZNycdW5OcanRi8voH
3MWG8orwdxFMHlt6sQFjM9OkBnSyOiUguRm6q14XHDD/CxiM4/iOY8Jva7/ZrkAXwqAN70lwufMf
dBEWLmmHHxbwcPl+FuLPV03pmVnO98b4XubHg3Eu4sz3NdCFdz8HtpH4WB7pBC6TX9JBPlG+aQjP
OPCJOPZH4DLxIT9kALoRDz8M5QUX+QFn4mE5+DYb8vjrgWUQF+Dph0v+iBfpLNMBbOE/8ERZUS4q
Hv3OiZ7iUIt0bVEOHy1Maqss3i44tMpqtUxZCVgJWAlYCTRVAhyYcWCFAR4Hbxy4oAzAwXCAxQEh
BmCMI4wDaP/EO6RObIF0bZtM1MZflnxpQHtmu/f3jfiXajFaCVgJWAlYCVgJWAkkggRC44B0vUIF
u8X1w7sYD2CM69jgeDcRaI0nDVhsuO6B1+SzJT9Joi42kF/UB42uMeipkxQpyNaT1ghomplOuERw
2bbQjviehTjQy3cujD9hAANj5oEf8eQP4fSCTnKQws1xoPs7V+cAhgsLxIE4Bz64cYYT5042/WM5
TcVHPCwXYZTNcTXpYDpc8AN5+OVAXHBpgAc4IC/iQj4sPMAQFvhYNuFMfMiDeNYD8iIOFgZppsu8
jDNxOoAJ9mfyQp5AousPyzPByE56cuyCQ9JXoWXASsBKwErASiCeEuCACgMuGAyoMBjBQBUud46w
TMRxAIc4c0CHeBMP81g3eSSwrqR1nHBoqMT5IsEXGfYD7Nhimm3fDZWqhbcSsBKwErASsBJIDgmY
z3qMBXAnPSY1Ma7F2JcTjNFOPCYHl5GpTKbFBpMDrC/kZen3CHRxaNhehc54LS/LnWg24VrSj3YF
E+19C2loX7AwbIf0O5H6x/xok7CcwM/d9Uh57ptvQt90wM59tFm0X+ThexnbL/EiPwzxIR22sfjM
chzEwT/Gszy/PAgLOmAoB9ACQ9cJGGHEE9aUnwlHWcL1l2/SEQkP8yKNsMBNevz4WG5LueQBcoQf
37SAhR8WJ2mqqnCqJkNqtEmSD5O3lqK9NZVrFxxaU21aXqwErASsBKwE4i4BDjwwkOLgBYVwIMh0
DFTgp+XAJe4EtQKEyTSFvzWZiG2GtsH2jPbOto5ibPtuBmFblFYCVgJWAlYCVgIJJgE++zEOhp8b
cDg+wHigNY0JknGxgXXk1E+a1ofeTl+Q7X5MOTi/7xnDJVITI+1sQ/7xJmllOsPMBzeSBTzi4cKi
/dJFPN7pmA6c8NOF328bi89BavyZ5bA8IznkJRwj/GF/POiDiSY/5icc89P1pxMP33396f58DCei
Sx5AG74RnRqsfzM+EeluDTTZBYfWUIuWBysBKwErASuBuEuAAzIOsDDwguHOFH+BhGM+pjOeYetm
S98+hSIrk+NDDgfu3na7rDK2W7ZnTDDAcHDOeMJtl0KyTFsJWAlYCVgJWAm0Ugnw+c5xL5/7vKqF
bPvTGZ+MbjIvNkDeqDMuDLG+ONGONNZpItQNafG7pI3jTaYzPpJLGLi8Ogn8MwwZMN4vHz8+lEvZ
MT/CDcVHmvz4Ge93/XAM1yeHaHiYj3gIV1+YcJBTQwzzNSTPtoZNT0uRndtl67uMiB78kTT91gkC
fllta7pac3l2waE1167lzUrASsBKwEogbhKobyBVX3rcCGkFiPoe3EPknc+SgJNcGdSrXRLQue1I
tO1828nalmQlYCVgJWAlYCWQKBLg85+TsaSL8Qwnq5uMiw2mrFkPcB2/ujCcLDdhk8FPfmKllXyD
X04gIw5hc/Lc336j4Y83vmjlNFd8Q+XXXHQkCl60CfQIfNukRv0ZaBfaPnS5IVFIbJV02AWHVlmt
likrASsBKwErgXhJgAM2uvHCuz3jyd7tEHnsnCp55auNkp3Z8KHIxmXfG1U0CAAAQABJREFUy4yV
sUlw5726yYHtG15GmV6ltM/gQTJAD2Nsz4btnu72LAvLu5WAlYCVgJWAlcD2JgE+/zlp65+wZXoy
yyXZFxsge9QPJlXTM7L0e3M1Ul5e5Sw8uBPu4Un3RK2vxtIF/sA3TjBABjiRjjDu6AfOaN8YiVZe
vPFF6xfRyvfDxxvOj98fjrU8f75ED4Ov7IxU6dctzyE1O0tPvej9SrheyZrmk0DD38CbjxaL2UrA
SsBKwErASqBuCVRtkeXfLZNVazZKhWRKXts2skv3PaSowD7O6hZc4qX2GTZM+gxrHF1VP8yWGXfE
ckKig4y/+kTpY5tH4wRtc8VPAlZ3xU+WFpOVgJXAtpGA1VvbRs62lBaVQMyLDbt3kYlXnahXqzbs
qpltyZzOszu7t6tqArK5tEp396dIblaWe+JhWxLSAmVhQhmWCy/OjnYNYwEBtqEm3vgaWr6Fj58E
UJcwadoOcjLdhblM7cfoH9Y0rwTsK3jzytditxKwErASsBJoogQwYIRZPuMROeGIi2V+LXzDZPqq
t+TwTu4d886gokqB7BOulqRaS0SZ7lqKzVRKablC2rYQm7gsVNwlAP0F3XW86q4FtbAPk3d+fVsO
Kwo30JRqffkJB2vlsBGJIYGq9Uvl+alfS3lGAlVWperFtrvIWSf0kfzEEJOlIkklYPVWklbcNiKb
k3fbqLhmLaZBiw26gSURFxtYH3BxPcyWsmrZVFIpb33xi6TrB6RPH9hNsjLd7xk0qzBbCDn4hsVC
AxYWHDno2CsruNDCdH5rBOG6DOHjha+usmxa80uAJ1ZQ//weI0rlQhTiWefNT832V0ICjZK3P+Fb
jq0ErASsBKwEYpPAhjkPyK5HjI0CPEu++mGLLji0lyUv/0l6nzrBhdvnQvlk1iNykL2CP4rcto9o
dxlq++DVcpl4EqhPdy1U3XVYUTuruxKv6uqgaLNMGveavFhaB0iLJX0t8zPayt+P2anFKLAFJ78E
rN5K/jpsFg4CNQ7aQHWl46akBHeNpyXnSKs1LDZEqudqPd1QqVcqFevCQ3pawDnxEAmutcVx0hiT
yuaiQmNON0A28cbX2uSdbPy4Cw8iVcFPNmQEsPBU9+JTsvGYiPQ2/GxRInJhabISsBKwErASaHUS
wA472JqaX+XZC/2LDUNk9OjfydAg19gUXF29SWb9PbjYgPj5j8onS9Y5OIDHGisBKwErgW0lAbzw
Qnc9E0F3jRrl1V1VVRsj6i5zJ9a2otuWU78EqlYvkzcScrHBpf3zd7+V4vrZsBBWArUkYPVWLZHY
CJWAMx6vqZZA6WYJbFkrsm65yNqlUrPuR6nZtEqwAJFs4+zWtNjg1E/wnQn+quoqx7LxVldX6zuS
1l8QhvGtxeXCAHes41sOsNi5blrC1cc34eKFr77ybHrzSID1CJd1GdBF0pWbquSXjXoiVNtHmp5S
TU11T8Y0DxUWqz3hYNuAlYCVgJWAlUBCS6B08TtypXkXSd+r5ZPpt0gf3Bkx8UHZsr5SCjrl6eRe
iQR8H/jNTLcLDQlduZY4K4FWLIGyJe/IVR7ddY18/PbNju5Ke/DvsmltuRTukKeTAFtr6a6s5Nww
2oprM8xa2dr1sikcTDxfWbFsUKrstUqJVzXJQJHVW8lQS9uexoAuoqdWlUqgQldbN/4iKXraoSYj
W1Iyc0QH4Xo/ybanqbElxrrY0Hf3zjIxQa9Rqot3c2EBfhr4Mfm6vZh48xpvfNtLPSQKn6i/Gu0D
uHIMblW1fmg8zb2GTC/lShQyWx0ddsGh1VWpZchKwErASiC5JcDBMXfjlJZu9DA05saR0k33bxbr
Fk4MHnIKc6S6vFzK9cNPHXfxgEqeztpV6X3/gMNdnDB2wOiVkQ1ZCVgJxE8CPJVQWVkpJSWY9g2b
MTeeJd1TtsrWre7dsRm5GY7uqlH9VOTTXbmZ6Y7uwu48GOzOsiZBJJDob0/6zFyvbWyXvASRlyUj
4SVg9VbCV1GLEMjxuNM+Ksuk8scvRTavlPS5L0hNxVZJ6dBdpLCLVB5+taTkFzm7yUFoIo+zG7LY
cP/VJylPifuBaH+jwHtTVRVOM9S4Vk+l4NorvAdVVbkfTkbdsH7o+vEka5j80G0qH8RDt6n4bP6W
kYBZf+WVAfno23VSrQuondvkSiAvRTLSdXyt/cKa5pFAog+Zm4dri9VKwErASsBKIOElgBcd2E0/
/+qhtUPbHMFkHhYQMIjAQNqdjEuT3/75Z1l43nJZX1ol+Z12l55dM5PumLeHWRuwErASSDoJcJJm
8y+rPbR3aJfr6Cvz5QcTOZgQ+H9B3bVBd17lddxVenXPsrrLIz0biF0C2VKYFTu0hbQSgASs3rLt
IJoEnPG4Tl4LTjeU6Wrm1rWSWlEi1dl6rDhDTzjoc4ztJxqORIhvzYsNkK9TT/rehN3bGFuk6kYs
2BpdiOCiYiLUg6WhERKo2iLLv1smq9ZslArJlLy2bWSX7ntIUYGdzo1Vmugf1arHyip0QU6/c1Id
0GvGBPKziw2xyrAxcLaFNkZqNo+VgJWAlYCVQLNJIDRg1sEyBsg/LvrMKKunFGVX6c7hEsnMzAzt
0sGCAxYhUlLSpajr7lKkObAzuFxPPmRlZTkLEnwZMif7DMTWayVgJWAl0GQJQGdB11RUVMiKxabu
2kuKsnDqocTRW9nZ2cGFUnc3aCDg6q5Owd2H0Ge8cxY6i3qLbpMJtQhasQSq9IOhyp59y2vFdRxf
1qzeiq88Wws2jpuxc74Gm3uqKvSLqxXOMw5TdJjAD+huejyv9M95ZuEZxRPFiSSH1rzYwHqivFP1
uqv0lIDkZqRKmi44aJU4dYZ+bk9LUkqJ77Jel894RE444mKZX4vkYTJ91VtyeCf3Dk5nfKifJrDP
fq+g+HyDPP8/e9cBWEWxtb+Um55A6L1K71JEUUQQBCxYABEFRRG72J5iRezYHvp+xQYqigVERQSx
USyI2BCQIr2FTnq/Sf7zzd5z7+4lwQKBBHZgM7O7s2fOnL3z7Zk5c2Z4WOcCZfQI8hnjpJWUSdxy
1qR8nrn+2eXzvblcuxJwJeBKoFgJ5OSkIzk5GenpOaDO8a+CNwfpQoN0kpPTkSOdjMMVvD7+LLoH
p6pKQWSEfV2IpqhdLcwoDKqIKRXNz1jTVCo0BOfX64y9OVLn9HRLboevuvYi3LQrAVcCB5HAIWNX
GcEtVlExKMpzIHYFd3wUq/QZM7DjM1ocDLNYjotblMKRD+HhZdx9ILEGapVxFo/8WyudEg8Zt8hW
GcEuxaDSxi2ryq7OVTq/yMNPVb9DNDDQo5jfKKYDOwPALE9i17cPPxeHRvFYNjaoZPQ98VxsDAiX
P/FRYeYQpcToJZrXjcuPBJJ/fB4NizU2sA4L8MeGdFOZ1TPuNRNTQjwydN7uGvzoXNGz/FS4FDnV
bxyLsLcXe7oUiz9uSbtzX47bV+9W3JWAK4FjRQLZ25fhw6nv4bW3H8cC+walaIMBowbiyhFD0e+k
xvBwiktJwZuMxXPex/uTp2HCzPkH5Go7YBSuHDQYAy/sidrRxdPhB9u7+XOMGHAXkioLiVqXYvLr
/0H9cC9Wz3sbEx6dgFfmO+dnXHr3RNx5y1VoUzXwOWKnZf+v7+Lmh95HdNUYvPHGBzZ+PsGjo4tQ
Q9ZcDJ79qwqDxiFVumLsg1egcZSlaOt1jZG+GbPemYLJL47FTIfcgB4DLkXt4B03ZdOIzjdNwOhe
DWz8uElXAq4E/o0E2A5zkpYb7Jo09XE4ocGJXUSH4Jn9ph0Lbv342bSjilvKl+LK3p/fwa2PfYCI
xEhMmWLHrll45KZC1EqwsE73ZtDndbDGnFc+CQ8/MhK1ZdBY6aqMi9I2ubilwjhKcVS9ejgFS7Do
KJX/V8VWaF7V3TD6r4T0L+8fKm5psUX5+/82dtWKOhD/lE7+prn/Sudq65sRq/hS6rgleO/XuSaK
zuVUBQ+qc93cs/4B+K/1d+PSlQB/HzzowVAoXnvIz0OIHLxmjA4S89tlPIwlDz2PVTcnZ/p9K10u
D079eDA22CVAY0NsZCiiwj3o0SzBvIPYyPAy8S7sfLrpkiWguFxYuAtTRt0SlLE7rrqqFtZNeg8L
5U6BvO+CglQseOHxQL5lr2Dx6sfQpWslc60stMMAc0cuFZBjwPOY3se8zsPa2yRMMMyDQpGjev8c
r/IqrTcTGOEprRJcuq4EXAm4EnAlUGoSWP3Bw2gx6IES6C/HzFd4jAUGTMD2D0ajVjGon776Ewxr
MQAzS6DCy8tmvoJbeOAMTF82AwPbJBabO3vfJkxdpj3Jrtg3fj3m3tUE100tNjumPn6dHBMxfeW3
uKh5vMlEJWDDd9Px/uzZxT605OtZxV4/8OIujBxzBU6oGFiORPMkL5c6tBuEA00rVo4FM4tnOHaQ
TaFTYm7sSsCVwD+WwOoZD6PlIMGmYoMTu7ZNvxm1LY9xf+701bMwvOXRx62BLWQNa18gdm1a9AHe
m1U8Rv00v3hM0+cD8U5cc59lcAhcA1zcskvjKKbDa2PMLR1x/YRfkB4d9MM8imyZoivWw3NDWx1t
Lo7Z8g8VtyiYf6xz/f4BBra1Bo6CBfuvda5V32GgTecqTdwizy52Bb+58nWuA3RFYlwIkcMEsSHJ
f3MUyrJK/utlqGo0Njzw8mf4ZdVWxMZEIjY64kDu5Ltdv2YllLcNooMrooOkjD1hskG0vJn4KI8x
NOh8M80T/Kx7XjYlkL3qK9xqnxDX+nYs/vJBtOKEuAn/Q/r+fMRXi5UB8ywUBVRRU5mIcLZON6gE
iGEauEd0qDQKxTW97salI4Fihp5KpyCXqisBVwKuBFwJHB4J6Edz5fRb0fri5/4e0Zm3YNxH/THx
osb+WS6kk778DVRsf9Xfo2Fyzccg6fhO+i0ZI9pVcDzHWU6FYYEPOvAKOtV5xZGn+JNlGNTyOvyW
MQVtZCYf6YQVpRaf9R9drYBoz4GDQYW7vsFFYmxYEESrdfdzUWn/LHyzIuiG7XTN7nTDHy/pTAjb
bTfpSsCVwF9IgO179Yzb0GrwP8GuvnhpYBM/5bKEW0sz3zK4pR2XsMLDgV0JMjsxXNaTDax86uKW
//WXiUSVtqdi2uRTywQvLhOlL4F/h1v98PKgAG6Ry9TfX0dih3+oc7WrjElLU3BFm3iH/kZ6/1rn
akGd6020jrRmeh5u3OLAJg+jr+757l/rXH/uyTA6l+pb7oAp3/qRC/pdY8w2IBs5mIPnHMQu4jvm
QbOD5jly7P1lSeR59JDu5jhY5sSEGITbvrcHy1sW79nbBdPcQ4OxthueM81r9rxlsS7HM08GL0UA
XLaM6ezsFIc4br7nMtRHBsTh3rzH6IRoFMhehbni1lKlriOreLl4zAx+/T3wrvvuZamxsBDUSYwi
XEEcfxAme53wRGXvlKJ7djgkEOjJHA5qLg1XAq4EXAm4EjgyEtgzD5cEGxu634Evft2IPbL3wo6t
f+L7j1/CkNYBdv7csMf5Qc1ZjhsOMDaci5c++g4bt+01ezjs2LgSs19/BDYyhuBVHZ7A5gBpk/qr
j/WNT03D8nXbsW3jMkx76sqgp9/B67PX+Qfzmw17BXM++QRz587CPefaszbB2Nffw4fTpmGWzCKe
LV4Qc+fOxeeff44vv5yDJ4e1tGcuJu3F3Ak3OYwNrW+YjFU7U/DD7Hcw+4dkrJw3Ed2Dnnx64W9Y
+fvvePPyYEkEZXRPXQm4Eji4BAS7hgQbG7r/x2DX3pQU7Ny2Ft99FIxdewM0yxpufbrO4Crxj0eT
y17Cl3PmYM6cmXhgQIBtoAnuf/VtfDJjBj7++GO5PwefffaZwa+vvvrsL7DLxS27JN20K4EjLoF/
gVtrRedyBGLXAcYG0bk+/h4bt+4xOtfOjaswe/LDB+pc7Z/AFgcx6+RgeteNT0/HsrXbStC5phqd
q3Rxizx68fmEG506142vY+WO5L/QuZYanesN0bkOVsdiROJeOswSUPmLfQGFshkxjQtMGxuDucYB
O17guJ0vYZ0e9b/h4WGomhj3l0d5NjbYhawGBY1lhJmjzMbYoMYHe343XTYloLicun2Xg8HKFaOt
5c3EkEZjmu6pUlgYir6PbceKnxbhm2++wa+rt2NQkwi/buogchyfUK7ELu5tEhcVCo8Y4cKkfRiD
6XEsl9KuumtwKG0Ju/RdCbgScCVwmCSgCghnPix88WHYvSwx6FmsmHYH2tSMMrMdQjwJaNz1fDw/
bwM+eWKw4aBzi5p+5YQ0Vkwdj6kO3m7FD9tex/knn4CosHzkyEbKiEpEx34jMfvHKXAu0jAeL83Z
YmZhkJa1DqJXFKECB0Xr5FRMXrQR9w8/HVXjwhAeXQ3dhz2GBc8Nd+R9/u2FSJEN6XJltkZhRHW0
6dABTZu2QudOZ9vyNUaLVi3QrFUrtG7d2hytJN2yZUs0a9Yando3s+V1dnwov4LMpZg63ia5VuPw
/gNnIxHWBoZpaVlIaHouJs4aZ6MjS0qtyket+vVRyVNglD3WV9+HI6N74krAlUCxEmDniMeCFx8J
wq5nsPKD/6BtrWizCXJRWBxOOPl8vLBwMz5+fJCh1blFDX+7K2u49ZwPtxQHiyJroF2nTmjSpCVO
OsluLT0BzQW7mghWEa/0IH4Vi12CV8QYyoy49baLW8X+rtyLrgRKUwKHgludbLhFnWHF1CfwjoPZ
2/Dd5tdwftfG4tHkldms2SiKqoiO/a/GZ0veCtK5nsDE2VsMHpAnrpnPtahz82TG+QHB0rnGXt4D
1eLD/TrX/AnDHDmff2uB0bnMoJWnGtp27HjYcEv1o/z0X/HWEzadq+VYTBOdq1JIrszSzUBqamax
Otfy1V7UlL1SqooHhuFP9EzW2w1HRwLaDoq8MvNajkDgUJIs3uP7XgWuu6mjIQF6MvAI90QiLDwS
3iIPCsB9NazrrqfD0Xgrf79M1fnY3qhTbln5i+3h5qga5UVWVpbpJ7OvzO8AD/bXc3LCUbVeY9En
m6F+1SiThzRIy22flhhpiIvyhKJj/Vh0bhBnDA8Rsr4Sl1dyQ+lJwDU4lJ5sXcquBFwJuBIoFQkU
Zf+KZ8cttNHuh08euRSJoljooBc7aJbCEo1uV08Uj4etuL93DfOM1XHYhLdHvWujAby2+HY0EEOD
dd/q0FKRIU1P3TPx1qRrHPnHv/wl0n2dDFWSCg7oEHbDuz+/h34NxRDiU3xUQWpy/lW4zE4xNRV5
PsXIriDl5doNB1kozLcUMeWTddX65uXY88psLBs/SjPdVubohy5AJcnDe+RLacW2ORPX2/Lt3pPs
51/p2G67SVcCrgT+hgSKsn/BhIec2DXTh13a9ti+rPYYiVOuegG7tm/Hvb2q+wbfyzZuUQTEOR7E
RCd2ZaIgz7rO+ikear2Lwy7m0yAe9P7g4pZfFG7ClUCpS+BQccsa7NmMt6926lyTltyBxhHOmaqK
B+Gic7352ihH3Z589Uuk+fCRN0i3JJ2rfyMx4Pp0I42bXjASjmkePp1LMfdw4ZZVX8tYyrRd57pZ
dC7qqnZ9i+lgnWuX6FzkW2k5BOGeHBUJqGcDh+aY5j8N9rRec+OjIwFpcuKJIoY62b8iLduL9Bxp
RzKv+1hfTicnJ914iaWn54hf1b8MXpl8JqsEJJsjHTmCQYcreH38JSeT7sGpEveIy5ERsbaMTVG7
WlixmKj5FS8V0/VhXi8peMVYkZ6eLofI7S/4KolGebiuv/8w8WqIjggzhocI8YAKk+Wo3FC6EnD3
cChd+brUXQm4EnAlcMgSUEVBO4PJq3/ELDvVoReiWTjXdHRqCpzJwg8snwuT9cCtdR7FhVD2Nche
8TWestPo8ww6V8kRGr51Wu33fOkKnfugN17Gl3pv1tdYnXIpOsRb6/Rytl1Obr7eNfHoN59Bx4Qs
UWQCrtZan5CQeLQ+U7J95Xvkm/n4Y++VODHW4kFnbxSI0hwIMlAnGlG+GB04o8PuIky62Y7ZftKp
zcuVWYDW2qXMW5TvhWwT4Q/VYkKRlpZmzvk8D0vOsrZjU7n8p5XVm5ttZhNSppQf81Gho3xVifET
dROlL4FjWSsufekd0RLYVhg4qJS2Mhi7LkLTUHZ0rLbHfNqm2M7YZqOiLK+tXMGxnJVfHXXcCg1N
OAC3Vu6/Gp3ifAOAwicxxOCXN2Aw4BBNoe86cUTlwjoznZVrx29iV57IzJdPcNXFLUrKDa4EjowE
tH0eKm55fTpC1vKv8KSd9T5PoYvoXGlpTp1JsxAHK3TqjT6yF9YXenHWV1idOgwdBGvIF3WQnBzn
8wGdyxpEYR4Gqz5xaGXXub6dD2JXR9G5OLhP3KJelX8IuEX9zOst8q8hny86WYzyLzF1rsxMMb5K
WeSJ/DEuKChy6FwF+Zyxm2PoEC/DRYdl0Pfi6l1GHEf8Dzci5mEFLkViXZEv9xHnxS0wIAFtD4xp
/EnPKUBqVj4+X5pk9qa4+JT6Mnht7eEQeKr8p7K3L8OHU9/Da28/jgXL7fVpgwGjBuLKEUPR76TG
8IhcSgzeZCye8z7enzwNE2bOPyBb2wGjcOWgwRh4YU/Uji6eDnHJu/lzjBhwF5IqC4lal2Ly6/9B
ffFcWz3vbUx4dAJemb/MQfvSuyfizluuQpuqgeFY4uH+X9/FzQ+9j+iqMXjjjQ9sz3yCR0cXoUZs
YIksvm/zzqV8Bj8+VumKsQ9egcZRlm6t1zVG+mbMemcKJr84FjMdcgN6DLgUteUb4wjijdb5pgkY
3auB43J5OTH9f5ERvyP6TSTvvM6D11WW5aVO5YnPwC+8PHHt8upKwJWAK4HjUAJUFHiEFnoctR/d
tyVCpPPGGS3FBX1OY35sCwtzHVmH9m+HSHY4HVedJwVRjXBaV+DLxXo93XQaZQsmc4EdyGAeKsaG
mTx2hUjThYVRaNKllxgcvvYRlE6q6XwGlCYtqaSYdSI9BqsD68ypnVnmM/XOLZTttgJh3frdKGpY
y8jVQSdzA5b6jA3MXSTr1vJ5KiaMNW+Akps6khKIa9oRl9f8A2/uOHipzU4/Ba3sE4QOnt29W0oS
YPtjCBfXfnu4pb8Pu+SitmVtWzzXI9COjz5uFRQIbp1UHG5Zhld7/YpLs06sjwbiFoMTO1l3ekHI
hnY0TuS5uKXycmNXAkdKAmyrDP8Wt7StE9OCda4hfdsiShp4ga8Me534nMFB0bm6i871hV/nkg2U
qWcVkp6lkwR7OCTGBQZUSIO0tB6Qof8THNgldRM6ZMGZz86Nleb9v4NbFl8Wf3yysBjsKmhc11+e
1qMwY6ND5yJTf8XTgVy6V0pTAtS09Z0w7VO9TZH2dGny4NL+exLgRK38AtEbxPAQHiZtl438GAur
P3gYLQY9UEKtlmPmKzzGAgMmYPsHo1GrmFHP9NWfYFiLAZhZAhVeXjbzFdzCA2dg+rIZGNgmsdjc
2fs2YeoyNSp0xb7x6zH3ria4zrl2sf/ZqY9fh6mPT8T0ld/ioubx5jrb14bvpuN92Z+wuLDk61nF
XS7m2i6MHHMFTqh44KS45OVSh3aDML+Yp3hpwcziGY4d9HgJT5Sfy5bhQXYW8jUHT5FBsvJTgXLK
aTFNr5zWxGXblYArAVcCx7gEtGO2fd0aR00rRnvMbDcOTLGDGRERYWIqLjzndX5kGXiNM9mSNmwy
5/qnacOK5h7zq6Wf9zQ/47y8UNTp1AVYvMT3mMygycxFbrQ1U81y23eaLLJyOZMt2j+DgA9qp5Uz
9IrC7PN2uQEWZ+1Zs3rNQJupg684E8kGTzITweMJ89eTl8mfDtwFcgs9KYN8WUoGO8xAdCADXr/x
JVzwy0NoFmfN/CEd5v15+mSHMlapcrQpg/cpIx5uOIoSCE/ENY+OxsVJ27FuRwr27M9CpnivMETI
2rUVqyeiYZ2aqFvJ/vs6ivwex0WzvbPdsL1vX+/ErgqR4eYe2xNxS3GK50wz5rMMfD5p/WaHJI8W
boWE2VFElmMTb4SiIsuYQp55EEedG1FKnQSL6bHBuhHfGJjXkpG9ajrjOMx4ShTJ7F/7L9nFLbus
3LQrgcMvgX+LW6qHKUeql2xfv1Evmbh548p+3YQYQI8uBuorxDwr9qB25yCdKysPeZEWZpB2sFdp
Vl6W6GoRBk9Jj1hDesxrsDTUjiRc2oieVBbe8j75OBTcKiigp4SF1yw/Lwi73rjpVVz4yzg0j7f4
Uvxb9N4kh85VuWqswUXe56HBntZrbnzkJFBYJC+Xhy/INBzw0BD8vvS6G5euBEzbliIY8/BKO+Sh
ge2fh13H0nvlKdZ6rpx+K1pf/NzfY33mLRj3UX9MvKixH0tIJ335G6jY/qq/R8Pkmo9BbSth0m/J
GNGuguM5fi8KxbATCK+gU51XAqclppZhUMvr8FvGFLQRaCadsKLUEnP//RsVEO37ptifKdz1DS4S
Y8MC+0VJt+5+Lirtn4VvVgTdsJ2u2Z1u+OMl/R3ZbpfJpH4vFJfINx34dqTyOwvUr8a9TujlwPGT
MlmFY4KpwBfimKiOWwlXAq4EXAkcmxJQJYu127NjtaOSuYUycC9fTn5I1bjAtBnwsrkJ6oeXefft
cA785eYF3PLtdJSe9awMljkmKKcjVzq/pGc/7MzJHf+p0rV/+IO/71S2NPjzObSAgCspebMfWj99
nrGdL6MQRjTDqCfPt2WZhvM63oCPFq/EXlmzc+fGZZj5/GiM+O98W54zMKhbXaOoKk/FlWV7wE0e
IQlUrFUbnTq2Qr/enTGw/8nmOK/3iejetqFrbDhC7+DvFsP2tycpCLuKrA6xvV0Rt4LbNe/z+b1l
BLeC60xvBAbyScxhIN45g2X81boeiM/23EJD6LDOBsMim+Pq8QNsGVzcsgnDTboSKDUJHApuKVNs
w8HYlefbeJd4QKyw4wLxzwphiHQ4tKYh37f4t2JDoWPJSXnKp48pPcVSPQ9oZCzBeaZ5rLL17z/D
LdaVvGko8DTFtc9coKcSv2/pXD+uwr6UFOwQnevjCTdh5PMLbHl64JLu9Y1MbBfdZFmQgLxf/sYY
+Fd/M85fkrnt/jmKEjB6g74nX0x2eL3chz3zcEmwsaH7Hfji143YI/24HVv/xPcfv4QhrQM1/XPD
Hmfdc5bjhgOMDefipY++w8Zte80eDjs2rsTs1x+BjYwheFWHJ+Cc+vLXcr3xqWlYvm47tgneTXvq
ygBjJvUOXp+9zo+bzYa9gjmffIK5c2fhnnPtWZtg7Ovv4cNp0zBr1izMFi+IuXPn4vPPP8eXX87B
k8Na2jMXk/ZirmDtAtud1jdMxqqdKfhh9juY/UMyVs6biO62+0w+vfA3rPz9d7x5ebAkgjKWg1Pi
Fb19uORYmnxLvWIQLxIvB/tYRTmoRrlj0fVwKHevzGXYlYArgeNNAtqx5Iw3zlDJz3IqjKHhkWZW
WnR0tBmo05nC2hFQebFTS2WTa4t7xdXWHjxFoWZGHDun9hm4zM91dFludnY2ChwWglhERFpu/aRl
8eeky1kDkZGRxvjBmDyRJullZWUFzaSTT750VHWgTtdw98jsg0AIQVR0DGJjw8H6ap0oIx6eMHte
ecpXFsvkwTzxCU4ega8x5vKvA0UEpUa9cC/aJ1peIzowwCzKZ1B299SVgCsBkQDbG4O2TYMP2c62
V2TDHW3PHIgPDqTFPWKCw9HCLecmc5YnFXw+CMQ51pn8ckO6QBCMjYxCTEyMwWmd0UwcIR6GCjba
A69xXXPTQRJ6CQlO3Hdxyy4tN+1K4PBI4FBwS/Ub1b1IS49gnSsCludpbGys0SWIB3yOOEn8YJoY
kOfDUat2sQj3eEWHs3CU+YJDmCfC6FyKM8oT8ag4nCF/ISHWOtbMS/3RqXP9M9yiDscln1gWA+sT
H38gdt01rGSda+Tzd6N1XMBTjHqpXfcKrrN7XvoS0N8xNWy7ls3fDA83lA0JsN15xZhZIH08cxQW
mPbNduj1Btq5vjONywb3JXPB3x8D6/fdiw/Dse3AoGex4n9DUVnycK/CEE8CGnc9H8/P64Ohk8fg
vDHT0LlFTYNFasxdOXU8nAsH3Yoftt2LhrLnQlFRvrU3TlQiOvYbidk/1kP/k4bjDz974/HSnOvw
yFm1zRXyRr7y8wOeP/6sOBWTF72FsxvH+HTiaug+7DEsiPCix+gp/mzPv70Q951bD5HiyVsYUR1t
OsQar97sTmcDs3R5pcZo0aoFmkn/l/hOTNR+KHkIa98MeGulj6YTc3m/MGsppo63Sa7VOLz/wNlI
LOKm0dbkloSm52LirN1ode5YP2/LVuVj5JCmUhbrmG/au+qv5eX3Y+czN78Ii9buA5cjrFFB3ovs
iWG+eS6O+d/54U7YvxmHm7ZLz5WAKwFXAq4EDqMEjMIgH8iarTo6qOaJksOPqc5k0xnCGut15uFB
OnVanOKgsSM5y6+86MxbfY6x1dnLwvqlupwSH7fNwBWaxYUQn0LE55Uu06RpVwDsz5I/BuXXfk+u
+vm08xfgsfiOj9IsSlmMsdd+4iRZ4llT3PXip7i1p6VUWjKwZFgS7yWScm+4EjjOJcDBsRqtOjmk
kC8dY23nwfig7dve1uq0PNnxfFnDLTuvhv9QOx5Z2KX1Co5L6usQu4pSfsSD17m45Xj57okrgSMg
gX+CW6rnsG0zzYOhWJ1LlgHUPMyv+prG1r1s0bl+stUyYMAwuEBsMPPMA1mIQXxWeVBcVZwN5GTK
qbf5nz0MuGWoU5dLXYIHRn3sLLbEs6a484VZuLlHTVMHO56W+Ih744hJgL85ftF4MG1+Pvxw8XD+
lI4YT25BTgkoLnAWN7ErVNoyD2vvlwMNlM6ny/5ZUfaveHbcQhuj/fDJI5ciUQb8LWMLDSuW0ZbL
+Xa7eqJ4PGzF/b1rmGcok8LCTXh71Ls2GsBri29HgzAu6WtNXuPAOg/S9NQ9E29NusaRf/zLXyJd
ZOyXtzwXvJ8O0A3v/vwe+jWMMnRIW+k2Of8qXGanmJqKPLlPesyndPNy7Q0rC4X5NCRxHx+LT8uQ
ZNU3L8eeN7B8MYtRmum2Mkc/dAEq+eiQL6UV2+ZMXG/Lt3tPsqNM8lZeA3kvECNcjuwtlJMnaVke
zvqGEtXcUFoSOHAaWWmV5NJ1JeBKwJWAK4F/JQFVPFTB8MiMOHuY9cMaXN/lVDMzjZ1LzrDVjizz
2Z+nosIQLrPg7OHVRatw79lNZEZu4Hl29vRZ0s1N24FfHZPS6iI+wlpruKSOYViYRU/5Yj7ywOPA
mXSWoqV8scPMELyeMPdwID315FC58Jpz5rFSsmLWZeev88SfQcNAvDZzGCK3LsOiX1diZ3KO3IhB
xfp1cGKbTmjbrjkqRVqbtpIXzuhgGXbZKiU3diXgSqB4CbB9sr2z/UUmxDkyfbr4T9x2en1/e2Y7
46F4wmcULzhDN1y8ueyhbOCWnSMrTf5NHRx9GDEKC34QR1hH4pfWj3nDfIOTPgp+oga3fpvv4pZf
Im7ClUDpS+BQcYvtVmmQ25BQZ5f75R9W484+9Q0OKB4QB4h3fM4M/mTuhDR9W6iDOA8HowKzyiVl
uy/6kuAKsYV6IOlSX1FeSDNYR+I9HszLYLDLQfPf4xbp7pQKfOnncKAsHTICoet/xo9L12BHcraU
HY1KDeuhXYv2OLFTG6NzkWfVt8iX8uYn4yZKXQJ8dwz6+2Cav7RCLoMoB9P8rRT6Dr4znrvh6EhA
35eWHirLPMpueLKOv7QfnwGReYgtfFflJWi9VIdMXv0jZtmZH3ohmoVnICMjsF8FbxMzFE+pd9Hz
IdeHK9krvsZTdhp9nkHnKjlCw9kHtWep0LkPeuPlAJbN+hqrUy5Fh3irn0z9NHg/ndFvPoOOCVni
PWC1I9LT+oSExKP1mXLhK18p38zHH3uvxImxFg9cicAYPBxL5okuLRieL0YHrjxgf4+km51nl4F4
I+TliqdtwPhdJPvc2XfwqRYTirS0NMMAn+dhyRmIbCqX/7R48+ZmG49dypS4zHz8HZlvRTlp8+RX
66j8SzVktQfxCPJ9c/ktdb81vt/jYY6c2s9hJu6ScyXgSsCVgCuBwyMBfiA1hEbGaNLEa577DJtu
Ph3t5MNPBUAVf7vy783IkM2do8HlgEkrIrE6bPoE8OYMrL53ADpUsD64pKFl8gPM9O4ln8Ixx/aS
jqjn2CTLwZY5CTEbMTn5UkXF8Ono2Aaet/Me3IVRJae4uARyfsK716/1p9G5EVo1aIDKLVrg5L5W
B5c3qTiSRyp7DOTTroTYeTMZ3D+uBFwJFCsBxRDeZJsKi3QaHP7832dYf0cfNPcEcEfbtRJU7OJ5
ZKWyiVv2eio+mHpoJXyx1s0ea5ZgnNPrjPdscHHLLg837UqgNCVgb8//BrfYvnM5Y5XLXvgGZCIq
VkMzYdq/e9bk6Vjzn744OcHyhKCewaC6Bs/3/PgJPjVXfX8Gd0B90bkMT74BNWt2pj2TpQMa/cqn
D7I+xWGO/SlNM1+wHmV/VtP+/JooId6zYV3gjk/nimvYEKedE2V4Im88OMAWzKfKhAQMXwFKbupo
SEB+G/xOmW+V73dtnR3s63U0GD0+y2T70UAbgycsBHGRlsFBhsX9fTrNU55ixYnQQsemNhjdtyVC
OGBsq7u9XvqcxsTOwsJcexYM7d8OkTKQX9yCSJqxIKoRTusKfLlYr6SbwXkx8ZoLxlAcxEPF2DCT
h9il70bThYVRaNKllxgcdAqcGH3NoHjAKKEllRSTpuKiGgrseVlXR71lKb4MW4Z163ejqGEtP+7y
lqGTuQFLfcYGXuMeZaRFPGasZfJeeQsqD/Kt7ySQdnGstN5n+TFxlpYEXLquBFwJuBIooxKwfxjJ
op576p6Ge0+yM/0u7p20yMwSts/Ap3IQGlqIPz56DDGVKmH4pD/8HbywWifj8p52Gl/j1qfnIF86
sRpIi4cJexfjwRET9ZaJH77sVISJwqN8OW76TtgnUTrsSOvhpxv0kCoAGgfdllPp8Jh6BTrpVj19
my4e+ID/CmmG2x07fnoSN42bhK+X/IZlq1bhjzVrsH79ZuzYswcpspkh92bkbA49yDP5d5Tn73T5
i3ETrgRcCfgkENwxiajfA2O62MUzDXe/8r2jAxNoYxZ2JVSrhhGTVxqcKZu4FcBAYgzrbD8CtQ0Y
XhVD7LE1ihPIrSnSDLP3sV3cUtG4sSuBUpHA4cCtuCpVcLkPt9iGQ2t2weUyvhQIX+L2Zz4zOlcA
8wKbR4fsW4J7Lvu/QHZJjR3azTe8ZV0m3eAQ6tPbgvUuzVfSkIods5x5/h1uKb1gneuGB17F/F9+
x7KVK7Fq7Vps3LgV23buNDNts2SZC/Jt17mIkUor+L1ondz4CEmAvzcZcDSHpPnrE/OWOQ78JR4h
ntxiDpAAjQ2xkaGoGu9Bz+bx6NEsXs7DHXrWAQ+V8Qsc6OZg+PZ1fpOt4bhitMc/OYz4QM8u7kOo
fU3FVmYmXtLLK2nDJvOs/mnasKK5x/Ng/OE1PpeXF4o6nezKawFSM8Vrgp4TcljLETlNFlm5mYZn
8q78kB4DJ7QVhdn9DejVZi3pxPKYn7w4u5gy+c2Hj/Ri40GstPI5UVsaKby2ZZI4kU7gFdFW8ebv
6ze+hD8zrUl1dl30t+mTMd+Wr1LlaCMD8qVYbLtdppPkmQffAQ8jB5GFXrfem7UkFe/r9TJdqXLI
nGtwKIcvzWXZlYArgeNdAhXQ63LnepI/PHYJhj40HRv2+OYveHOQtHoeHr4gAu0HjzUCa1DZ7hkR
i55X3+4Q5KpXrkaf217Gih0p5rr58Oan488fpmJAs7PxhT13lwfQv5lzaSf7bXs6WEHRTqOJg3Uk
34Oax5yWkMdext9NN+zax5H15w+fx3WXXYwLzz0X/fv0Qc+e3dH9lFNw0kknoVP71mh23g146o15
SBJlUxUyBwH3xJWAK4ESJUAM0WClBbuGXa2XTLzo0cG4/NEPD8CuRy6MRIeLHzR56kuHxwplG7d8
TB72qGHX3g6aLm45xOGeuBI4rBI4VNzy61yVFLfIXizOHHWHg89Vr12DM0ZPxB8+ncvc9GZgzaK3
cGGr8/C5PbfoXP2aOnUuh55kz+tL2+/rwH0x2Ur1UjB2/TRjAm4YdgnOP+cco3P16nU6Tu/WDV27
dkXnDm3Q9Lzr8cyUgM7FOtjrUarMusQPLgGOfvKbzsM3EsovfOArf/DH3bulKwFtJ4w9YeK1LR4O
8VEec/heV7lsS3Y83rNjtUOIuYUycC+/R+KbGheY5iC8DsTbMYR59+1wGi1y8yxvdhK201F6llzD
EGWfsIZ05GYFBq5J184naVkmOaYCdJUXg8fWLf9fDnhr8OfTF2duBLzX1IChscWjPm3FyhNjM+Ae
0Qyjnjzflmkazut4Az5avBJ7k5Oxc+MyzHx+NEb8d74tzxkY1K2u39CgfNkylJuk/f2Eywg424fK
qNxUopwy6hocyumLc9l2JeBK4PiTgH7oqajUOXMYbuWaSLYw+5mRaNOgujXjISoOdVqeibEzAxl+
355ilA6lk9D2Yjw7KHCfqZVT7kWXxrUQ1eks9O7dG5GxldG57/X4zpGtJyY9fREShQ/yoocji56I
slScIqQ8HEZbgpZYYkzFIqLxIMx65JwS8xxwY81X+L+xI9C54SDM3Zxv6qq8H5DXveBKwJVAiRLQ
dlOr51DcFoRdnz13LVrXr2bNTIuMRd1WvR3YtUywSzsGxyVuNRro4laJvyz3hiuB0pPAoeDW70mp
fsZIp0L7oQfoXH+8fhe6nFAbESf2NjpXVFwVnNj7Wnzvf5KJnpj8zEBU8OlTpFVSEI3LPzgUnMc8
V/KjwdkP6dwMcMkAmqfhRZj7xHl/n9bqr/DiuKvRvs4F+GKL7Dnh8yr9+wTcnKUhAfP9lfcZEsJZ
zmJiEH3aBBnYlk0CSqNIl+Y/kIDiFB9hmu2GA+46A17bkT3fPyB/1LIqjnAmOr0C8rOc5q1Q2deL
dYyWJYNjZAm7WNnjMC4uzn/wun0/G9LwFgQG9lkxT1Go8RagZwRp8EhISEB8fLxJkwZlWeDAzlhE
RFqz5tk2yF9BEN1QWVKYZStvpEua5JHeCc79CcU8Ie2L/Wm+K9bJeDBwZNwfQhAVbdVR68pY60gj
kyMIX/QK4aFyjE9w1h2yO9iYyy/AKTLJ7vS+g3Dfq/McJEa9cC/aJ0aY3xR5M98QyWFPOx4oByfh
YmiokxiFunKI4w/CfHjG9+iG0pFA0C+zdApxqboScCXgSsCVwKFJQD/ypGKlZZmRKTNwWdDAXcml
3ITHL2kXdDsWvR9YiPHDiiGyYiEWLlwYlJ+nF2PKvP+ia2XfUktyxc5bMQ/8o0u65ZXjw18kPp+2
oHlsl0pMct6K6Sj5FYld+Gnxp478TXr0x0X9++OMM85Azy5dxLuBKy0Hh+8wqPXj2BJ82T13JeBK
oEQJ2LEh0EER7HrrQxQHO8UTugGPDrFjV9nFrQP5d2JXYB7dgTmDr+QLZil2FRXtdHErWEDuuSuB
UpLA4cEtS+dy6DLi5fDPda7BeHPes0bnIl88iKUaaGA4lFC8PpXlIPmPcMvxJE92Yckix+5faHJ6
Pww8+2yjc/UqUef6FoPbPuHqXAfI8yhfoC7t16ct/d/xezyIMewoc35cFK8YobEABl+SwQz7eypv
wiCOctC8ZquODtbz8gsMJnKQXo0s9livqzxIp06LUxw0diRn+eWjnhH6HGNLd83C+qVLbM9Z/KiO
ZrvhT9qX/1W6pEWa5Ke4oN8L5deZJ/Ae7fwFeDw4zaKUxRh7rROLnfTtZ01x14uf4taetc1FSwYl
G7PtT5blNOVLKcVHhSEuSryA+D7kXdi9Ucoy/+WVt8CIUXmtgcu3KwFXAq4EjlEJqEJij5nmLIyc
nBwgpgnu/GABun/4DiY9+Ap+9MmBMzPatWuHb7/9FjhtMMbfcCMu69cOsUUyOyTfmt1A5YezJ/Ly
quCs26ehVc/PMPWdN/HulwF31T6yxNC8efPMzA0074M7Rg7FwLO6IC7E2jSKvHBmhSqxPPdExDve
Ro2YSP99+w1VqjwRQDdxp1+xYgVSU6sg2vdV0jrzmajEOugvBoE5c+bIWYx/DWNV9HTmhpkxEmtf
NioGUbZNrUlz1buP4yGbvaHvmEl4TDZi5D3KhLNPKNtQcdPd+ed8PHr+zbZlDZ7CrN/uwujO1nqf
9nrb6+amXQm4ErAkoO1c2zPbDNtZQXxz3DF9Pk75YCrefPg16D58ffv2xRdffGE6lsSuJ667HkP7
tkWMtMecHGt9Vc4OS08vLBG3GjRoYGalrZQ1wovDLfLwV7gVJx1C8klssQetD3GrQoUKaNOmDb77
rgqibNq04hLjyiecglq1ViApKUnIxIBbMeh9pc1yuK5seKx9+ZVog4XMS9klzX/voLhF7OORn53h
4pb9hblpVwL/QgJsdwxse0xzQOdguFW9enXUrVsXP//8s9G5nrj+Bp/OlWdmvbKtcyYqdYvc3ET0
vWM62p/1BSa//hre/zqwvAf1nM8++8yUiea9cdeo4TivZ3skyNZa5IXYRf2Ps3Q1hIU7l1mqEx/Y
jFnzMFYMJnb16tUL33//vfBT2a9zaV7WlzpXv379DC/BuKWy8cvFgVuWzsV7rDNltvytcXjANsbV
75438MhFbcw98lSxYkVkZWWJXleArSu/xPgLb8FcZQZPY9avd+P6DvHF6pH+bG7iiEmAs7B5MPD9
yeRpFHit7xSv6e+DaTcceQkQq/gOwj2RBntyc71+7AiTGfC8z6B4cOQ5/Gclsi6KJ8QUj+h/9jDr
hzW4vsuplseA4A09CoiTPBjsz3OmP0M4QdAWXl20Cvee3QQRtucpH32WOJabtgO/fm17CHURH2F5
NpQky7Awix8+T76s9mJ5HFBf8zi8FyzM1BL0PTm9IMRzRWiRHp9nHSkTxdowbt5RQmBddv46T/wZ
NAzEazOHIXLrMiz6dSV2JsuYguioFevXwYltOqFtu+aoFCmz/+X3wkM9ZeyyVUrlKeY7iPKEomN9
63cUJZuq8z2EynU3lJ4EbF2k0ivEpexKwJWAKwFXAocuAX4o+bFXF8rMzExRNBJx6uBb0H3IzchL
S8M+2cSqw4knIl5cSpN27kd0pPUMewXsIlDpoPKQmJhojo0bN5rOa90T+2Nct4twf04GMjIykFCp
Gpo2bYq9+5KxaccuVImLMhtjUbEREiZUrVrV8EI+uGkWQ2TjAVi5/DSky9qWsTIg16RhQ6McpQlv
GsiDhlbDXsI3t1WVDmc2knbvgsf3zbfn6TD0Gcy+qTJ27tyNnXv3oapT3zR14iAkDS2thzyLZd3v
QHZ+kXGpjRCFkIF1rpRYAScO+S8avvSbbFS4Eeh+H+48v5WyYgYQ69SpA9aHA4R1252Lx6eswefD
XzB5KPuzGlkGDTt/fgJuwpWAKwGHBOwdMbZBHVyycCQRpwy8CWcOvx3pslF7XJUaaNKkCXbv3Y/k
1GxUqWhtqFdE7PJhBjGHA27btm3D/v37EYxbBSEetG/fXnAyDGs2bUGcdCyITXbcIn5WkQ1d6QKv
uGTHrUjBknq1avl51QrZ2/wJg59D0nWVxb09Gttlw9MCMRhoYD4e7BS2v/A+bDj3LqxctRYeuutL
B06D5iF2sTPa8OxxWN5zDLLyCkwd4315q1SKQr0R/8U1S3Lw8ssvH4BblGv9+vVNeZRLMG6xvPoJ
1sw0ysENrgRcCRxcAnbcUp2L8b59+6RtO3ErQ1wEqHNFRUYJFuxDXLQ1oBdKXUmKYZsjFhBzaChY
v369wZ46HfrjwY7n4GGZCJIsWFa1Vj00FH1pu+hbu1PSkBBhDSapbsXya9eubYylqampflyLbHQO
Vq3ohTTR/eJE52rauL4Z2KJxgxijdbEwsAhth7+EL++sIdiXLvzuQAUbJlEqfObEyyZgznXxgrNJ
SEnPPAC3mIdYTuxpOfBJH27RqBKNBKHH+xygShSdq8OFT6Hq//2CPYLxOP0BjLmglbnPPJRJLcHa
lJQU7N27F/VE53py6nrMvfR/5gURF89tYp9EYi67f8qIBPj71n6JSfvOywh7xy0b0rSMzuQtLEJa
tlf0oRBpw9aAd3kUCrFCQ2ikEw/WPPcZNt18OtpJ/1h/i4wV9/icV/q0uaKr6YSPiMTqaCrX/1Si
b87A6nsHoEMFaykqYq2WSYxjeveST2GzmwKXdEQ924Q2JWWPQ0QPVV5Ik2niMGNzXoJ3mp334GFw
pVdcXAI5P0u716/1p9G5EVo1aIDKLVrg5L4y01/wmoGTX8ijGrXJJ2Wgwc6bXisvsfIeJnWKjrDe
a0Q4PViCpVxealR++Az4ZJYfnl1OXQm4EnAlcFxJQBULfvh5ID3NdPZq1KhhFBcqCDk5XoTHVUQX
cU9PkAG1gm1bULtmZaM0cFCNRgTmo+JUqVIlYN9ehEvnlx1cKhq8zllmQgV1GzYxxgbv5o2oWqUS
mtWvjezsbPM8B+mofHBgngNlBZKHMWdbkAaPQhn0o6eAMTZ4ZUOvPbuMMYBKjLXOpTXDg+VyAJG8
xkZFmkE+1pX59OBanJUrV0bexvWoUaMa6tas5r9HWlSKOIBIBYL8VqtWDfFiTImO9oisAutrmjrv
3yubfnmwYMECU+9RQ7vJfA5LwSK/rBPLYZmULTvsBeJ2yUC5v/7662hVLRoFKclivynw19dkcP+4
EnAlcFAJhObLLP7CAtPOOADHtm7hTh5qNDjBGBvyN21ANcGcmlXjxYsh3eAWcYltkUZSeiYwD9sq
B7yIE4pblarVQseOHREh5YSlpaBFo/rmPnFPcYtGSQ5yFWzdLOvnhhmcMpgldIpCIwyW1K1Z05Tl
lXKILeSTOKNr4TI/ZzRHSwfeK3RqC1ZwYIz3WQ4DMZLYhn174JE6t2zZVDo4VidW6TAPjSfEUNar
ppQbIpgYHc2Za9bau+Q1Nr46di5ehIkTJ+Kaa66B4pZ2CBs1agSPlFsoOMsBSfKnuEVezjrrLAxo
Jl5ZqSn+OlBuzMfDDa4EXAkcKAHVu8xgi+hcbM/UI+y4FVWxitG5YmTmMPbsRB3RuWggoL7FiQvE
Jj5P7CrcsR0RokdQ56I+wfbLvPlFYWjYtKW5TmyrXbM6GtasanQuu9GAmBdNvNiyyUyOIOaQFxPC
Is21JoIFIempcqQZTFGsYcy2zmeo27CcChUSUE/wQnUtzcs6Uh+iLlSnTi3UqJponrXnI16FC73C
HUkGi2MEV2NiArhFfDd1TtqK6g0bGE9Zym/UJScj0oeT1OtobMjdsM5gOc+Nnik4yUBeP/zwQzSS
dba9yfuNvIivLm4Z8Ry1P/LVlnHNwHfD3y85ahy5BVMCilcGn+Q8PacAu9LyMGdpEub+vgM54oXC
d6X5yrrUgtu5nnvqnoZ7T7Jz/y7unbTIGHWJO/p7tOJC/PHRY4gRTBs+6Q8/dofVOhmX97TT+Bq3
Pj0H+YLVGkiLhwl7F+PBERP1lokfvuxUhPl0KPJWXCA8Kx1+B/Tw0w16SOloHHRbTkNgX6bJXlfz
Xg98wH+FNMPtjh0/PYmbxk3C10t+w7JVq/DHmjViDN+MHWIYpgFYhhTM2AD76TzIM/nXMsvL70gF
oHzr++CYBb8x9nfCdHmrl9avrMfWV72sc+ny50rAlYArAVcCfgmETp2M3OlTzcAZO49UJPiRrFev
ngxqRSD71lEIGXIO8levNAPw/KiyM8k87ATSAFA4/ALkjRxijA6NGzc2H13S4SAeB9NyvpmHsAvO
ROYTDxpjAQeyNLCTaJYe+u/jJo/32/lmkJ6GB6PUiGLCQbBwr3SoZRmmouEXomj3TjN4RxrMww87
O6DedWsQcsm5yLp5pGzeFG46w5qHA7Vn0s0AAEAASURBVP8cIMya/g485/VAxhsvG+ODDjSSDsuk
sSH/nlsQOuRs5K/43cz25bMMVCpYH5lCCO+wc7GxzylI9Bkd/lybBK/QYEeX/Gb/8C3CB/VF+tg7
Tbm1alXB9AkvGQWLxobhw4cjacJ/gc9mup1eI133jyuBg0uAbdQf9u+D9/orZIO+QrP8CDGA99n+
ONieNfdThA3oicz/PWXaHwe+iFsc6GIeDv5nP3wPwgeehdzF3xm8IxYonnBJk9DsLORdMQhewRy2
ec78J/4R+4gJxC7vH8sQenF/gxkewRwO6msgnrLczCmvIuzcHsj76H1jFFCjLMsibkUI78Ss0KHn
wrt2jcEYzaNlFe7agcJhFyD3qiHwFHhNndnpIQ3yxEG7gu8XGgzNfuZRU2cOKmogbpHnjIduRoUr
B2HpKy8ao0NV2eWOuMXymjdvbowNOSMGSVmCs4LtdevWwcKZ3xgyNDZ8/PHHyFyzGkVjbjKyVPpu
7ErAlcDfk0CIYFLOl3OMPkW8UMwxEzYEz3JHXYqiSwegMGmbwQIOahC32EaJUQUywA/BitwbR8jy
a5Z+pFhAbCOmZM38AOGi52S+9oJ5hlhEGsQT4hiNDTn33Y5Q0VEKlv1mDAzUbxhYDnUYGhoKiH8j
BgNpqUY/Iq+kQ8yh/pf7848IG9wPGffcavBF68N81KeIOdmv/A/hxOJPZhh8VJzVPGFCL0/qgkvP
MxM9yB/xmfdZDid+FG7bgqKh5+D30zujaUPL6LB0xWaDXcR7Yl3G7I/hOb8X0p9/yvBWs2Yi3n/m
f4bGjBkzzFKaSfffi6Iliwxt0nfD0ZMA5U8TFw/zLuR18I2Yt+K+mqP3YoopuUC8G/JlE+MMMTzw
UC/RYrKWs0sV0Ovyaxw8//DYJRj60HRs2JNhXffmIGn1PDx8QQTaDx5rrjWobPeMiEXPq2930Fj1
ytXoc9vLWLEjxVzn77soPx1//jBVJmycjS/subs8gP7Nglzt7fdtaeI3Dw2aNnHgst42seaxThy3
DumkYdc+jud//vB5XHfZxbjw3HPRX5ZQ7tmzO7qfcorsY3gSOrVvjWbn3YCn3piHpDxrsiO/WeU9
sA4hITJBUfCKR1GRIlp5r1nZ5r/8/3LKtnxd7lwJuBJwJXDIEjCKj72jJcpLxLi7kPXeFNNRZeeN
nU26zGbIIFjMvM8RmpmBkKsGI3+NZXRgZ5Ad20IZ+C+8/CKEy2y7yGW/ymDYxWbAikuZsOPJTmDW
gq8QcctIrgWA2LdeRdpjD5jOLQ0aHNSjESDz6UcQ9dr/mU5H2OiRyBcDBTulvNegQQMzwJYjA21R
v/+MMHHbL5QBQA7AkQ8ONNJgkb92NUKvvFh4TUfswi+RLXRodGCnmPmMUWPGe4iWuhbJM7FPPWSM
DrzOctTYkDfmZkTMmoGQnGyEjbwEudIZJw+kYwbwZOCxQOocsWM3WnlzsclndHjjpl74ef1u0OCS
8d1CRN40AiEygy5e1pXfdetVUkYVnHb3DOPZQGPDghvHoNarTyNPFHmdNa0zB03n65DftEvAlcCx
I4Fg3CoKkT1eFn+LvGuHQfyhTLvjoBqNmRlzPkHUXTeYyse+NAHpE8abNs42TFwiHmQ9dDei33uT
C0bDI4Nd2Yu+MQNxxDVjNJX2n3v5QESu+QOebTKwJYP9RWLkIDbSiMBy8pYvRagYWkPEY4uYkSvY
EekzSnKQjGVlvPEKYsY/aDDH88AdDqMDB+NobMgZfbXBLOJs6JWDjdGB+McBQOITDazEWWJflOAs
sZAGWPJArwbSyf9WjLo3XWkwNHryi8h48iGDs8RY4hbpZAofce/PMPvWNJvwqDE6PHx5LyzdJPU6
oYnB7uwrBiL6j9/hEXzNvbgf0sWIO+L5rzF69GhjbNi+ZBlirx6MIsFBM6NaZla7M4WPnXbm1qR0
JODAL/FSirzjemN0oNGSxkDiCnEs66pLEP2LDOKLNxPbfMH2rWbiBNs58cQYG664CKHiYRT13Xxk
X385osVAQMwiHR7pH76P6PtuFS+rUMT+9zGkvfy8eZZ4QV0mVvAv+95bET1zGkLEYyt01FDkL/3F
4Br3kqFuRmODV8r3bJDl29atRoHoVjQ60LDJQRbqTPm/LoHn+mEIES+wOKFFowPvEx+JsUxnSdnR
zz0hbp2yDIvwlP3pR0Z35D2WRWNDvuBW5PcLEJqyHyGCP/QupdGBeE1MpwdZEfEvLQOds9P8RodJ
13TDH9tSDL+psz5EzN2jOTUb8S9PwK5HxwgftdDq2smgseFs2VR6wZArUevDN0TnsrxjaThRI3Tp
vHWX6sEkEGJuclk+MYQxLX+om/OwLpgM7p+jIAHFK429oifx0MB2U577KxyE50Esq3PmMNzWVGtm
xbOfGYk2Dapbs/Gj4lCn5ZkYOzOQ5/ftKX4DLukktL0Yzw4K3Gdq5ZR70aVxLUR1Ogu9e/dGZGxl
dO57Pb5zZOuJSU9fhEThg7zo4ciiJz6e9VRjrYvVnvRq6cT6e2Ac0XgQZj1yzt8vaM1X+L+xI9C5
4SDM3Zxv6qq8/30iRzen8stY31WRGBx2pHqRlCLtQ8Ycwjz0jLG8N44ut8du6a7B4dh9t27NXAm4
EjhGJZA18FLkNW+F6EfuQaYYHdhhjZXObcbNVyFeBu639b8AK+6TDqO3wAzoq9GBs1+LZPYbB8F2
3Ps4dlxzK6KW/4YcGTDjkhwc5Mqc/yWibhuF/IqV8Nujz2Nvl25ImDoJaY/ebwwK7FDS2BD7+kRk
dOuBrS9NRUGVaggXA0WuGCrYceVsXg6wRctA2/Yrb8T2+8QTgmVLB5QDcRxIK1j/p+GNHd91457F
zgsuQcyCL81AHgf02DnOEWND5IP/QXbjJlj538nIaNHGGB2yprxmaHB2cp50WCNnf4TUAYOxYfyL
KAyTTWmlM06jA+XCWc40NnAActMt9+DbNjX9RodKkREYLTP0Vrz1BmSdEmyTznGTVdvwRkoWqn8x
FwvO6YVzzjnHeDYsGD4SPea/hcwupyCn99lGcVVF7hj9mbnVciVwWCSg7YQ4kX797YiU2aq511hG
Bw5O0dgQc/dNyKlWE0sffwH723dC/KvPI/258WYAi4PzmePuRsz7U5Daow/WPvMqCuLiESl4R6MD
B+jDc2UzVjE2RK9dhXWCOX9e/x9EyGxjDsCFyBJoxtgg3k/EBg6ObJvwmsGMKMGOnDtvlPXXI/3G
htinxiFTsGbDxKnIPaEZ1OhAA6dHOpg0NkQv+AK7LhhisAtiSDBGBxno54CcGhvCBfO23v0Itl15
g8FCejrQ6EDDBI0N4ULHKzLZ+H9vIu3k7oh782Wkjx9n7jNPxhNjESueFsldT8VHpzVCkuC5Gh1u
EG8uT34ulp/aHjFibLgmKQX9NuxC+J69SL6wH7w7kzBhwgRs//YH1L7rSoTIYEO64B8HHDTwvbjB
lYArgQMlYG8bTGdecR3ya9Y2Roeszz81HlmyPZYxNsQt/Qkbh4zAqtseQLjoG5ABeBodaMD0yrJE
HJAPlaWVtj4yAXsuGYGYRQuRdZ1ldOBkERob4sbegaw69fHb4y8ipWVbJDw/Hukv/89gEo0NWeLB
GfPJB0jpOwDb/u8NFIphM+zay4zRgXpOaIYYG4ZfhMhN67F19D3YPvpuhAsWFohuR0OEMXCKsSFc
jL0FUTFY/cQL2NuzrzE6ZN9/uzE0EN9yXv0/xEjZGe07Y9WEycgRnqLuGW2MDtTJuIwSPRsixHCy
Z9jV2DLuGTNhJFQ8rGh0oDGGxgbKgMvabb7/CSxuUsVhdBg1sC+WPPUYou+6EX9kZqPeyq34ND0H
1d95CwuuuASXX365ZWw4ewB6LP8cGb3PQXbHrsYwa38vB74190qpS4AjpPxu8JC0DAGLyU1O5WDa
DWVHAmwr2l40Jnf2dNnh9uCccLBYg5WuhhFvfYhhQUYHzXNgfBMeG9I2qO6x6P3AQowvjsiKhVi4
cOGBZHAxpsz7L7pWDmyBa+etmAf+0SU1DzneUVGmg4bmcVws4SSP7dQXLJq78NPiT/WSiZv06I+L
+vfHGWecgZ6yJPNJJzVz3LdOvsOg1o9jSzF3ytslvi96+3DJsTRZN8pbwHZCHAvIqrzVqTzwG/ag
hPLAqMujKwFXAq4EdHYG177lxpo/b0o3QunUQNaPlWUmImTWGD8mnEHPcDgVAUPwCP9RpYOzupjm
rFSmc+RIl8H+yKU/I/rj95EZXwF50lGMX/gVtvW7AJvOH4K8hApIa3siqkrHMPRTmcnbuBlCbr8O
4buSsOWOB5HapgMy6jVEXmJlVJ47EzkycJcbLTPcZNmNvAqVsELy5IjRYV+HLojZvQOJcz+RrSPS
kCfLDsW98RJSTzoVW24ag7yoaGSc0h3xP36PiI/fQ3bdBvA+cq8ZYNty+bXYI53avGo1kN2kBRK/
/BSFn89GfoNGCL3pKm6egA33PoZ06dSmywBfqNQxkbzIUlD50kmOengMshs1xdo7H4JXBhiTO3dD
nHSiY2VmXlZsPLyytFT0nI+x7+wLkTRsFHKiY5HarjMqfSczh6VzntO4KYruvEGMDVuwSTrg+9p2
QljXHli2ZilO2b0Xa6e+ia25+ThBZg7vl8G8Hpv3YWN+AWZJ57e+Jwzn56RiwWdzsOmHX9Fj0SdI
PbELtsqggkcGABg4m/lY+r3pz7ukdta5odXOuHzDsVhvrf/hju3tN0dw648k2exddNv6laNkT5Ew
VIjlOqLWxmyUa3nHLZWfvd5M0ysoVwylOZ4IVBBMyv5lCfJkphFn0dLYsELaVo7gVnKnkxEjBsKK
YgxIz5d9WubOQtz0t7C/+5nYcvVoeGPjkNLxZFRc/A0iZk5HVv2GKJSlRmhsWHvFDdh90mnIrl4L
2XK9+ry5yBePr7yadeAZLZgj34ZNY59Clpynt+soA4GZSBAMydqwHnnbtyH2afGiatYK625/wJST
2lWwTQb0Iz98FzmVZQk4zv4VY8NuMZBuu2Co4GxFZLbtiEoLv0CIzNjNa9IckCXtaGzYRJyVwcOM
+o2QL/kqfzELOYKT+TGy581/roe3cjVsHvc0suRestQnUgYpK8yROnO/HVmmLv7t15AsdflT6lzh
xNOwaK/sqbMpCQ2XfIffsnORcscNaJeXhWt2pOJVMZKuF+z6KTsfoxKisE+WodtUoSYaPnGXLGFV
gE33j0dRs5bm1dhx61j9vTnaWRWrnVU8RtuZtrfDHav+Qb0jz1uIzXuzzRIdnvBQRMhRu1K0xGFm
bWf+jjh78FgIWm/FL7N/i3zrkzufgpgfv0OkLLOWVasO8sUgSGPDhsFXIKlnP+SJ8TBD2n81wYfC
z2eJniNLVQrmcJm3zTIBJEP2xkoXbCmUmZSVPv8EmUvFw1QMpXH0VhUdaPkt9yFP9Jz9MskjbuNa
g5Hp4R7ky/KZcZ9+iH19zkHSiBuQJ/iRLnhR4duvESa6UI7QLaKn1ub1WC+G1hR5noYCb936qCjY
5hXjZn616jIp5GoUir62Viab5ArepopRwSPG2AqfyZJrSdvN8pb0bCAubrztfuTJJtj7pc4VZFJK
9Eei2wmmFkx4AlGLFmL3ZSOx65yByKmQiFSpU5X5n6NIyspteAJCpZww8azYcNdDSG3cHHldTsOG
P35GN1kb/Ne3p2Drzl3o8PbLWJPrRS/RuXbKsi8z0rLRIcqDPnu3Y8GSn7Bp2ofoseYH7D2tF/be
PIabaJmZy/x9qf5xrP3etJ1t8bWzcNEJ2M7qHOV2pu3A7AGXl43wbeIlmJOOiLRtprnnx9USZVgm
EdU9EdzQ1/59YYZjRZ8xlS0Hf/g78kp/Jl10gSxpY3/uSJd3ALSpI5M0wgM4re9F47JWNfLFQ/FY
96xi/RjyEY9uFw9Bh+oR2L3gF2yXa23btjW/P+5baMJpg/GETER7Y9IlqBNheUdxfIC0LHrRaNR1
IM7t2gBFmduwYsNeM37ApSjXrVtn0eDf5n1wx5j78ewzl6J+nKwwIN8Denwx6O+d/abClA3435uf
mevdunVDp54D0KZmnPk2cpk9rQ/bFL1NQ3N24eVp801+oAuuuLkXaggOaj5zIy8dr0z72penNYbd
eDZqRAo2+PqfvEEZcb+f5HULMWXucn/e4Tf2QU3ZE4zL3LG8XydehesnW+2WmfqOmYSXbrsUp/fq
hYsvvhi9xavsoosuxegbrsWg3s2R9N5nWO+jVrXqWtQ98xp0rhVlrpDH8hbIM2WfKcaGT3/bITpN
JhrKfnFh4s0X6RFvFd9vjvUqj/Ury+8jRH6krkmnLL8hlzdXAq4E/AoHFV5+LLgR3970XLy0IMlI
55oetVElPlLczi3XcX6IGcr7B0PhWQeAqTAwzQ0JqXTlynIhdR66EzF/rjL13d7/Qmy5cKiREevO
Dlns1k1o8fSDCM9IR6EMFNPYwA4lg3YkKsmgXN1J/zPzk3LEOPDHf8YhV4wNLN/QEct/E5lxXFkG
uhhSxNiw9ea7zeAdz1lOePI+NHjwDkTKUk38qGyVGYG7z+hrnldFq+Kq5ajzxH0IlffIGcobpOOb
JYNxrJPSqfHB26jx0bvmPOuE5tgkBokc6XSrLELzctHk2YcRt3KZybP/7IuQNHyUua9yipAZdk0f
vxcemWFXGBaOjdJhTT3xJKNgkg7lWGnhJ2j9/numzjvl78Vrd+IbGbBj4FIJtRq1xHik4ZQkS+nc
J4OK226/H+FilKGXBzu9nDXIuh9rv7fgdjZxvtXOru9ptTMq2sdSvc1LL4U/+ptlx4ZtzXQIMnIx
7efdZlZN9yYVUDE2AvVE4Y0QA5d2ICjbYyFoe+TviWluCMqY+JUw831UFy8phqxadbFSMIeDbZQZ
6x8qXlJNJz6DRBnQY9gvA09bxSOLyzIRk5gvTJYQavrYPYjcu9tcp2fDnq7dzT3Fv0RZ0q3JC08Z
ehz03yAzbvPF0GoP1d98CVVloJ8hvXlrrJXBtiIZmGPHlHSihZe6grPRsgQcw+4LL8HOQcP9yxIx
X8zmDWgsvIQRZ+X7s23MI0gWWuRT5VBdBiLrvP6CwZxcmS29aezT8Faq7KdTKL+Thi/KWuZLvjfl
7Bdjw8brbjODvKRDOYZsW4m2z09ARZEhcfY+8Wx4TIwNDMStmo1bYVCNSrhh6XyEC9/5YpxZf89j
yBfjK70miMX0MCPPx8rvjbJhOKCd/eRrZ82sdla/aoJpZ8fagKWp/GH8o/LU3y1xKyMnHwtX7TMD
WDGRsryhTPDo0jhRPCs9ZjCD7YS/rWMhEKsZ9PdkNqUXfYu4hX17Ufu+WxC13ZrruUk8G5J69fdj
DuWQKMsZUUcJE12lQPSFTeLhmS26jOpblG81GcCv9cFbppzMeo2w8o6xZvIGLxj8E0+o5v97AhXE
2MmwV7wqaWzghqEsgyFSvJgaPHg7POJVwaWYjLFBDASKW2zfFRYtRK3nHkOI1Cm/UhVsfPBpZMgk
E33HpNTgzYmo9LU1SEbPhg233odCeZf6/iPFYHKC6FPRgnEMuy8diX3i3UU8Ih3mixFsbPrUWITJ
snYFYqigsSFN6sz7/P2w7tU/nYpms63ZteulDpes3oGfxNjAQOyq26gFns/fi7Z7tppru7udgc1X
3YSK9JoVfYveY/yNUf+gDFjP8hz0HaictZ19u9pqZ5EyGYHt7KSj1M6UP/Y1+P74+y/M3I+IJW8i
NG0HYrct5kgnMmt1QmFCTeSedCVC4yr79WK+Mwb9vZbnd1UeeNf3xXaZLwaHHSnZSBZ988sVe0Dj
1SUn1URiXKRZ0tHefsr6+9H2Qf2RbT85Odn8FonL/F0SE0JDCxEqk1MayKQK/l5X/rlBfocVUaWi
NTjO96d9Fi4dx7a2ZcsW87zRqwRPeD0/Ox3VRDerLMbjtWvXIml3MmIS4lElTvbP8eEYy2vQQJYN
lt/33r2WgYL0eZ+8ZqbJMnPhUWjatKnByPT0dINVilv6XeEzxLS9YojdsHErEiolIJK6pPDBd8L3
qct0btm0Cbv2JCNCxjiqVIw3dTZLCkt+Lt3HsHPnTtO3zZANn7Pzrf14IiJCjZcc6eRk7cM1levg
Len/mtD9Psx78hxUlO8El+Tj0qSkkZqaamTF+iV/+zROHP6CWbp53rx5+CGvOq5sV8nwV976Kdo+
KP/90i5em78Z3OdkyCl1UEnahZmQIoYHbQ8aW8Jy/x6qBFwPh0OVoPu8KwFXAkdMAqp48INxPHg4
BAvWXn9+PPMkQ0rX0xCzYin2i8dD0uDhRrGhokCliB2yAulcprfpiAq/LcHmG+9EugycM+jHl+lM
zsCVfFGyBMmaux81SyTxWaUTLvRSO5+MKOng5taqg0033mWMDfpBptLHTmaKeCAk/PYjdgwahr3S
CTcdZ+kIa8itWh00IsQJvxvGPIxsmQFIPuz5Mlu1M3tHhMg73iDLkXhl4I/3WZY5ZHZ0shg84sTI
kiqda3o2kAYP5ccbn4A06ThX+PVHbL7mFqSIl4bmIS/kN6dBc2RXkU1Zt2+WOj+G7tdchyuuuMK4
859//vk447STkX/KaYgSQ0qudNTXXHs7ImTwjnKhgkeeOGuEZdr507qW59j+O7O3M9fD4d+9Vf7e
+PtjR8gx8/oY93BQaWn9iduUAw1+9HjiDNrw/XuxTjCnMLGSwSyr8ygGBzEypsryZdFbNiFLZg2r
sYE0tZ0X0tNBvCEq/LIYWy+9Gsmn9TwA//LEmJEjHlVxspfNeiknV2b+MigekDdiIj0dOMi2/vax
kB6fo00XiNGSOBsng3/Jp/cx+Mbntd2Tnlf4T2vdwcJZMcbSs0H5VIzIlkH/goqJiBAcXS8znvPl
GdLRECLYwvpEJW1FtvC58brbxZBibTLNPOQVFarJrONuqLz8V2wcMATV77zPj1vnnXcezji1K6q1
E68KwdbEP1di+c33oECWhSKv7PBSvsQtnhPLyJvyqXyU11h/Zwe0M9fD4V+9Uv1tUp7Hk4eDCkt/
T4pbHJgqkLazV7wL4n/7CTtlGce9ssQR25HqW0x7q9dEZtMWSBDPgA13jkOWtHsGezvLFGNkIdtg
Zib+FF2oSHQW0lA6oaJzpXQ5FbGy9CQniGwfcT0JGDqKXfSUShGvS+o5W0fejDTRixSTWBb5z65T
z+hsMUKHmJMjOpjmYRwq/FqeDvvhFU9ZejYUSdkMrAuPwohI8Wg9DfGCOXv6nY/d58kG9cQiXyAd
r3h/pYmXasLvvwiN+5ApXg+qR2jetBNawSuYHyETQTbcNx49R16NESNG4ArRu4hdPbqfguxupyNu
2yakiUfuRjGwhAkvHICjXKh3qaxZP5Z7LITgdlaWPRxkRBah239HSG4GIn0eDnkV6oqBPgEFtdsj
JML1cDhav0n9HbG9FcpAalZ2HvJkEtX25FzZdyoULWrFIUomtrAN2duPHZeOFu/FlWuvD9OsV7jo
aXEyME5M5gA/A9Ph4RFo1FS8+GUSnkd0x2o1qyM7M9Xk4X0exA+znO/mjYisWs3oQTQGEKcY+J2r
U6+BLAss9DdtQNXGJyBGDOoFueLZ56NBzKFxlMsGc0+sWKHDe+SPseExIsrk4bJ6EeKx65FvBnml
3JmP5dEYbJa5k3Lia9cRXjxiEMgy74VYx8CJbVy1IV904EoNGspzQt+bZ/rlfGfsn9PoAPFSE+YR
I7plpnxP8iTtkfccLt5RXAaP+whxubvIarVR6cQT8e6MGYaHq+8egy7Vo8zeO1WrVkXuhnWoWLee
MZLQuEhec/b/io8XbACNDU0bNsAvG/eKx0asucf6MJTV349hzvbHahdsG/JdzPPilw3JUg+gRe04
493AtsEvrH5Xyku9bFUs00nXw6FMvx6XOVcCrgQoAX74GNjh48fiePNwYJ0pA9PhFWWFygCVI8qB
youXMz1ESVE5FfehDKVSJEoO7+l95tdnTFqUIs1DeWs+TReJkiVPy+wNSyFShYP8MRhaMphIGnpu
L89clD/c9FDz6LXguLg8yquhKXs/FInxgUH5NHXw/VaCeWE+yozXKUfG5Jt7SCgd5uF10mNs0hKH
iRYSKp1uKm9U8jhbhDE7wlROqDwyKB/mpBz+YX0ZgtuZ6+Hw716mylM7Iux0cMbZ8eLhoLil9Sdu
Ea/YKWJs2qHIhJ5Xpq1Ju2NQuTHNvQekkYGD8cHti/nMc/wuCA0N9nzalol/0qszWez3eUH5DCU+
2HjRjoefrg+37PzpPY0Phluax47FvKb8UCamTuRD/oWIoYPB3qHl/ZJwi3mVN9IM5d4SYrBlx5ad
WO6vw5jnxG6mTb5yPnCnddbfmb+duR4O/En846Dy1N8j5Xk8eTho/fU7yPpTd9DBKZ4X2XArWMBs
U6ZNcyapYI7iiMYqV/Oc5LFjVzAtg0lsp9JG9XnNo3yKBdehTxWXrzhcUjomFlwJ4SCaDNaVFJSG
qZtk0ljro3VW3U6vB+MXcYk6F/lXGva0AJ7RMaNlMI0YxVnA1LcYE7d0oofqnyXxW9av6/tTOWk7
K9MeDhn7EPHTFMvDYesPRsQZdbsaD4e8TsNdD4ej+KNTPYZYRQ+HPSmZZlmlxetTzZIxfVpXRkJM
hH/CFNsWg7bBo8h6sUUHtw9OVIm8/VrgFtmfpnlLbN26FVw6idjQuLFMXhNP10LZx6tI+mcRk6bB
K/2ybdu2mfrR0MAZ/Pk/fIvwm0Ygb/AwRN0l3v5icNi4caPRqXTT+4xnHkXMW68i95mXEd3rLCQl
Jfk9GVhORKHorldfKstmim/8mzMQIgZm8kFa5MXs3SP7eYVeeTHy23ZA1HOvgYtAsX0zMA+NHzmy
NF/k2P8gU/bWirvyWuO5QY8J6mfU1WhsyL37FnjEMzb/5amIbHeiqQ/fMzGQ5dDYUCj75UAMuaGT
3jMedRs2bDC6NevLPYLyfvoBnusvR3bvHoh9/FXMmTMHF154IeoNeRzfPnkpqgudtOefQtxr/4fs
x59HrOydwzqnpq7F+7cOwsCnLWPD76d3xrqH38T5PWT5Y/kesR787ZTV348Rtu2P4izbh93DYfDJ
YogRD4dEWXKTnkD6XSkv9bJVsUwnLbQp0yy6zLkScCXgSuD4lIB+8DTmh5BpDnAzzQ8oD+1g8h4P
VST1A0sFRTQcI0R9nidU6HjoQHyRKDG8T3qM9cPrvy95GfS+lmNXdDlgx2f1eU3zOaWjA39aH+Xf
wa+PF6XD57Uc5hMh8JIph4qPphmrQYF1Zv1Ig0Gfp/yYNvl8dEwG3x9VdJV3lTcNDCyL56w7D81j
f95NuxJwJWC1TW0fjNlJYtvlABRjXuPglLZRbcfaThUPKEvmDe7g2Ns58yguKW7p86R3MPzTATHi
EstRXFI6ils6kHbQcoQGA+koPrJ+PJQf0tH7jBX/lA/NbwjJH8qN13jfjlu8VlwgTR4ej7V0khoc
SIc8Kf9abnE03GuuBI53CbD9s43od56DRGzDDFw2TYO2J7a5v9POFU8MLtnw4p/inx8vfLwoH4o7
dhxVnYs86n3FGeUnJMTCP62v1k/LCfHxquUoPiqumdjHC8vRoLjFAUPyVFgYwHzmsedlOkTkzDI4
e5e8UO6MKR8t2/6MluPGR0gCsicQeJQQzDu0vf8SsrmXS1ECsjKMLMcViigxIPZsHm/aGJfnKk/t
RvUbxTHGIeIdFTLyYnhfew91ZPmk3bt3mxn8NDYUDL/IeI+GyP5f2TIIH/n6dNSuXRspssQQB99z
v1uAiNEj2RFE1JRXkSnLucXf85CZ4U/a9ChIe/IhJLz5skzgk6UCb78GmU9NRK3e/QyukwaNDblX
D0W07J9I4yzLxJQZSBCjA/GPNLxibAi5cjBCM9IRLfsq5sieNpETXjU4RiwknuV+PB2RD9yBIvnG
xD7zMGSxPiSK0YHvh/dpbMiRfXmiZR8zGqTDR12K3Femoo4YHfbv328mvdHDonDEQISLl4QwiLwR
gxA+eRoaNmxoDCQ0NuT+uAgRN1wOiDE59pM5WLqsJ/rPnocPP/zQyI7Ghu1PPITab1l1jr77ZqSK
J0Wt8wZiwYevOYwNnbPTpJ7W/hfEfh7kV78DpfhzPiTSwb8j9hu078B7/P55veLJV+hBobQbfmMY
ylNbOSQBHaGHXYPDERK0W4wrAVcCrgQORQL2j59+4PXDqB3HYAWA9/WDyrK1s6b59Dnes6e1w6n0
WTbva2dbn7fzYX+e+XkoHaWvMZU7Br2vddNyqAAwBJdjL4P3tRzNp8+zY8q8Wo7S1+f1Hu/rNdIL
DkqffLIMjZlW2QQ/4567EnAl4JQA2xHbCw+2N2332v7s7Yxp+3XmZ+B1fY5pXg9u53pf26aWp3jC
cz6reKFtX2PlmnSZj4cG5lH8K6kcdiYZgsvhNT6vfDPNoHRKKsdk8v1RHikblQ9jBvvzes5rpM+6
2g/ypvyZh90/rgRcCRxUAmwvbH9sRwyM9RrbGc8Z8/g77VzzBeMS2yuDtnVz4vvDZ+x4oXkYKw7o
ffLGoDwyj57b6SgN3mOa9+z3mdZnGf9VOaYQ2x8tn5f4LA/SUZwkfQaNzYn8YT34rOIWz3loCM6v
1934CEhAlvgr9MhmubJ0kjeyoimwUNLmmtxzw9GVgLYNxh6ZrS3IhXjfJsS+5nZAezu6HP916Xbs
yZJ99GLFQyH0qiFidHgXNVq2Qb4sUWmMDbuSsEaW+41I3Y9Gb0xE9pWDEDl5OqpXl+WVvp2PSDE2
cOnLpIeeRaW3X0XC1EnIFAiqcPdDhgk1Nuzr2BWbLr4CLWUfnug7rkPm0xNRW4wOhbKcU87ISxAj
y8YlXXUjIMtW1nj4LvGqEKODeDpUlr0f8mQvmxDxbKA32NqxT6GiLL1XfcZUMTqMEqPDK/DIpDUa
GyLuvw05DZtgs+zdU1v26okTo0OmvKCKI65BkeBk7t2jjbFhf/8LsKdnXzR6eIwYHYaK0eEdVG7f
EQWylxA9G8JlX53dsvRwiOyzU/W/smSoGB08YmipVasWsn/4DhE3XmH2S9z4wJOoPONttBcDyIKz
LaMDK73gikvQ4//Zuxc4Sary4P9P36Z7dnb2BrssK7uwwgIBQQF1MYIGRFcTJQgGeUOAvNFETIyX
vB/8iwHFSAJvMIGof4Pv39xMyMdoEF+CGoyiZMWA4qIQhGWF5bouCyx7m51L3/7Pc6qfnuqenp1r
z/TlV1Bb1XU5depbXTXV9dQ550f/KV/fOyTv+cV2+eaag+QYDXT8cPMj8puXfUxGBvaJlWywYMOm
37hU23JYEe6D/Xs28dFrrSX875nlSmucCo1E27T49NbKcefkZvQveOfsE3uCAAIIdJSA/3G3H13+
h9F+vNl0++wPwvwHsf/g9GX9B55P9+Ucydf35f3HnW/X5/vQ1/fl/Ieo/4D29Xy5+u348vZgzzpf
3qf7durz6/nz7Xi6ng9Px+bbsr68pePzbJq93WDb8jfu4sv6cjb09SyfNm4lHGyfrISDffbtej4Y
IoDAqICfS3ae+Dnm1wT7PN51yeZZN5nz3Jbz5T1tOzetq7+exPNj8329ibbj1yNPr347ns54+2Pb
ss7T8eX9+uH59euWb8fya70tb72lb/P8+uXTLW3fNxtauja0fFra1naDDf26ZdNtvq9j69MhgEAk
4OeFn+d2zsXHPdBZv5z7TXSe+3wf+vnv2/Drw0TXJZ/vy/v6PvT0fej59euOr+fpeP59vi/v6/t1
ydP3oU/365+vZ/NtG7a+LWP3W/bZ3y715WyajbuDbd/GrUSWpeFVVzYKBHueGTZfwI5JqadX9h/2
GikND8iLB70sbDSpDUYns3369yX6O9P8nLCFRgJ+Ptk8G7dzJ35e2Wc7hjYtvmyjtFplml+jLD92
3SiuPkL2XfNZOeTy90ny3RfI4J/eIIlrPyY9Gmx4+A8+LC9qG4C2jrVhcdQXb5T9+gBefuf3pfeK
D0p+8VJtO+ZaKepwn7aPdZiWcFjyT38je3VZKwFmJRss2PDwuz8gZXV6QNvzOuFTV4Wgw94/+ZQk
v/QP0nf/Jnnqt98rO7WNQrtOjXzkallz7RVSvOhcGbnyzyTzxx8SGR6SLf+PtlF4+JGy/4ijgvny
r/yjDH7gd0XOeKPk/uQjIdjw6Ef/NLRRuOWDV8i66z8pCz/1J7JPr5PJh/9bFnzja9o+0NnyzG/9
brgP3qzbOebaPw5Bh8FrPyPJv7haep56XJ7RgMWuE04Oh2tQ2xlc89d/IUMaiCi9948kp6UVitrO
2WYNSAzrPr940aVa0GFEfuWu/wxBB9H2fDzYcO5TO0ObkG944gX5zuEHySv+7rNytzbSnbr1X0Ow
4ce/fokseOc7QrVQVvIsMta8qpMfo3b5ThlWWutJPmyp1YCgh16fhKcSOqIffF8CKP/MqgABh1nl
JDEEEECg+QJ+0+g/6OyzdX4j6Z/tj6f/AbWhr+fL2To+3Ze1efHl4vP9hsJvZD0dW96Ws88+9Hm+
Tjwd+/Fp0+PpWF5seny5eD48bU/fhtbZ9Phy8fn+Q9i2E+98O7ZsfNyX8fTss6XvD+psuvc2nQ4B
BCYnYOeLn6t2Ptp55w/u/HzzZey8jJ/HtgVfN76MjceX9XmWnnV+bttnTy+eTnxdG7cuPt/T9/Ut
Pd+GL2freDo+Xr8/8em+rK/v6dl09/AHfL4fvr4PPQ0f2nTr6rdr6dk087Y+Pj9ag38RQGAiATtH
rbNzyMb9vPNz14e2jM2z8yy+TP1552n4cvH5Ps/W93FL18bjy8Xn+7gt48v5OjbPtxOfb+M2z9e1
oa9Tvx1ff7zrn8+39T0935ZNs/m2rvfxbdv8+LI27s5+/bL1raebX4FwnJIaRNIGostJbcy2UhK5
J7dYq0bs1XZGovNjfnPJ1u04WVc9ryqf2/U88uuUH9mRI14q266+QQ79Yy0FoG/wW/uFW97/Udl9
3ImiDdOGxZ47/Q16zUiEkg6Jy94rwytWys+1ofrCsoMlactoaZyn/kCrNNLxpf/8t2GdnRps2PKe
PwpuOkMK2gjzgx/+hBx/3ce16qUPhGWevORS2fnGt2pLhtG1bp8GOJ7+6J/JYX/2UW0n4eLwgH+L
Bgf2a+kH/4X47Dt+K6xrQQe58z9k8Mhj5Ikr/7cUrfo53U5Jgx0//6OPyVEadOj/y6vDsi+85Rx5
5qLfC/mzCUOrDpNHdDtH63Z6tYSHVcX09B9dKXtf+Rqt3Sxq+2vXaWfokmUNOvylJD70uzJy0PKw
zvDBK0I6Vh52y8V/IEWtN+hX/utOkcc3y30LF8l12j7hYRpweEznP6dBmN9J9MuXMgk59V8ilyfO
v1hKWtKiU7rwN0p3pj+nv0PUP6N/W1J6juhfw07ZxZbcDwIOLXlYyBQCCCAwKuA3kP6jyz/b0P54
xjub5svZDzyfH/7I6jyb772tZ9Pjvc2zztOJz7Nxn+dp2HA2tmPpTpSOz7dtNsqLpXGg/Po6FkCw
tOzBnk2z8Xjn+2bTbNzeZKkf+rz4eowjgMBYAb8e2QMk6+xz/Dz1882Htkx8vn32eTa0Lj7fxn26
DX17fr3w5eNp+PLxdGw5m+7p1efTp/ty091Oo3Ti+bBx30YYqfzj1ysrsWDLTPa6Zfm0/Yr7x9Nl
HAEExgr4NcLf+Pfrgd0/xM9RW86XrT+PfboNJ3u98OuWrdPM7dgex/Nrn22b3tfPt2Vtni830f54
3j0db4vG9y8+35bx65Rv365XNu7TLRBhnechfOCfpgu4vw2Taf3u96+QkgYbStllYdvlnFaxpPfI
qUxUIsUDRk3PGBtoKGD+dm6l9XgU9QHy8HCheh6l2rBRXL8e+M7afdCIlnR4TB/aH6GlC5581/tl
4MSTJVP3O+7FM94sT2gQbOXXb5aff/QaKRx0cDVQYGnp1Uye0JIA4bqmDdk/riUkeip2Yb7dh+nD
+s2X/1koXfDcm94mz5/1a1pNVdRZPixvLx59nOQvu0rWfO4v5DGt8mn4pUdLytbVzubbcr849zfD
/Vq/VrH0mJZsCMGGKJkQYNViqPKYllY48lOfkEHdt20abPDO/v5YHkdeskaDJtfKkddcIc9o4GPv
yeutGHBYzK+lL772DN1OWVZp9UkW+BjRQIvlN+yj5iWh5/DmC7WkhWYvo+1hvKilOT5Wuc66sw2f
3bdHVl5/tWw/9XXy3IZfF7vy2vnv12DPWzsObf9ymaSccnhfyH4um5KM1q+U1Ol0zRMg4NA8W1JG
AAEEmiJgfzCtsxsA6/zBk39uNN+m1U+3dW2arW9Dv2mJp9Nofn06vrynUz9/MtuxZSZKx+f7zZOt
Y51Pt/GJ8uvrxtdxP1vfuvr8+w8om+7zoiX5FwEEpirg59FkrxeefvyctTR8/UbXLVvHl/fl/Nz1
6bZMPB37bJ3Pr8/nbG2nUTrxfPh8z6/lyab5D0/7bB3XrciBfxGYC4H664Fv068X9rnReezz/Xz2
z+Ndl3y+nfO+jqXt02drO/Xp2GfrZns7fp3y65c9gLPOr3Phg/7j27WhW9vQp/tyDOdHwI6D3QuH
oENCS82VK79DMlrFqE4P8yq/SeYnh2zVBex5t729XdCHz3sGC3oOJWSBvkkfv574sq08jOfXvn/x
a+bw4S+Vzdf/bWhU2UotxJe1fbLry84zNshuLe1gVSbZtzV+PQnXpVQ6KumgTvYdjnd+fSpquw8P
ffKvJKlBAXsT3jpLJ769gZedJA/f8Lda0qenup34fFtnx29cJM/9+jvDMh60sOl+fRQN3D2mVTFp
kfqQhs3zNGxo+bGgw+br/ybaTiwv8XT2vO4Nsmf9aWO2Y1XnmaHt5+YL3211fFqxvTH7YmkVtOTD
fZf/qeYlK5nKvoZ1Y+e3582Wb5fO85zS/ejtiQJzPWkr/Rsd13bZj3bMJwGHdjxq5BkBBLpSwP9Y
1g9nijHRWwsTzZ/s9mcrnYm2N9F2/AbP31z0G0tP133rP9sNl3X18305hgggML7AVM+fic7jieaP
n5PaOROlM9H82tTG/zRROhPN57o1vi1zEGiWQP11a6LzdKL5s5XP2drOROlMNH+y++PXL7/f8mH9
/ZR/rnef7HZYbnYE/Dj40Eqc2HfB63D3Nju8JIpXPWrLez87OSGVyQj4cbKhVQ+zd6gou/fn5faf
bNM665Pyzl8+XLI9o+3ZTSbN+Vwmvj92LbDfazbNSkpZ0NKuH+VKqVnLZ/z3nM3zZWyerefr+3XF
HsDbcn5dsmV8OVvHplfT0fb74vN93Jaz8yDkRQMF1tk5YvP9uun5CNuxYELddnx+GNbNt2W98+1Y
8MS6A+5PZRnPh+XP3CwPQ0NDYej7b/Os822ZTxjX5W3cStTavlhbOrZNb1vHl/P1QiIt/I/l1/bV
9sGPuWXXplvvnu2yPy1M3TBrBBwasjARAQQQQKBTBSa6oaifX/+5U13YLwQQaF2Bia5D9fPrP7fu
npEzBBDodIHxrkf10+s/d7pLO+yfHxMb2sNHe2BnAQbrbJo/fPTPYQb/zKtAUd/az2uVSvs08JBO
6YP1yoPlec3UNDbu3z1/YOwP8m1oD5Btvn8vbWjTfLoNvWv0QNnm24N+6yw9T8c+ezo2bp1vJ56O
L2NDf4jtAThb3tez+faA37r4dmwZ3y8bt+XG246tG99OPB82z9f37fg5aUOfb3m0/fW8WnrW+/z4
0Naz3vJr27KhT7NttWtn+2C7XKh8NTKhpFb77k+7HAcCDu1ypMgnAgggUCfQzn/063ZlTj/iNqfc
bAyBGgHOvxqOSX/AbdJULIjArAtw/s2MFL+Z+c3X2vaAzjp7kGqdPXi0zh9a+nyf7p/DQvwzZwL+
4NgfIheKBbHeO3vQbL0fn1Y/Hz1//r2y/bJxm27fPf8+1i8X318bdxd7aG6d778/mI8HHGx+fHv2
2Uvy+Ho+3+ZZ5+v7+eD58uV9vg99uufH1/P8RKmOltjw/fP5vj+eDx96+j709eLzbd3h4eHgZ/tl
27ZpnqatY+M29MCJl2jI5XLBxgMdvh+e31YduoMNrbd8F7TZxl/sthIuIoev0LZnrA2H0Oh9q+5F
++eLgEP7H0P2AAEEEEAAAQQQQAABBBBAAAEEEGiKgD/A8weO/rkpGyPRaQvEHyT7A2VLzB8oTzvh
eVrRHxb7984eiPu+2DzvfR9tOTfwdX0Zmx5f39axB/M+34bxdSezHXt4b+vF07F0PS3Pjw3j2/Hp
vpyvE1/Otx/Pk6dhy/k6Nj+eni9j8y1flkcPMtg0T8+G3vk6lo715mRDCzTY0Of78u02tPxbaR+r
ciy0c1LU70JKj7f+p9+idtudtskvAYe2OVRkFAEEEEAAAQQQQAABBBBAAAEEEJgbAXvYaJ09sIt3
9Z/j8xifewF7w71QsNIMVn2O9qWiHjN9q1ur9CkUoofI8YfGrX78/HvnJQLssz0g9wfnvi8+NPH4
g3Qb9320oa8fX8bW8fV96Ol7ej7dhz49no7Ns86Gnu+ppuPrz/Z2PB/eloN9TyzvNj3exbdr41Z1
mg09kGJDz2N8vVYft33wfI9owZ8fbHlBz42SrFy8QMp9WqJDSznojrb6brRt/gg4tO2hI+MIIIAA
AggggAACCCCAAAIIIIAAAt0s4A/A7e1te5icTNrDb32rWx8w1z9cbkcnfyBu++njth/+gN/Gbbrt
qw1tOet8vq9TP9+mx5fz5X25+vm2rE3z+Y22E0/Pl5soHVvHOt++jc/Gdiw9N4unbfmKd/H82bj3
8XXiy7fbuBlYEG5oxIJxOl7WwIvY43CCDc08lgQcmqlL2ggggAACCCCAAAIIIIAAAggggEAbC/gD
yTbehY7Muj/w9p1LlkuizSpLbyYlKQ04WGfL2APmdnx47Hn275+/ae/7Wz+c6fz69Mb7PNF2xluv
fvpE6Uw0vz698T57gMFLjPhy/v1xX5/u262f7vPbZWj77d9/G48+a+PRViKoEoyzKpV8f9tlv9ol
nwQc2uVIkU8EEEAAAQQQQAABBBBAAAEEEEBgrgWK+WiL+kA7dMnKoyRtdJVufgX8obHlwmIMVjf9
wmwUcAi11Ffe9p/fXLL1+RSYKHAw0fz5zPtsbNvOET9PfGjpRuOUcpgN40ZpEHBopMI0BBBAAAEE
EEAAAQQQQAABBBBAoIsFwoM6DTYk9mwXKY5IaXi/Vreijcj2H6Qt0vaI5BbrU+6o4d0uZmqJXbdg
Q182Kbl0Rs48tj9Ui9OXTYdhS2RwBpno9AfiM6CZ1Krd5udBBS/hkM/nxfpwPdPgQ9S2iTWonZGS
njf1JWkmhcpCEwoQcJiQiAUQQAABBBBAAAEEEEAAAQQQQACB7hNIaKmG0sALIvlBSQzukbIGHJJp
fZSU6ZVSVh9sayU+dPMn4A+TbZhJ6bHRKpX6c5lKPfxRvnyZ+cslW0Zg/gQ80GClfyww55/nL0fd
sWUCDt1xnNlLBBBAAAEEEEAAAQQQQAABBBBAYEIBf0PY3gSWgd2S+umtInt+IcltD0o5lZHiy88R
WXSolI49SxK5/mod6DzYnpB2VheIe9u41UVvQ39j2z7buE2LLzurmSAxBFpYwK9laQ02vGRJVoMN
IlrwR1IJHYlVtdTCu9C2WSPg0LaHjowjgAACCCCAAAIIIIAAAggggAACzREIbwKXCpLSkg0ysEvK
A8+JpPWh3dA+rU5pvz6v0zYd7Ake3bwKeDChGljQAIN1Fmzw4MO8ZpCNIzCPAnYdszOiP6fVKOl4
Rs+LlJ4j2rLDPOaq8zdNwKHzjzF7iAACCCCAAAIIIIAAAggggAACCExKwOs+DyUcrJRDflgShRHR
VhvCI7qiTitbnejFoiS05y36SbE2bSEryWAPVdOZrBSLJRkeLlRLOqS0miWbb50HJpqWERJGoAUF
7HufyyTllMP7Qu5y2qh6Jq3BuEpgrgWz3BFZIuDQEYeRnUAAAQQQQAABBBBAAAEEEEAAAQRmTyAE
HvQBtj04sjeErTBDKPVg49rb/KRNpJt3ATsM9vZ2oVSWPYMFDQIlZEE2S5Bh3o8MGZhPAQ+ypbRU
Q29PFJjrSVtVY1EpoPnMW6dvm4BDpx9h9g8BBBBAAAEEEEAAAQQQQAABBBCYQMCCCdZZIMF6K+FQ
LuQlpSUcklrCIV2pgiRfKOr0opS0lEMynZe0NiJtD/aovmcC4Fme7Q9TbWjVw+wdKsru/Xm5/Sfb
JK0lG975y4dLtidqw2GWN01yCLS8gF2PQskfvT7Z9cw7m269X7f8PPL5DGdHgIDD7DiSCgIIzLOA
3xxbNmycPxrzfEDYfFsK1J9HbbkTZBoBBBBAAAEEEEBgVgTs3jDEIOyfMKJvBYfRcvQAL4pP8Ptr
VrRnnkhRSzfktUTKPg08pFN6jMIxm3m6pIBAOwtEgQcRrQAu7EaibENKODT7mBJwaLYw6SOAQNMF
4g9JfWONpvk8hgggMFag0TnTaNrYNZkyHQGzre8tHcyno8k63Srg50ujc6lbTeZiv+Petj0/DnOx
bbaBQLsL+PkSP498Wivtm+cvlHCwthq0ceh4A9FFvY+xh9lRywCtlPPuyot/d6rHq1iQgvbeFbV9
Devtgat1vJTnMgw7WcC/5za03r7/BS3g8MyLI3odEznikIWSsjYckimd38kS87tvBBzm15+tI4DA
DATsb4O9xWF1VKa0Dr6RckYbxLJGsUrhD4v/oZnBJlh1FgUK+rZNvLNivnStI+A/VPyHyX4tjr1n
MPqRYnVe0s1cwK5J9iKg/Ujfny9JShv0e3EgLz2ZkmRGoh+B/oNw5lsjBQQ6XyB+3bKi8oODI+G6
ZW93Wsn5hN4b8ENyht8Du2jpDZcNhvW6lUgUtLqOoowURXry0Y/4ZFLfGQR6htCs3i0Cft2yoV23
hofzsl/vBwb1pBoplLX6Gyup3RoalkfvynZRjX/WWfbR98eXYzi/AvHjUXP89GBxnZ7fY8PW50/A
vvsWILUqx0I7J8WyZFJRNWR6pzh/GevwLRNw6PADzO4h0KkC9mdBA9KyT2/Ov3bf8yHg4M9EEwke
jrbScQ83vpqh/EhB/8BHObM2mjI9WterfuTmt5WOlv1wjAJD9ruyoDdjwzpclNX6L/XgxX+4tFau
2yc3ab3Z3acPFr730K6Q6XTmeUnqTTDXrfY5huS0FQWiPy5FvWbZiwg79+WlL6sNA+rnhM5qlYd3
rSg3UZ7MLq1/tO0H+gPPDGhVHTbcx3VrIjjmIzBJAbvvsuvW3qGC9KQT8orDFktKf8u03HWrpFFG
67WzK67dv/tDvIReH+jmV8BeGCpomxpFDbiHXo+V3VtaCZVCIaqv3o+Z5ZTfX/N7vNj63Aj499yG
+ihC7n70Rb3eluTQJX1S7ktIRks56MkwN5npwq0QcOjCg84uI9AJAvZ3YVFOHyboHwxrIMtu1P3m
t6TFSP2PSyfsa7vvg/0GsQcVI/nagINFG+w4JS36QNcSAhZQsONhQws42A3Ywp6E9GvAgeM080Nk
162+nlQI5OweyquxVUcQNWZmDxy4bs3cmBS6T6D+umV/cxZoA5nW9+gPSfsxSbB0+t8Luy7l9CGo
9dmMvdChD7Ts3kunc92avitrImACdm2yewO7T7bTK6vXq1xGzzU931rlniDcE1ZeRgl5Dr+4oqBD
+O3FoWwJATtO0bGKSs7Yfbv1JQ1ExBvLbYnMkgkE5ljAzo2iBuEGh+0eRsfL2ui92ONwnkM081AQ
cGimLmkjgMCsCtiNt9989+mDhLcev1jyWhmfPqbT6fpQIZMJ81MpahOdVfhpJuY3vvaWzaC+UvCw
vhE5nI/ejMpm0nLsSxZITks5pFNa0kH/1vuxnebmWG2WBOwNKTt2IyNWx2VJ9B278MCuTwMP1sXP
w1n1zMlDAABAAElEQVTaZEcnE/fq1acJpx3dH65bw/oWmt3kZtLRdSud5paso78I7FxTBfy6Feoa
1+tXSX9IprWo/MpFaa2yLBFKQTY1Ax2ceEZvqY5bmdOXBjJy1MGZEIzu6ekJfwusCji7xlEVXAd/
Adi1pgnYQ+DwEKxy32XXLyutfVBfVq9bKS1Z1LRNTyphv4/3hS07NVmyoubW082rgB2neJfUe3d9
JU969TtkVQ5bZ8vY941rdVyK8W4Q8OusDb23U6ZgJYIqwTh9kqRVcnMta8b3gV+3zVAlTQQQaLqA
vbFhJRyKxYQUrdix/pfWO3P74ZtO8wej6QdgEhuIfqiIPqTIa9Fw/UOu97z6nmlYM6lhooV6/Hr1
be+MtuVgx9OOHd38CxS0/mA7dnm98dLyDvruh92EUcJhpkfGvt/WFsZCLS1S1LuvkUL0fffrVsae
6tEhgMC0BPy6VSymwpvCdlcQ2nTSp2P2vMUfjE8r8S5fyap8s7ettVlFKfWm9Qe7vomtwdNwTdO/
EzbkIVaXf0nY/WkJlEpRidL49cvuh3N6ftm9gZ17rdJZTqwsuf0XcqV5szt661spn63iNdf5iAcd
7G+e1U2/UKsVtICDHan4/LnOG9tDoBUEoucS0XOI+PkQjbfOtbYVrGYzDwQcZlOTtBBAoKkC9qPW
ei/J0KOtrJb0GZ292Whdyipq1i5RzIch/8yPgP8Rt+qu7MFEWd/kLmvJhvzIoBQqJRz0FliKw2kt
zqhvcGlph7LdEFca4bBjTDd/Ano07MV7PR5a0aV29ua9HZoeLUFk434ezl8O22vL5uUPO+1BQkb7
pBIn09GbjfoIL/rFXoiuW3z/2+v4ktvWEPDrVjKh9wN6/UrqiwjRdStd89Ya168DHy+//vjQ3/jL
6N9pu35ZyZHoZdroepXUKuHCn4wyf7cPLMtcBMYKJKOTSe+r9D7A7rv0IbHdAqctwKfjdv5Z3yrX
rbJWR2L9aGfnffTbzK8Zo/MYmw8BvUxr+0VaLZeWnj3z2P7w3VmgL3dZ5w9c/Xea52+iY1e/POtF
Arj4N6F22Counisv4ZDXFyCtt/xZH7Vtoi+plLTkpp43/uLEROeDp8twcgIEHCbnxFIIINAiAv5H
wIb2trD98k3ozbh3Nt2X8WkM51YgCvvoNu1XU/R/aGtDR6tdGLdjp1PszSjvbQGOX5VpXkbs+NmN
WLpyXtmxsXPNj4sP5yVzbbxRu5ENrloCy04N0ZIk1tk0M3VXH4aZ/IMAApMSqL9u2Ur2gNzOO/8R
adM4v0xh8p15mZ8P7W+BXbO8c08f+nSGCCAwsYCfSfEXbvxciw8nTmlulrBbl3D/rkPLu+XRet+P
uckFW2kkYMfBOhuGkuN6VPpzGb1e6+2mvvxlL3wNapVdifB30RqTHr3vzGkJW7vXz2p1xTa0ztbL
a5W41rbI/iENNDU4yqyHSyt/X6w9nOg3bPS8Idy76PfaqxnTL3d4PhG+8PzTNAECDk2jJWEEEJgt
Ab+Jsrd87I+FlXDwt+7ss0erfTmb5uOzlQfSmbxA+IOui1vJEyvhUNAbVjteSe0Txehnif24smnW
21vzoeoLHbeOYxcY5uUfP3f8GNqxiEo4aOOrWme3PXiyY2bTOU4HPkTuY2bm6dctG7c+aiNj9Fpl
03ydA6fMXAQQiAv4uWND6+w8Cn9z9Nzz65aXjIyvx/j4Ah6ksb/j5pnNZvXveVT/tw29c3v/zBAB
BKYmED+H7Fyzc8+vW36/ZcP57CyP4fpqDUfXNB5twQYPQcxnDrt72/F7R//7Z0Prh7WtwyefH5I9
gwX58ZN7ZWgkXkJFSy/rQ9ljX7JYlvT1yPojl8mCbPR40Nbbsm2P7BoYkR/8/AVtaDcq9ezSrIdL
u3xfTl7TH6qpi661Za2SWyt21mualSSzF1OsvcIypTT91J71IQGHWSclQQQQaLaA3YzbTVT8QZ79
EYn/CG52Hkh/fIHwo0Rn2zA0OqzHy49VfC2/GbZ53tt8m043/wJ+fOI/eDk20zsu7mZD87RrlT0A
5bo1PU/WQmA8AT/XvPq3+N+W8dZh+vgC7ul/B6K/66P3W/73fvwUmIMAAhMJ1J9nft2y6T5vojSa
Pd/Odbs7tz6c9xrfreYvivU2OwukP4GAf1fs+2OdHScb1UHovZFcT8aW13fCtC+F3qf70F4as97n
+/We9XCx70R914rfF/vOe2e/vez61a9tSNo5oc0T6jXMrms8d3CjZgwJODRDlTQRQKApAn5j62/6
2Ge/+fFhUzZMolMS8GNhdSMW9U42kdQHrIm8FvHdr6UdoqQyqbTkcjnp1eK+fQt6QwkHe0BknR1X
utYQ8GNhQz/v/IdMa+Sw9XPhhhZgsM787BzxvvX3gBwi0H4Cdt5Zb+db/Prl52P77dHc5tid/O+y
X7fszWuuXXN7LNha9wjYeRfv/b7Lz8f5lAh35tZWXnhApznRvBa1L2mf0p5u/gXs++K/wWxoNQAk
tNGwlx6S1t9fZTnsoN4QQPDvky1jJcz7sxnJaEkH/b/aLmJC5605uFcOXZKVQxZnwu8530PWw6Vd
vi9pbQvHSuPYd9a+99aeyWnrFoev8iJtVD2tJRy4fPmZ3ZwhAYfmuJIqAgg0UcBvlPzBZ4hY89ei
ieJTS9r+qFsXPaCIhv7Qx4+dDW1afW/r+TI2Tjf/AnaMrOO4zM6xMEfruW7NjiepINBIwK9Xfv1q
tAzTJi9Qf93yv/OTT4ElEUBgIoGWv27Z/X3lHt/u9PVuJvwX3fVPtHfMnwsB/w7ZtqK/f1qlZ1qr
ttVb+SULakvWhmU1VtSnD2Et8BBVLRMF6S2ElLEqZ/R+dXFvOjywtSr2rGM9XNrl++JVJvn31j73
aaDBurQGImw/6JorQMChub6kjgACsyjgN1H+xk/9gwR+AM8i9gyS8uNgxyuZLEk6X9A/6Fr3s/5R
t946G6a0lEM6rW/VhDY59M0aSjjMQH32V/XzzVOu/+zTGR5YwN3qh76Wny/+mSECCExfwM8zT6H+
s09nODkBv89yR7//8rW5frkEQwSmL+DnV30K402vX26uPie0rnPrvQsNxuq9Pt38Cvj3xK/X9nvK
rs023V5uKQ5roECPW6o8EqZLKQoc2HLRutY+gz6ELdeWwC1rSfWyBhnSktc677We+1LUjgPr4dI+
3xcNoOk32L7n1ts5kuuJSpzb/Yx9tqHPn98zuTO3TsChM48re4VAVwpEN01duestudP+x9uH9Zn0
6fGhLWOf6RDoFgG+791ypNlPBDpPgOtX5x1T9giBhgJ2a+4lHCq36VaygdINDbXmfaJfm21ob3Vb
eRQLEFljualKyWU7nmG+Tg9L1P3+so9h3cpxZ73osOLSXt8XD8TZ0AJx/qKEffZ5837CdnAGCDh0
8MFl1xDodAG/mer0/WzX/bPj06i3/Wk03Y+nD9t1v8k3AgcS4Pt9IB3mIYBAKwpw3WrFo0KeEJgb
gfCALjyoi2IOlXiDvhCvbQZob9cHrhFzcywOtBU/Bv4Q1R+wWklyr8bTjqW1sWedzbd1bOjr+HRb
zkoy2HrWsV7khUv7fV/8+hQ/H8KXWv+xefY9t87Pn/CBf2ZNgIDDrFGSEAIIIIAAAggggAACCCCA
AAIIINA5AvagVZ/Nhd7GQ+cTOmc3O2pP/AGqDT24YDvoD1ht3ObFq5TxdXwe642+PGcm1uE5GmRs
t++L5devX/G8R0eWf5shQMChGaqkiQACCCCAAAIIIIAAAggggAACCHSCgLXf4G04WLChVOltnK5l
BPxBarzNHXvI6m94xx+42rLex5e3nbFGolkvCsjEDy4u0XemXb8v8e+/HVc/X+LHmPHZEyDgMHuW
pIQAAggggAACCCCAAAIIIIAAAgh0toAFGgg2tPwx9oBCvFoly7Q/aLVARKOO9XCx70D9A/pO+L40
+r4zrTkCBBya40qqCCCAAAIIIIAAAggggAACCCCAQNsLJLR0g/Xele1hJAEH52i5oQcU/E10H46X
UV/e5/tn1qstwYNL9A1xh3b7vnh+Gc6NQOOw3dxsm60ggAACCCCAAAIIIIAAAggggAACCLSygLXd
4O03WDMOGmxI2Nvx1SYdah/MtvKukDcEEEAAgeYLUMKh+cZsAQEEEEAAAQQQQAABBBBAAAEEEGg7
AQsllCv/VcMKiaROqX4K+1T/1nPb7WgHZni6x4T1Gn8ZcGlvl8a5Z2qzBCjh0CxZ0kUAAQQQQAAB
BBBAAAEEEEAAAQTaWMDqcbfQQgg8WCkHq0rJBjalUq3SdB/EtjELWUcAAQQQOIAAAYcD4DALAQQQ
QAABBBBAAAEEEEAAAQQQ6EYBCzZYn9T2G6yvdsmUiPV0CCCAAAIINBAg4NAAhUkIIIAAAggggAAC
CCCAAAIIIIBAtwlYgMG7MG4FGXSC9dE/PpchAggggAACjQUIODR2YSoCCCCAAAIIIIAAAggggAAC
CCDQVQLx6pFs3AINpVIx9CHooJ8TqVTouwqGnUUAAQQQmLQAAYdJU7EgAggggAACCCCAAAIIIIAA
Aggg0LkCY0o4hF21Ug9RyQcLQvineHCic0XYMwQQQACBqQoQcJiqGMsjgAACCCCAAAIIIIAAAggg
gAACXSJgD4784VEIO5S1rIP1VgKi0nB0l1CwmwgggAACkxBIT2IZFkEAAQQQQAABBBBAAAEEEEAA
AQQQ6HCBeAAhlGZIJKWYXSTl/KAkkhkp9eh4OiuS6ulwCXYPAQQQQGC6AgQcpivHeggggAACCCCA
AAIIIIAAAggggEAHCcSrVLKAQ0mDDTuOOVfKI/tFigWRdI8klh8jqdxC6UllKOHQQceeXUEAAQRm
S4CAw2xJkg4CCCCAAAIIIIAAAggggAACCCDQxgLxEg7JpJZuSKak1LdcSzYMSVkDDgkNMqQyuRB4
0DqV2nhPyToCCCCAQLMECDg0S5Z0EUAAAQQQQAABBBBAAAEEEEAAgTYTsECDdel0WsrZXhk5aI2U
ikUp5PNi87J9S8K8TE+PpFKpUMohHqhos90luwgggAACsyxAwGGWQUkOAQQQQAABBBBAAAEEEEAA
AQQQaHcBCy6EgIK22ZBMliSlbTjYtKQGIhIaaLBxAg3tfpTJPwIIIDD7AgQcZt+UFBFAAAEEEEAA
AQQQQAABBBBAAIG2EvDggQUZQkmGbFYymSjIYG07lEqlEGDwaV66wZalQwABBBBAwAUIOLgEQwQQ
QAABBBBAAAEEEEAAAQQQQACBIOAlGCywYAEHG1rnAQkLUHiQIszgHwQQQAABBFSAgANfAwQQQAAB
BBBAAAEEEEAAAQQQQACBIOCBBGvDwbr6oEI88NBofliJfxBAAAEEulaAgEPXHnp2HAEEEEAAAQQQ
QAABBBBAAAEEEGgs4IGG+iqTfHrjtZiKAAIIINDtAgQcuv0bwP4jgAACCCCAAAIIIIAAAk0QKD53
v/zz9XfJPlkhb/3YebI6N/FGint3ypPPvCCSOUjWHLlMogpcJl6vXZfY88RWeXr7oGRWHibrDl/U
rrvR+fkubJNbP/Z/ZasslTdedoEct7Szd9kDCvVD32uf7p8ZIoAAAgggEBcg4BDXYBwBBBBAAAEE
EEAAAQQQQGBWBH564xdk4w1DmtYaefPHJpfk5r+7Vm74yC5deIm879k/lxP7J7deey41IN/49Wvk
jkc090efKZ/6yQXSziGHbffcJT99dI8sOPJlctr61Z0VLCoMyL033Cfb9VA92vtS+fSVr27Prxy5
RgABBBBAYA4EknOwDTaBAAIIIIAAAggggAACCCDQTQJ775evXWPBBpGV158raydRusGWzWT9kXuu
KxocXLDW9lq7tZn2fkA/9DO58Yx/kFvefYvcpMPHokMf7Vsn/JtbJ+d8YknYk6FrbpOf7e2EnZr8
PliJhng/+TVZEgEEEECgGwUIOHTjUWefEUAAAQQQQAABBBBAAIEmCjz1b7eHt8FFcvKGtx3TxC2N
n/Two3fKx17xYfnwKz4mdz46PP6CrTBndytkYmZ5aO8Yw7Dc9cmr5f1nvl8+9tE7pdG35eXnnlEB
2i7/8b1tM8Nqp7XLZZHiiJQLqpLXvqDjpZKITadDAAEEEECggQBVKjVAYRICCCCAAAIIIIAAAggg
gMB0BQbkh1/ZEq186i/LCavmpyWGwu7nZfsjVj2TyC922yPkbBjnnyYI5I6R9952vmzaslsWrztZ
XjrJEi1NyMk0kyzI9k1PytDdooGy50PAof7bkjryFFl/9C1yj1aB9eCX75WBt50tfdPcWrusVi5r
YEEDDeVn9Xy2gENKz+VUj8iyNVJOq1AyI1r0IZR+aJd9Ip8IIIAAAs0XoIRD843ZAgIIIIAAAggg
gAACCCDQPQLPPSj33B7t7spzTpRl87TnuQX6MLTSZTL1j499DsPZEUjJ2jPPkvPec56cdebaNqwe
KifVb8vizDihqRVy0nlRtUpy873yaDdUqxRKNxRE9myX8q5nJGG9jpfyQ1Iu5mfnq0MqCCCAAAId
J0AJh447pOwQAggggAACCCCAAAIIIDB/Ajsf3ixRuQKRV77p8IYZ2bHpTrn5/3xHHvridrGqeJZs
WCdvuvJCObx//MDA8HNbZeNXvy/3/fsD8tTWIRl6ZEhyp66U1We8XM659BxZtzwqSVHctkn+z3Ub
Zd9PH6xu+/YPfFp2nLpQRgb3ySEbLpAL3ry6Mm9Ytm7cKHd89T7Z/NOn9A13TffonCw5YbWsv/Ac
OefN6ybx8HxYfnjdjXLbD16Q4/7wfXLB6wry7eu/It+66VHZZXk8eokc+Ttvkv/xe2fJikm/+T+1
fA0/cZd8+oO3y95DjpNLb7xAinfcKl/6zPdly+12JHKy8uJXyTmXnSsnH9nonfxh2fLvt8s3btKH
6DdHxyN39Eo58sLXyNnvfpOsXTqZEipq8Okb5Vs/2ivZE98k77/s1ZWH9tH0275bsfnlYbn1ui/J
92/eojaaMz1+L3/3OXLBb55cV1pgeqaRw3dleGG/nHH1pfLaw2u/T9vu+JL87Wd+LnLIUXLJZy+Q
1emibPr838vGh3fKg5Ugmdx+m3z6o8+Ifltk3+AhcsE1ulzluB31ppNFrrlDTbfL7d96Sk48z79H
1a9aR4yUtMqksgYbSgU9OzXAkL7z/9VAwy+0GiXdvf4VUtrwx5JYvEqSS7W0QzJNCYeOOOrsBAII
IDB7AgQcZs+SlBBAAAEEEEAAAQQQQACBrhfYfl+lOiVZKUe9ZOwD7q03/5Vcc9FoMMDAdt2+Rb58
+1Xj2u3c+CX5yAZ70FvbDd29XbZof90198i7n/hzefVykaHtD8p9n69NX+7eIvdpdTnWPbrqxUrA
YYd86cwr5I7K9Giu/qtBgl2PbJHbb75O7vnEpfLnl+lD5gN2BXnqmw/Kdk1n++2fkp8dvUurchpd
YUirdXrwI1+WK/72Cbny3nfpQ+7ReY3Hpp6vwgvqcPt2TW67XPXID0Q0cDLaDcn2L26UG7/4Izn/
gevkrCPjD+F3yq0XfURuu3l0aRsbemS7PPjxW7T/rlz4wCfl9TXr1C4bfVKDrz0oT5rlM4/JcDXg
EE2PbK6WTRpe8mCUrWfH7567b5R7fnShfOb618dKFkzPNHJ4MmTpqQ9pFUB1AYdd//0zeTI4jciL
14ms7h+QR/76Hnkwdrxs5S033BfS0G+LvPgnowGHRS8/UdbIHWJb2PtMhxdxsICDtdVQLIrse14S
2ltXTmpFGVq6oVwqhKBEIkzlHwQQQAABBEYFqFJp1IIxBBBAAAEEEEAAAQQQQACBGQkMyEPftQff
2p16nKzsj0b93+K2O2uCDWsuf6u8+7YLZf15OV+k4XD73Zsq05fI+uvPl/fdc7lc9t1L5KQNvvgu
+afrfxg+5FafIm+9doOcfvFomrmL18tbP7dBNlx7ppz9upXRSnu3yw/sAbl2S85bL+ff9j65fNNl
csnnToom6r+7Pv73ctc2feA6QZdZ7At4sGGJnP6FC+WSL5wulUp4NJBxj3zmcz/zBccfTidf1fqA
NNlKsGHlBzfIJV89X44/1Tc1JF++amNNg8j3X3ftaLDh1JPkku9fKVc/dJm8/fKKkYYHbjrvy7LT
kzjAcNQgU1MqZHS6BxvWyIZ/uUTOv/b40dQ+f5PcUdew9+h6UzCNO4ymXh3LZPWN/EoXxX365JRP
vlU2XL9+9DhpiZD119u0DXLm9WfLyl5fo3a4/Uc/l4HaSW3/yUo1WF/UIEOhUJDi8FDobVq8GykU
xXpbxnpfL74M4wgggAAC3Ssw4bsV3UvDniOAAAIIIIAAAggggAACCExVoPrMt0Fd+A/+63eqya25
/oNyxXuOC59ffeZp8qrT/lI++yEvHVFdLIwceeFvy/nHFuTVbzlRFlV/xa6VdV9ZJdctukZsraG7
H5M98mpZtPw4Ofv9x0nx4Yxs/OJtYf3Xf/C35Oxj42/26+T+Y+TSr14oQ+tO0qqGFoXl7J+1x66T
NT3XySffHVKVp57Sx8qrRudXFxxv5NTT5cpvXFSthueVJx8sf3jyLWHpXR+5U7b9/nGyqroPDRKZ
hXydfttVctGZq0Lirz3ryKqR3Pyf8ujnzpLjLBD04v3yrx+vlDc4er1cdce7JFpD5C1X/okcIh+W
G6/R+Y9slO8/fP5YvwZZn3DShjPlqq9cUNn/18qRB18n1wRnkf/6+qPyFj1uDbuZmjZM1CamZJ02
/rxOirLg3++RW6xapQ1nyW+95+xYaYvYyrnD5UQNcj1pyz2T17U6uyuVdA+tj3Uh+GDxB+2tBEQy
WRuMiC3KKAIIIIBAlwpQwqFLDzy7jQACCCCAAAIIIIAAAgjMusDQNrnf68LfrTWv1GxgQB730g/6
iPed74o/XE7Jie/5I7nkg9XyADVrZlcdJ2e9LR5sqMxOr5GXnVcZ1wBHvLWBoXy+mkZ+v1avM6bL
ynFvfn1NsMEXWb3+ZT4qo60Jj04af+x4uTwWbLDlsseeKedf7Gtsle0T1sQzs3wd/49XVoMNYavp
tfJr13qJBRFtAjh0A1t/phUwRd3pn9cgQGXcBye/7x36rn/UPfO4HswZdyfJldVgQ5TY2rdt0Iq3
Jupmw3SibQxJ9duyO181OuBaWqol/n074LJtNtMCCSUt5TA0OBh6LcJQswdDI8MyqKUfvPM2H/wz
QwQQQACB7hY40HsV3S3D3iOAAAIIIIAAAggggAACCExRIK9N7Va6oxfXviVe2CFbPRhx6ksbvOWf
khWHW0mCylv3nk5sOLDtKdl8/2Z5+onnZfeevMYC9skd3v7AdJ+JFwbkKU1z88NPy/PP7JZ8VlP9
7tj2ImLZGH90w9oGDUNn5chT14h80Wr+3yWPPLJHTl4/iRIT08zXYUcvG5O/sVUJiWzTKoG823jG
J2Tne5Zro9o+xYajQZqt2qaDvHlFfObUxzeskGX1TyAyaRmt5GicJGfTdJxNTGvy1l2hSqWxrZRM
K7WWWcmrT9LKlbSdhpIkrJql0Fp0JYtWssGmWV+Khi2TeTKCAAIIINASAvV/7lsiU2QCAQQQQAAB
BBBAAAEEEECgDQWqr4lr3p/dH94Ur1ZkpG9Lv+C7pMGIqf0Y1caNP6TtDXx+/GCEJz2V4c57bpVr
z7jtACGOqaSmy+rb8Y26535qwQbrcnLoyokfUc8kX/l8bbmSaLsT/asNWx/ANpcdpyGDiZKNz59u
QGiWTONZmZ3xCUMls7OZeUylXNDwofX1nZV40D40Km0NS9MhgAACCCAQE5jaPV5sRUYRQAABBBBA
AAEEEEAAAQQQqBHI9Io1DxCq6hnnQXFY/tndtcGImkTqPxTlhx+9SoMNXoXLSjn9+tfIS9cdIv0Z
DURs+LL44/z6NQ/4edtdcpUGG6qpvud0ed2ZL5VlK/pl73/+q9z0ca9w6ICp1M6sNh5dO3npsVrC
IeRySH7xgrYJEUpy1C5T/dSMfFUTHx3JD48+SD7+C5fK2Sf0N6xKKJ9Py2Enrh1dca7HZsO0GXle
u0AmDh01Y8PNT9NKL4RgQiWw4KUebMvxypXi483PFVtAAAEEEGgXAQIO7XKkyCcCCCCAAAIIIIAA
Aggg0OoCuRVyjDaqu8WqTqp/UNy/UtadqsGIu3Xe1v0Nq6MZ3DP6ELy6q0OPybduqIQFTl0vV37r
XbK6+ku2KM+cpwEHr1apulL9yNja9rd+67vVYMP6r14p73rz6upKxYMf14BD1OB0deJkRjTIMrZ8
QVG2PbyjsvZKOW7dgatTakq+GuT94KMP1alRUOWQY4+RtSe06OPzaZuOPebxIEsDkmhS/fe2ZsFh
2e0lNRrmq2bhtvsQqknSIEMIMOiwWLYqlbSv25OiTimPmVq3EB8RQAABBLpWgEaju/bQs+MIIIAA
AggggAACCCCAQBMEFlbSvP1p2eEtFIdJfXLo0ZV5j2yUjZv0Tf9Yt2Pjl+SzjUoVaOPPHoZYcsar
YsEGXbmwTR5/IJbIOKP5gbFhgEL1Df8lctL60WCDJbHtZ8+Mk9IEk+++Qz79+ftrF9p2t3y9Wjrj
UFk6Qe1ETclXbY7Cp8XrjqhOveP674QAUHVCK41MxTTWUPim72yu2Yud99wsN3xk/FIr1cqwNBg2
9ttSSWpou2yxgJl2uZev7tgSDtEe6r+VEg7Vzz6S0BCE9XQIIIAAAgg0ECDg0ACFSQgggAACCCCA
AAIIIIAAAtMR6JNfOm1lZcUXZO/eeBpZOfGck6oTbj/tf8u3N22TPc9tk7s+f51cseGO6ryakUym
2rDwrmv+Ve58YGeYvefRH8pfvfKTct8jNUtXP6QzC6rjGz/+Fdmybads3Xin3HlPVNognfU6+HfJ
1z57p+y04MjQHtn0938ln3znfdV1pzSiAZUnP/RZ+fBHb5Wt2/bIjod/KNf96j9U24hYee3rawMm
DRJvSr4abCd75GvlTC1xErqbb5NPfOhWNdojw4WiDO/dI09t+qHc/NGr5fde8VeypVLApEEyzZ80
BdO+tceJf/t2ffxG+ZubfyY7X9yhx/Sv5SNnWLGb8bq0LPBAmQbDbrp5i+zctlXuvPmu2qDZ4FC1
VMyKV62SsWUoxku/PacntXSD9WO6sgYbrKdDAAEEEECggUC1IGqDeUxCAAEEEEAAAQQQQAABBBBA
YEoCh7xinS5vb5Jvl7vu2yEnnrmiuv6KN58np596n2wMb4lvly+fdpV8uTq3dqRaOCK3Ts7+xBIt
/WANRm+Xm9Z/RG6qXTT6VFcVTvbYl8tJcouE0MHd98h1R90Tllt5/WXy+vUrZO2v/6os+f0bQzBg
+zU3yUe0n3FXCX7suuE2uUb72u54+Z+/d1zNpOpb9TrV36pvSr5iW626yiJ5+/93vvzghC+Hh+i7
Pn+bXKf92G6JDFpGc2PnxKc02hebP950X9dLr/jnMcOpmC49Uc65fInceE3UuPg9F90g0VEfk2pd
exVZOeXC4+WWmx8MC9530XXR90bDFx/c+VpZUXlysu37G6vBo186YfR7PTb1DpnSoISDtduQqJRw
oA2HDjnO7AYCCCAwywKUcJhlUJJDAAEEEEAAAQQQQAABBLpZYNHRL6++Zf7Qv22pPkiPTFbIRd+4
UjZcvGQM0Ulf+KBcventlek9En877sTLrpALP2GBjNpu5QffLu+77cxootetX11klVy86fxqXnxy
f38l5aUnyxWbLpQ1Xs2TL6BrvPX298kGbYsi6qbwHvuGM+XdX90w5tn8kovPlMuf/YCsrXton/G3
6hdnRt+Wn0a+0pLxzEomMza/6azPrnXNHnmWXP/z98npDY6HrZHbsE42fPW9cry1BD5B13BfdJ3x
pkfJjZZekWoe6zY0RdOTr7xCzr/cGumu7Q70/bIlV7z5f8qFl3v5CF+3PyY7LD/7ehSQEFknJ65r
0TYvPOszHIZ2HKwQgxVmsMBDpbNgQymRDH0ymYyCDz6TIQIIIIAAAiqQ0D8co385IEEAAQQQQGCG
Av5npVAoSLFYkoH9g7JvcEQ2/uw5GRyJ3qnr7UnLa39puSzs7ZH+vl5JpZKSTkc//sMbUzPMA6sj
gAACCCCAwHwKDMs3L/pDfVvc8nC8XLnnAw2rESpqtT0v7NynT6Rz0rdimfRV4gDFoWEp6BPybDzi
4LszNCA7dw7IkL42v3DZQbKoP3q4buuIrpNqtI6GPPY8tzusk+tfXF3Hk7ThwIs7ZWCP1huk9eoc
tHxR9PDfqhbSW5dsbuwD/Pi6urbc+vYPyW1WY8+pG+Qzd5wn2cKw7NwRbTOez9r17JNuY6gg6Zzm
fezMKeWrqNvUlNStUUq6pQMa2fwB2W22mo+cHpNsf5/0Tbjv8UyPty/jTa+s29B5JqZRukWtHsu+
XwUN/yye7PdLV7Xv5e69qmDfS/0uVOMgQ1vk6mXXyZOW/HsulL++/vUNj1m09fb8t1QqheDCyMiI
FPPDsm/7Vkns3iYHf+cTkhp4PuxUceEKee6Nfyrlxaukf8VL9JzToFFPTwg8WACCDgEEEEAAgYa3
Y7AggAACCCCAAAIIIIAAAgggMD0Bq55GKzO62SozelDuun9ALjh57Nvgqf5FskL7+i41zsP3sFyu
T5atapCWrjN+l5JFy5dpBULjd31LNeCxtG6+PrhvGPSoW6z+o71ekdXgx7JVk6lyR7dxgIf6U8lX
ygIu9ZmJfTbXA3WpcWwPtE7tvPH2ZbzplbUn4Tw10yjdVE6/X6vGHvUDfr90VfteLmvwvdzz07uj
YIMuc/q5JxzQurJnbTuwF4isTxSLoa/fkbIGFqynQwABBBBAoJEAfyEaqTANAQQQQAABBBBAAAEE
EEBg2gIrznqrlm2Iujv+8d66apWmnSwrIjBPAgNy12c3Vra9Xjacvmye8jHXm7UKMWorxbA6MqxE
svXUlzHXx4PtIYAAAu0hQMChPY4TuUQAAQQQQAABBBBAAAEE2kcgvVrO/lylHv3P3ywP7m2frE8n
p3lvP2JnnuDKdAAbrNNSpnsflW+GKsK09YZ/fItMpuxKg11qq0mhhIO232DtQ3uVqdUd0DYcxPpK
5wEI/8wQAQQQQKC7BahSqbuPP3uPAAIIIIAAAggggAACCDRFYO1vvV8u+6Wfy15ZKkdOotHhpmRi
ThLNyYkf2iC7frJLlhx3ooyt8GlOMtFhG2kx0/4j5Q+/e2n4Lh+zflWHWTfeHWsvOgQarGql2CIW
XCjZPO1tnA4BBBBAAIF6AQIO9SJ8RgABBBBAAAEEEEAAAQQQmLlAepGsW3/yzNNp+RRSsu5t52nf
8hltowy2mmlfl3yX674ipaKI9WM6K92QrFatNGY2ExBAAAEEulqAgENXH352HgEEEEAAAQQQQAAB
BBBAAAEEEBgr4CUc4nPiLTrEx+PLMI4AAggg0N0CBBy6+/iz9wgggAACCCCAAAIIIIAAAggggEBV
wAIN1icTWp2S9vVdOZEW6+kQQAABBBBoJMBfiEYqTEMAAQQQQAABBBBAAAEEEEAAAQS6ViAeaIiP
V9puoP2Grv1msOMIIIDARAIEHCYSYj4CCCCAAAIIIIAAAggggAACCCDQTQIaYygVi5LQPrQQHdt3
bzQ6NolRBBBAAAEEqgLW0g8dAggggAACCCCAAAIIIIAAAggggAACkUBCSzLomPXRP5XJsZINidh4
NJd/EUAAAQQQECHgwLcAAQQQQAABBBBAAAEEEEAAAQQQQKBWoKSlG6z3LqGPkKyvdBZwIOjgGgwR
QAABBFxg9C+FT2GIAAIIIIAAAggggAACCCCAAAIIINDdAtpwtLYe3d0G7D0CCCCAwJQFaMNhymSs
gAACCCCAAAIIIIAAAggggAACCHSwgAYaEiktwaC9Bx3KyZRYH0o1UJ1SBx98dg0BBBCYmQAlHGbm
x9oIIIAAAggggAACCCCAAAIIIIBA5wnESjiUteVoDT+E/2ycDgEEEEAAgfEECDiMJ8N0BBBAAAEE
EEAAAQQQQAABBBBAoEsEyhpgiPeh/YZqGw6JEGaIQg2hKekuUWE3EUAAAQSmKkDAYapiLI8AAggg
gAACCCCAAAIIIIAAAgh0ukCshIOFGCzYYD3hhk4/8OwfAgggMDMBAg4z82NtBBBAAAEEEEAAAQQQ
QAABBBBAoPMEYgEH27lyIhn6zttR9ggBBBBAYDYFCDjMpiZpIYAAAggggAACCCCAAAIIIIAAAu0u
YMEGK8oQijZEFSl5CYd23zXyjwACCCDQXIF0c5MndQQQQAABBBBAAAEEEEAAAQQQQACBdhNIlEpi
vXUWbEglUyLWJ7TxaO3pEEAAAQQQaCRAwKGRCtMQQAABBBBAAAEEEEAAAQQQQACBbhXQgEI5mZFy
qkcKuSWStOqU0jkp9SwKQYd4wCE+3q1c7DcCCCCAwKgAAYdRC8YQQAABBBBAAAEEEEAAAQQQQACB
rhYIAYRURkpLDpVibpFsO/ESkcKIlmxISqKnVzK5xZJMjtbQXdbqlwg6dPVXhp1HAAEEagQIONRw
8AEBBBBAAAEEEEAAAQQQQAABBBDodgGtMimdlXKmJMW+FVIu5jWokJRkJhtKOMQDDgQbuv27wv4j
gAACtQIEHGo9+IQAAggggAACCCCAAAIIIIAAAgh0nYAHDlIpbadBu0TPQi3UoNUoLU1ISdtySKfS
ktB56WyvpNNpseXigYeuA2OHEUAAAQQaChBwaMjCRAQQQAABBBBAAAEEEEAAAQQQQKD7BCzwYIGE
pAYULPSQ0mqUrPFo+5zQ6QQauu87wR4jgAACUxEg4DAVLZZFAAEEEEAAAQQQQAABBBBAAAEEOlDA
Ag0ebLBhb29vKNmQyWjj0ZV2Gmx6NpsNAQkr5eDrdCAHu4QAAgggME0BAg7ThGM1BBBAAAEEEEAA
AQQQQAABBBBAoNMELIhgnZVksHELNljnQQefHibyDwIIIIAAAnUCBBzqQPiIAAIIIIAAAggggAAC
CCCAAAIIdJtAPNBg++6frSRDvPPPtN8QV2EcAQQQQMAFav9q+FSGCCCAAAIIIIAAAggggAACCCCA
AAJdK+ABh/rAgk/vWhh2HAEEEEDggAIEHA7Iw0wEEEAAAQQQQAABBBBAAAEEEECgewQ8oGBVJ1lH
wKF7jj17igACCMyGQHI2EiENBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ6G4BSjh09/Fn7xFA
AAEEEEAAAQQQQAABBBBAAIFxBbzEw7gLMAMBBBBAAIGYAAGHGAajCCCAAAIIIIAAAggggAACCCCA
AAIqUCqKlMv6vw61S+i4tiQtks6Gz/yDAAIIIIBAIwECDo1UmIYAAggggAACCCCAAAIIIIAAAgh0
oUDZAgvlksjgbinnhyW5d5sGHwpSTC6QRCYriYMPF0n1aOxBgw90CCCAAAII1AkQcKgD4SMCCCCA
wPQECsWSvv1UlpL+PgldKfrcMLXYbxN9Z0pKuuxIQX/UaJfUHy724yWdii3UMBEmIoAAAggggAAC
CCCAQFMENOBQHhkUGdkv5V0acCgWJNGzUKRngciy1RpwaMpWSRQBBBBAoAMECDh0wEFkFxBAAIH5
FLAgQ16DDTteHJKRfFF2DeYlnUzIEct7JaVDCyaEt6TimbSXpiw4EeYlZaRYlq07dklBoxWLezPS
k0nJIUt7JZNK8uZU3I1xBBBAAAEEEEAAAQSaJOD37MWiVqGUHxLZ/pDI7m2S+uE/SXlonySWrBRZ
vEpGlh4hif7lkk5Hj5SSyWSTckSyCCCAAALtKEDAoR2PGnlGAAEEWk1AAwiDIwUZGinK4FBeUlo6
YWikRwMGCS2/MH5npbVHCkUNWJRlv65X1AkpLd2QqxaTGH9d5iCAAAIIIIAAAggggMDsC1jgoaxB
h2RhOAo87HteksP7pNjTqyUctJSDtu3gwYnZ3zopIoAAAgi0uwABh3Y/guQfAQQQmCcB/5Fhb0AN
a7Bh284BGRgqyMDgSAg4JPWHSi6TlIMWatDBIgvxTmtLsml5XXfHjr0anCiF9YsaeOjL5bVPy6ql
OUlm05pWVF6bOmLjgIwjgAACCCCAAAIIIDC7An7PHkoh6316YVirVNK+1wIQtin9p6wvBo3k85LQ
3ko22D06JRxm9ziQGgIIINDuAgQc2v0Ikn8EEEBgngXsh8loX5K8tsVQLCVk//CIDpOydEFPND9W
1sGXL+kPlv3DeRnOaxsO2tvnkr4xVdL1fJl53j02jwACCCCAAAIIIIBA1wjYPXjo9AWhkgYdEloF
qlSaVrM51ltAIkyPluRfBBBAAAEEagQIONRw8AEBBBBAYLIC/mMk/ODQnx4HLcxINlWW3XuHZWi4
KNteKGgJh5Qs7LE6XTUoocEEX8fGB7VUg9aiJNueH9ChVqukQYZMOqHppGWhtuOQSHgbD9GPHko4
TPbIsBwCCCCAAAIIIIAAAlMX8Bd+8lp6oTQyImV9gSihvU23mIO2zCYlbUy6UNAGpLW3ks5WusHv
8blfn7o5ayCAAAKdKEDAoROPKvuEAAIIzJGA/7iwXyA92l5DNh0FFzS6oCUdopehRvTHiL0oVQol
IaKM2fiwBhmSyVIYWhsOWlGsvimVlGxPSno08FB5kSr6gaNFtekQQAABBBBAAAEEEECg+QIeeCjr
Pb3d19d3lHCoF+EzAggggEBcgIBDXINxBBBAAIEpC9gPEn2vSZb1pSSXLovWoBSCBfuHtWqlYkme
eWEgBA0KGlSwuIEtb+O/2Lk/bMsamrYyDAuySentSciyBWkdT2saoyUippwpVkAAAQQQQAABBBBA
AIEpCYwGGqx0st3La1sN2oe3hzSlUjkZqk615WxaCDzwYtCUjFkYAQQQ6AYBAg7dcJTZRwQQQKCJ
At5QXFKDCSn9J6vVKGmcQdtm0ELX+kNkaCQKHNi4tdHgRa0Hdb6N2w8VCzj0pLVKJl03pYUkrPdG
6JqYdZJGAAEEEEAAAQQQQACBmEAIJlQ+WxsOSWvDQTu7X/fOSisntadDAAEEEECgkQABh0YqTEMA
AQQQmFDAAwe+YFKDDRovkJcs7dFgQ0H27B+WEQ0w7Nah/R4p2I+Vyu8SC0js2m8BB6sLNhGqY1q1
JCrZYNUpWVre2Xbqt+XzGCKAAAIIIIAAAggggMDsCkQvCpUkpffhSe3ts1WcWr0v18/xwMTsbp3U
EEAAAQTaXYCAQ7sfQfKPAAIIzKNAPBBgJRJS2vdkklED0Bo0KGrVSQULMnjvedXPGosIXVp/xGS0
SENG23/o0T6l45aWd/Ft+DSGCCCAAAIIIIAAAggg0GQBe2vIeuv0nr16T2/jdAgggAACCIwjQMBh
HBgmI4AAAggcWMADAalUKgQIilrk2rrF2ohDjwYNli7MaEmHouzcN6JVLEV1vNanaHGFxX0ZbbMh
petZCYeMBh7SGnRISVqH1beo6lfkMwIIIIAAAggggAACCDRVoFTW+3vrK11R4wzW0yGAAAIIIHAg
AQIOB9JhHgIIIIDApAWsVIIVrbZ2HNIpa8vBGpUrheqRotIM9naU/0KJ3pSyIto9GW2/IaPDtAYZ
KqUb4iUcJp0BFkQAAQQQQAABBBBAAIFZEbC7dq04KfwX7uDDrbyOeUmHWdkKiSCAAAIIdKIAAYdO
PKrsEwIIIDCHAtVAg5ZKsBIJVjIhp4GFww7KycBQXnbuLWjVSlED0qPZ0npgE1qFkgYYDlvaK325
jOQ08pC2oIOub2la76UoRtdjDAEEEEAAAQQQQAABBJopYC8RhXYb7OWhSqPRtr1Ewu73o3t+7tOb
eQRIGwEEEGhvAQIO7X38yD0CCCDQEgLxHxxWHVJJf6RkNXhQSJc1gCCS1kai8wUv3WBZtlIQOl3n
2XJZbbshqcEHW9e7eJo+jSECCCCAAAIIIIAAAgg0X8DKNngXjdd+jt/Z+3IMEUAAAQQQMAECDnwP
EEAAAQRmJOCBASuZYG9ClfQtKJvWmytIQqtXOnRJNrTl8MzOohS0EWnrrMqlg/uszYaULNQ2HHI9
aa1WKRMCDhkd2vqe7owyx8oIIIAAAggggAACCCAwLYGE3ttbH3UJDUFoFaraj1aTOq1kWQkBBBBA
oMMFCDh0+AFm9xBAAIG5FvD2F6x9BmvPIZdJhSqVkjqeiBpz0GCCSG9PKjQSrZO1eiVdVks3+Lpz
nWe2hwACCCCAAAIIIIAAAqMC8RIMNm73797Fx30aQwQQQAABBFyAgINLMEQAAQQQmJaAl0TwYEGx
WAzpZLNZDSKkZdWyopZwSMtz2pbDULKo70Rpg9JahdJLli/QgIOWcsjlJJMZbbfBq1XydKeVKVZC
AAEEEEAAAQQQQACBGQmUynpfb32l0xYdxHrvKJXsEgwRQAABBOICBBziGowjgEBbCRS0IWLrvJBv
W2W+AzNr1SlZV9BSDDZqw6KOWCAiKsEgktLfK/YTxZpqsGk2z5axkg8pXaekw0TluBJwCJzz/o+/
zJbWNjboEEAAAQQQQAABBLpIwG7qrdfO/vUAQxgPU/kHAQQQQACBsQIEHMaaMAUBBFpcwB5sF/XB
9HN7R0KbAIVCwe+DWzzn3ZE9K+Fgx6iQz2vj0SXZv39YxwuhvQatRSl0aY047No3LPuGi7IgbwGJ
kqQzGmwIVSvluwOqDfbSistbiRNrc2PFIi2xYtViUYa+DY4cWUQAAQQQQAABBKYvYPfy1tvrJvFX
TjzgMP2UWRMBBBBAoBsECDh0w1FmHxHoQIGS3gAPjhQlr2/DlytV+HTgbrblLnnAwUorWG/tRBe1
GqXwgrw+uNZDpyUbomkJHbeGpJNJXbagS1nAwV6ZomsdAT0+GT14ds6l9DjSIYAAAggggAACCHS+
gAcc7O7Pxu2+XW/Wo5779c7/ArCHCCCAwAwECDjMAI9VEUBgbgXsRtc6G+YLJdm6fY+M5ItyyNJe
0efYVK00t4dj3K35cSroMbLxciLUnyS5HgtARNVghfYekmmdl5QRfaCd0OlpW06PYqI0Wk/suBth
RlMFLPBjx86qxXp+97BktM2NlYuzIfDgx5eSDk09BCSOAAIIIIAAAgjMmYDf34V798pvLgs0lMoF
vT0vhFdO7N6vVOntXp57wTk7PGwIAQQQaDsBAg5td8jIMAIImIC9bZ3XB9V5fX6d1IfUab3p5UWb
1vhuVH6jaF08WoxBP2iZBT0+2l6DNjFXLkeFsu0HSiaj78vrcQttA+hnW8Y6fry0xnG0Y6Nnmgxb
4EjHOL9a47iQCwQQQAABBBBAYE4E9P7c7s7DHbqOR111ypxkgY0ggAACCLSnAAGH9jxu5BqBrhTw
N2+szQbri/omvL5nI8v7U9KbiR5kdyVMi+50qRQdk0IhFd6WL5V6wtCya0EFfzMqnY7+FIVSDy26
L92arUFtTuPJ54qhzZRw3mkhFGvTwToCQ936rWC/EUAAAQQQQKArBOwtIiudbL2O28sn9gqR9dF4
VyiwkwgggAAC0xAg4DANNFZBAIH5Fagp6qsPrq06JXs7ngeg83tc6rdeqrwIldQSDtEx0x8nleIP
dqy8T4XGHaxdB4JG9Ybz+dmOlZ1bfl7Fz7v5zBfbRgABBBBAAAEEEJgDASvVYPfu1tu4dhZosJ4O
AQQQQACBAwkQcDiQDvMQQKClBOofeBa1kWGf5kN/iN1SGe/SzPiDan8j3ttvcA4PMPhyPp3h/Ar4
uWS5sPGSNsweP0Z2HOOf5ze3bB0BBBBAAAEEEEBgtgXC/aDe8yW1peiEtRZtQQfr7EWhystC0QT+
RQABBBBAYKwAAYexJkxBAIEWF4g/EG2UVR6GNlKZ/2keYPCc+HGqH/p8hvMjYOeXd/FxCzTEP/sy
DBFAAAEEEEAAAQQ6VMDuC2P3hnbfHr+n9/v4Dt17dgsBBBBAYJoCBBymCcdqCCAwfwL1AQe70bXe
2gLw8fnLHVseT6D+YTU/UMaTmt/pfpxGRkaikgx6bnkIwufNbw7ZOgIIIIAAAggggMBcCJTthRPt
rbN792JRpFiwUg+VKpZiwYi5yA/bQAABBBBoDwECDu1xnMglAgiMI+A3uzbb3raxz/ZQND59nFWZ
PM8CHKN5PgANNm/njp1Hfg5xjBogMQkBBBBAAAEEEOhCAXsBxe4Nw72ijVc+dyEFu4wAAgggMIEA
AYcJgJiNAAKtL2BtBMRLN2QymdbPNDlEoEUFCoVCyJmdU0l7g62ST0o3tOgBI1sIIIAAAggggECT
BKyc62hZ1+gFL404NGlrJIsAAggg0CkCBBw65UiyHwggEN644Y1svggIzEwgfg6NNz6zLbA2Aggg
gAACCCCAQKsLhBKvmkl7+SSMW3MONm4ZD//YCB0CCCCAAAJjBQg4jDVhCgIItItA5dVreyhqvVep
ZEM6BBCYnoD9oAw/Kivn1fRSYS0EEEAAAQQQQACBdhaIfmpZ+w2lqMSrTihryXLrq0Vg23kHyTsC
CCCAQNMEeCrXNFoSRgABBBBAAAEEEEAAAQQQQAABBNpQICraoFEGLc6g4/qKV7WEg43TIYAAAggg
MJ4AAYfxZJiOAAIIIIAAAggggAACCCCAAAIIdKlAoqSlG7S3zmpRSuio9Vq8PJQwt+l0CCCAAAII
1AtQpVK9CJ8RQAABBBBAAAEEEEAAAQQQQACBLhYIzUX3LJBST58UcktDmYZiz0Ip62dJ8O5qF381
2HUEEEBgQgECDhMSsQACCCCAAAIIIIAAAggggAACCCDQHQLWJl5Jgw17Dz9NSsP75fnlrwg7nl60
XJLZBZLL9klK23LwtvS6Q4W9RAABBBCYrAABh8lKsRwCCCCAAAIIIIAAAggggAACCCDQ4QIhkJBK
a2mGhdpkdFqK/VqPkrblkOxdJImenBZwiIINHc7A7iGAAAIITFOAgMM04VgNAQQQQAABBBBAAAEE
EEAAAQQQ6BQBK9lgwQYbJjXgkFp4kJQLBZFMf9jFRK5Xkum09plomcrynbL/7AcCCCCAwOwIEHCY
HUdSQQABBBBAAAEEEEAAAQQQQAABBNpewAIOVmWSBRZS2l5Dshg1HJ3K9GggIhXN02XoEEAAAQQQ
aCRAwKGRCtMQQAABBBBAAAEEEEAAAQQQQACBLhCwUg3WeZsMaSvFoAGFvr4+KZVKksvlwnyfnslE
JRwsKOHrhRH+QQABBBBAQAUIOPA1QAABBBBAAAEEEEAAAQQQQAABBBAIAtVqlSqlGCzAYF18ugcp
wgz+QQABBBBAICZAwCGGwSgCCCCAAAIIIIAAAggggAACCCDQjQJWqsE6K8lgnX+2Ug7xz16yweeH
mfyDAAIIIIBARYCAA18FBBBAAAEEEEAAAQQQQAABBBBAAIEaAS/F4IEF/1yzEB8QQAABBBCoEyDg
UAfCRwQQQAABBBBAAAEEEEAAAQQQQKBbBTzA4MNyuRwoCDh06zeC/UYAAQSmJhCVl5vaOiyNAAII
IIAAAggggAACCCCAAAIIIIAAAggggAACCNQIUMKhhoMPCCCAAAIIIIAAAggggAACCCCAAAIuQMkG
l2CIAAIIIDAZAQIOk1FiGQQQQAABBBBAAAEEEEAAAQQQQKCbBIojIpXqlMJuJ7SSjERCW5PmUVI3
fQ3YVwQQQGCqAvyVmKoYyyOAAAIIIIAAAggggAACCCCAAAIdKmBtNpQLI5J48SmRwrCU9u+SRDIp
icWHiqSzIgsPDkEHSj506BeA3UIAAQRmKEDAYYaArI4AAggggAACCCCAAAIIIIAAAgh0kkBCylLa
94LI8IAkhl7UXdOSDZlekWyfyIJlGnDopL1lXxBAAAEEZlOAgMNsapIWAggggAACCCCAAAIIIIAA
Aggg0IYCVrLBukKhIOWB3ZJ55Nsiu7eJPHW/SCotpePfIrJ4lZQWvCboUAAAQABJREFUHKQ1K6Uk
lUqF5SnpEBj4BwEEEECgIkDAga8CAggggAACCCCAAAIIIIAAAggggEAQCFUqlYpSHtwrsn+PJAae
14BDRspa2kFG9ku5VKpt2wE3BBBAAAEEYgIEHGIYjCKAAAIIIIAAAggggAACCCCAAALdKFDSQIIF
G/L5vJRHtA2HQl4SxYKkQ8mHhJZ80CBEviBSLOn0opZySITeSzp0oxn7jAACCCAwVoCAw1gTpiCA
AAIIIIAAAggggAACCCCAAAJdKRAFHjT4YCUZrNfmG8pl/awaodfSD8lK9UtdCcROI4AAAggcUICA
wwF5mIkAAggggAACCCCAAAIIIIAAAgh0roC33WCBButDGw7ajkNGSzkktbSDd4WCBh20L+k0m55O
R4+UfH3acnAphggggEB3CyS7e/fZewQQQAABBBBAAAEEEEAAAQQQQAABF4jacIhKNljpBi3eEGbZ
dAtIeOeBBv/MEAEEEEAAARMg4MD3AAEEEEAAAQQQQAABBBBAAAEEEOhygRBo0KBCUdtnsL6QHwm9
s1iowXpfzoc+nyECCCCAAAImQMCB7wECCCCAAAIIIIAAAggggAACCCCAQAgmRAyJqA2HULpBx2M2
JZ1G6YYYCKMIIIAAAjUCtOFQw8EHBBBAAAEEEEAAAQQQQAABBBBAoDsFvB0GayQ6nU5IMhU1GB00
ytZ6tAYfCDh055eDvUYAAQQmKUAJh0lCsRgCCCCAAAIIIIAAAggggAACCCDQyQKjJRdqSziEIg4J
DThYHy/u0MkY7BsCCCCAwLQEKOEwLTZWQgABBBBAAAEEEEAAAQQQQAABBDpPIAQdtBRDqVSUhPW2
i8mEFDXSUNI+lUpq3CFR03eeAnuEAAIIIDBdAUo4TFeO9RBAAAEEEEAAAQQQQAABBBBAAIEOFbBA
Qwg22P5ZqQZKOJgEHQIIIIDABAKUcJgAiNkIIIAAAggggAACCCCAAAIIIIBA1wmUSqLFHMJuW7wh
mdAGHbSnRqWu+yawwwgggMCUBAg4TImLhRFAAIH2ECgMPC+PP71DRooiPQtXyBFrDpZWv+C3Y57b
49tALhFAAAEEEEAAAQQQmJpAORZW8HELNISCDlNLiqURQAABBLpMoNWfP3XZ4WB3EUAAgZkLWJ2r
Ox64Tf7p3x+vJHaEvOvyS2R1tlogeuYbaUIKjfJ8WI+V3G7tfDeBgiQRQAABBBBAAAEEEJhzAfsd
MdpotJZo0BzU1MOd1BIO1tMhgAACCCBwAIGavx0HWI5ZCCCAAAJtJJBM9cdym5V2+FnQjnmOITOK
AAIIIIAAAggggEDHCNgrP1aywf6zcXsJqFrCgReCOuY4syMIIIBAMwQo4dAMVdJEAAEE5kHA30Yq
aT2rNm5D6xKJshTCtCjG3ColBjy/PrT8ep61slgphDesRiFbJd+jOWIMAQQQQAABBBBAAIHOFSiX
imL9aBdCDyH4wL35qApjCCCAAAK1AgQcaj34hAACCLSeQKkgg8P5kK9UJiM96Ykv3fHia/ZA34IO
U+1Kut1CIS9F+42RSkm2p6e2SPVUE9TlS4URGc4XNbmMZDK15S7qs5iK78Q0ttWMVTz/lnYm2yvp
FsxjM/abNBFAAAEEEEAAAQS6TyAKL0T7Hdpu0JINXtKh+zTYYwQQQACByQpM/NRqsimxHAIIIIDA
LAqU5LnH/lt+fM8muXvz47XprjhCTjvxZHnFKS+Tg3uT1XpWdz/+I/nGfz0pqd6iPPvjB7SMgHcP
yde+crOsySVlRCclkzrseYn86q+dKovrHpgP7HxaHnnkYXn44Udk8+M7PIHKcIUcc8pxcvIrT5Fj
Do1X2VS7WGn3z+Vr//wfsqdXf5b0nyjnnPtaWTzyvNzzra/Lv//48erC5RXr5TffcLDce+/jkllQ
lu0/vr8mz1/9l6/IYdruREmDHdblew6Tt/za+mqeC7s3y63/fIfsXbBA9ssyefO5b5G1/eP9WSvJ
0/d+S/7tR8/KggX7JXvIafK2N58gfdXcRCMFzfutmve9C/TzstfIO972ClmgAZvdT2+We394t3z/
gcdr1jjihF+R0057lRx1SH1KNYvxAQEEEEAAAQQQQACBthGwF5ZCKeSy/qKwvtJZ5UpRBUs+hSEC
CCCAAAJjBcZ7MjN2SaYggAACCMyRwID85N++KF/78bONt7fjcfn+t63/ubz3inNlRaWgwL5f/FwD
BQ+HHwehflX9oWCdvYX07OYHZEfljSQLOIiGHk7foAEHbZQ5dIPPyp3/96/luw9XPjcc7JDNP7b+
e3LsGy+R81+7tmGJh8L+XXL/s573F2XvrzwtGz/zN/Lj+jSfvVsee/SoENywWaVKfn0xz3OUX9uP
vJy2QQMOlTyX9u+NbWer7Nh31gECDsOy/cG7pZqtrZvktDM14OD7X9loKZ73rY/JnjPXyqMbb5Gv
3v24Z6tm+PgD3xPrTznnPfK2VxxaM48PCCCAAAIIIIAAAgi0q0AoJa2ZD2052H26/m+/K0JVStHP
jHbdNfKNAAIIINBkAQIOTQYmeQQQQGCyAuEtIl34qe9/WW65d3t1tTB9xeFyeK/IE088Ed3kh7nD
MlzQ9hoqpRSKpcFq2w22zmh7CNGPg1SlpEA0fTDMt2YeQkDip3fIHQ9Fvxw8H9UM1I3Y8g996+/l
Pw+7TF6/pq+aH1+vpHUj+bjIvfKFT98bUhidFiVon5OVPNt4MdTdpL9ldNy2YYGG8IOmsv1kUvOs
y5RK9rNHAxQ127H1RtetrBIG0XaTkuyxfPkcrR5KP4x+jqaXa9L8qdz45z/1FUK+qh9iI5bHe2+5
UfoX/S95/dr+mjzHFmMUAQQQQAABBBBAAIG2EQh33FbnqfbReEKKet9b0j6lPR0CCCCAAALjCRBw
GE+G6QgggMB8CBSelbu09IJ10YPyE+T8S8+Sow+uVNlTGJKd2x+Te775Vdm0Y0jirSCsOOHX5LcP
GbDmluWZTV+Xb256NqSRTB4ib/gNrW5oYVqDE0lrjkESqUWyMvZ2vxWUjrYnsuKY18rrTn2ZrD5k
qZYA0D8T2pbDwO5nZdO3/07u3ByyFv753g8ekvVrXikaB2nYeXrxmSe8/mw54SW9suuZLfKj7w3L
6pNPk4uPGtD8lOWpe/9Nbv/Jc5V8LJezzn+rrFmgQQfNcCJRknTPEjkklud4upMZrw0uVCMPY1Zt
lG9b6OQ3vENedfxh0t+TkD3bH5bb/+mb8kRs7e998U45/sq3yvL4QYnNZxQBBBBAAAEEEEAAgbYS
sBvoyk203T1r+Ybw3/h30m21d2QWAQQQQKBJAgQcmgRLsggggMBUBexBd+HFZ+VnVuxAO/v8ugvP
lLVah1A+n688iE/K4kOPkQ3v+rD8ynBZepMFLRmgdanaD4GexbJyVb8MDw9LacUynb4tpFMqLZVD
Vx4sBy3oCW/fZ7PZ6C38gq5beTspt3ytHH/8Uvml15wi65YvDOlZSYiREWv1QRtI7lsup579bnnx
2s/LT3Qde6s/8dAjsmPwJFmtbUNY5w/q83nLk7U0HXU+/Y0X/aG8anXU9sPq1UfIy9ZHJSGKC/pC
aYtCyPP2kE4iEeV5WU9Seqyxag2UhKqVNM+FSp5tO/FSHFb6wbbrJTl8+1FebF5Jl69ODctaNr0U
haWV1/Qtv55nW7pcXiPn/e475Jjl2bCyzVuy6gS54PcXyk2f+ZI86R6JH8lDT7xODl67KCzn6YYP
/IMAAggggAACCCCAQJsJJLT9Buu9S9p9eOVe3KcxRAABBBBAoF6grrnQ+tl8RgABBBCYS4FSfn/Y
nD/0ttII9iA83kfzUpLNZqoPx315G9qyhUL03pF9tvYaisXRh+g2P768jfcddpKcc84ZcvSK/vAg
Pr696rgslRPOOqomf4mQ/qhQtL3oc3wbrzj79+SUl0SBhWp6lf3y5fRZf7Url0d0H0b3Ox7A8PVt
YV/Xxm16fPs2zTqbZvN83JepXz5KazTN6PNyeful52sJk56aYxDy0HeEvOlXj6tJ99sPPf3/s/cm
AJYdV333eVuvs6/SjDTad8vaF1vClndsY7xgbGO8YBsCBBMIEDshkBACBELIB5h8OARwsL8QvGAb
GVtesGTLRrJkW/ti7dJon0WzT093v+U7/7rvvL79prcZdfd73f2rmeq6t27dqlO/d999VXXqVOU2
vk6X+AMBCEAAAhCAAAQgAIGFR0CrJqmtL99cQUk9C3kcBCAAAQhAYCoCWDhMRYdrEIAABOaBQAyA
V33EvTCwxo73wfFHm4PkX/vrL9r6f/nDdpwvh5SsCnxGkawddKyZ/3IxmK5B+TQQngbys0F25V0o
1Hzwvur3je2LIGuBcnnsJ0DplCYG4XUe+YZ8qbBiKaVT+SVfBqnhZYWVgMpX2rBwaN1/1uvtilMG
W9YSyVIhZZb9kRVFlD+mWMjqIkWJ4nSP8stbDYw4h5BXOdV99pXOo9xIm6Vxaw2vn2TNnFsypLRZ
7ynqq7KiHoq7/MffZCcN1NxqpHVjZJBkXn7cqbameqdtTzxcO/T0Xhv2PHrjvJWaAwhAAAIQgAAE
IAABCCwMAmoHe2NX/5Nv6hvMit5/cK92drS1F0aNkBICEIAABOaTABYO80mbsiAAAQhMQUAN+0b/
Kjs+Ne6zuUONxt32f/7HH9mXv3O37dyfLW8UWaT06gU8D5c6E83788cpygfkR0YO2YEDB5IfGj5g
e3c+2yqt4QP8cU+EulirZ4oHxcm/7KKTrex5xXkrgyM8iPsjzCsXUlZNFroeLo6ze9RhymTS3Kz8
NaWPa/n45X2+70XznonC+sA6O2NDVlq6/uhuOzBmdR5iEEIAAhCAAAQgAAEIQGBBEVDb1vUKyWfH
voyr10AeZcOC+igRFgIQgMC8Exib3jrvRVMgBCAAAQiIQAxkZ8cr7KIP/Ih9839dnWbaK06z+2//
5j/aHdcXbMMLXmwvu/QCO3XzmsMa+mr4K20242isI1AoZPsfaG8DXY9Qeeed7msM77YH7r3HHrz/
Ybv9wa3jZAvLAd2TdTJqydqiltvIOVMCZIP5kb7hm043GpWWvNm9YyVLHjEolTI5sw5NVg/JG3VS
KBcWCPV6Vo7SR3xYQ6QI/6NroZjQcaRVVymzZlC52S7P6dwVI5G/8hipyYoikz3SRd6yCDHrtf5B
t4p4JttHo1B4xva5NcTK3uyzUNr2+sb9hBCAAAQgAAEIQAACEOhqAtq/obmHQ2pxN1wD4T5rfXe1
5AgHAQhAAAIdJIDCoYPwKRoCEIBAnkAMiFfWnGW//IGyXfMXn7Z78gn8ePvdN9pn7r3JChsvs/f+
xMtty4pKSqF7k8KgGeYHubOZSc2Nnv1E1/I+G4Sv21N3/pP97y/cnBuUzwrP5xXihKyhVFC8jiM+
yzNSZ2G+TB1HWikSdK9LNe6G9vTtckQZCtuvjcuoeRLpdZo/zqfNx+s4fz5xGa7AGcznt876iuKA
AWGeK8cQgAAEIAABCEAAAouAQNaxWAQVoQoQgAAEIDCXBFA4zCVd8oYABCAwAwIxsB2hBt/Lq0+2
1/3aL9uLn3jY7rj1Jvv+gzvSTH9llwbit3/XPv6n2+zdv/IeO3l5MQ2MK173aoZ+uWnNkBWf7deg
PRs0uK+Z+kobM/aVftvtX7FPfOmWVhm6T/Kc/oILbPXK5dbrRgA+j9+e+Po37AGPzzulU34hv8K8
07V8ubH3RKQZHh5O9xfdwkFpM1+ySqXivpjCsG7QPaGgOKw8L7e9bKWPdPV0XTFyY9YRcU+E2fWs
HJUlOfLyR34pF5/xVW2udJXdv80OuuHDWv91TUqUZn0iT0IIQAACEIAABCAAAQgsFAIFb+vKh2uo
ze8eBwEIQAACEJiKAAqHqehwDQIQgEBHCZRt1XGn2ytOOsdecmCb/eC2G+0rNz6Qk+gx+//+6Qf2
628+28q5hr8Gx4u5cy2pNDaQHwP6Yx2Fwv6H7fNfuCWXr9mlP/Ieu+KczT5b39Im0RpM1xJCJ1ee
tQeuyewuYuA9G2gfd/v4E5cllA6STU7ncro34nQe8Tr2k3QecUo3bVnpxuf/J8oMGZRjKGii3lma
Udu3fay8xvFbbE1lYsXHWCqOIAABCEAAAhCAAAQgsAAIeFvdG+CZoArUPld7vhnVajMvgKogIgQg
AAEIzB8B1nyYP9aUBAEIQGBCAmqoyydFgTfgNbAdVgiKlwVCqX+dnfdDb7ZffO9rTXsUx8B745nt
dqh5/4SZe2TkHflGOVHuyNBu25bL8+xXvMde/oJNVmnUkpIh8pUco6PjLQMauWWUIl2EkX85WSpU
TBYWeR9ytORqq0fcH2Gkj/MoJ0LtATG5m+padtdE+RYK2WeRtw5pySsFyL5n7IadY8qThq9pK8sG
+VBMTC4TVyAAAQhAAAIQgAAEINCdBNTC9ZZ/+teaquQTmdy2eZzAakPjIAABCEAAAnkC04/A5FNz
DAEIQAACc0Ig31DXwHr+XAWGgmHgmBfayy9fNzaYvW3URptWzrpH94bL51GLyAnCPU9tHRd73Anr
W/nHoLkG0MOFLHE+XejqlFSfkCcfxnF7HoqXubbC8O1p2s8feuK59qjW+cHHb7Vr8sYhrSuHH4RM
Cq+95ibb7UqEkKE93P7wneMyWL9ppeX20B53jRMIQAACEIAABCAAAQgsFAJq80uVIJ/a/942dm2D
WvbJ0kH1iHazjnEQgAAEIACBIDA2MhUxhBCAAAQgMK8EYhBbyoLawV327I4DVnRrAO11oP0D4vro
6KiNjBy0Pc89k6wekjJgvSsn6tV0HkIrfb0+mk6zex+0J3Zm+yToPJzulyKhPLgidSJkwaBlk3bt
PpDCmKWvOB1Xdz9k133tnsM6FkmOMLX2zEPeKCfCsFCIMNJF2MjJbPagPZ6TOS/3WH7jh/bvv+ZW
e9YtMMKFXHu33mx//ImvRfQRhYUdN9lHP/bP9tzomNIh5C8eeNS+9NUHx+V3sS9DxQ/rOCScQAAC
EIAABCAAAQgsUAJF379BPlxBe8G5x0EAAhCAAASmIsC4yFR0uAYBCEBgHgloUP25H1xjf/PX/8P+
4O+/aY/s2Gc1j4sBed9NwZ6+63q7+u5sUD0NqPf1W48P9us475atPyZ/atd9+SZ75pA6C3U7sOtp
u//+rZZOPaZvWaZwiBtu+OS19tCu4ZaVg8rd/sj37Y//8nM23hYi7pg8DNknUhi03zW4rk3mL31n
Upl1b3ntFrtyfT6XW+0vP/lte3pftotzfWSfPXTzF+0jR6lsaOW87Xr76B9+2u56cpeTkKvbnqfv
tc985O8st32D2fqX2ilrxytBWnlwAAEIQAACEIAABCAAgYVEoFiyau8KG+1dadWBtVbtX2X1Yq81
it7eHZvDtJBqhKwQgAAEIDBPBNg0ep5AUwwEIACB6Qho5nxPz6rMguCBG+0z99/gg/7r7ezzjrX+
xog9fMudaYA7r1x41Q+d6nstyLY52zsgyli2/jjTWPy2pjKisO1G+8v/dnPKW+WYnWEf+NBmO8Y3
OC4s32QXuQXDTe6zvO+yT330LjvjwivsmP6qbb3xu/ZYZHwUYV7pMJXiYdn6zS2Zla6x7Qb7qz+6
sbWfhWT+6Q+/zTaUQgmz3M65/Hz71tW3jilHHv2m/cV//3bGsClrUsy0KWUKhfEKmomqFZyz8D77
7F+NX5Op1pbnq193ng2OUxBNlCtxEIAABCAAAQhAAAIQ6G4C6i9U+1bYtnPeYXW3sLaqW0+XKlba
cLKV+5ZZT7l33FKu3V0bpIMABCAAgfkmgIXDfBOnPAhAAAJTECj3VNLVsUH67Xb3bbfZd2+723b4
YHbenf2Kd9tFx/aPDbbnLw4cby+9bNz0/9bVGEj3G7N7S2vsxe99XTqORCr/gdtutG9/53u2tVmu
4k47e0skSeFUe0OMSziTE5f5qsunkbktn1Vnv9R++Ky2yOZpXtGw7rK32M+857XjEo4Zh4+LHsfh
rBe/2E4LTh6Gy+etuCve+jN2/sa+uEwIAQhAAAIQgAAEIACBBUsg9UWKZasNrrXa8o1WHdzgVg7r
zHoHzSq9Xq/x/ZIFW1EEhwAEIACBOSGAhcOcYCVTCEAAAkdOQPskrDrn1fZzfcfYTTd/x265b1ua
qR/KB+2xoOO1p1xoP/SiS+yMzW7W3LRK0AC4ro25op30knfYm3u/aZ+//o40iB75aMZS4wUn2XK3
boj7+445137xZwbspmv/yW5+aGcrm1a+J5xvP3L5ZXbm5lH7+j1/Yd9PKXyWUyvl2EFRZtY511Oa
WrcdchUKJTv5pe+0N1eutc81ZVY2IUPjnJNtednVBM1x/6y+/faC13/QBo+90T73jVtTqapTsGis
P8dee9Wlds7xq23o2cwSIhNtrfW3/QKGEiHKVLjp9IvtksvPslu+ca1de8fjY/k2lRDrzr7cXnrJ
BbZlTV+a5aVyxVc+6pWVx18IQAACEIAABCAAAQh0NwG1YeW0j5xcccUx1vA+SN33dNO1Uv9yK/le
cxXfa66k/Ry87Rvt7nQDfyAAAQhAAAJOoOADLGNTNkECAQhAoIsJaMBdryxtnnxguGo33J8NjL/4
9LU22OsN3+YGy2r8LiQXr+GoXygBasNDdmBoyA4ePGRavqfuA/J9/b5nQ3P8vuyNfTXwe3szk+Zo
7IuP8hgZGclm61cP2YEDvidD2uStYitXrrSBvp6WskHpJYPSyzVqw3Zg/8FUnncz0h4Py/sribvS
qcOhjaTLfQNuTq1loHpaHY3Ip1EbtaHhUbe8rtigy6wOiuSUjPH5tOqpTozLO+R11f3K21zmkeGa
jfh5j5czODiYZI7PNV+/kLtc9P0p9u230aorX5xN2TtEKwZ7k7xKn7h43rVGwfPsackV8uj60DPf
sz/8iy8lOSTLy9/9QbvsuOVJfquO2H7/LKqjvvRUueT16bf+Xl/bVvK6EwfVM8JWR63ZcQvZuz2M
51A80vfsvux7dsWZ69L3LJ674Nbt9UE+CEAAAhCAAAQgAIGpCajdK6d2rdrNw8PD6Xjfvn3pXO1D
tXP7vV2vNuDy5Vn7ONqFuoaDAAQgAAEIBIG2+Z0RTQgBCEAAAnNNIBr2EcZArxr5ivN5RNbbP5i8
zvPXJZsa+xrAVwNfPhQOER/n9VKvDazoHVPIeH9Ag8m6R/lGulZY7rPlq/paM5tUltKFXAUvt+K+
3NpLYfzMppRvocf6XEGiPMMrn7yL8iIu5EnnLkOfa1b6/f5MkRSpsjCfZ+RTa7hCZtlKW+bKhnCh
HJH8ckUpIsRrCrni3qzOtdTZUhnlsitPlldavNQhi86Xrkv+8Hn5Ij9CCEAAAhCAAAQgAAEIdCOB
aE+rHxFt8lAmRD8gaw+X0/XobygtDgIQgAAEINBOYGxUpv0K5xCAAAQg0BEC0ahX4TFQ3n4cnYL8
wLaOlT7iIk1UIp9XxOXTxP1xbbr06mBMVFbkGdciv4nCSKtryk9KjXYXckTddD3yjrhIo2v5Y52H
y5cVcdOF+bwk20R5hCySP89kury5DgEIQAACEIAABCAAgW4jkG/bSumgNrAUDHKhkIg03SY78kAA
AhCAQHcQQOHQHZ8DUkAAAhBoEdAgd/tAty7GYHd+6aj8ILeO8/eqg5A/jwIi78hPHYeIU6hZ+3IR
F+mUXzjFxeC6wnCKz3vFx+yoiM+n1XF0XGJAX0sSqew4j/Tt8ihdpNG1WNqoPV10kCI+5IlyI//2
MNWxMFa3uD/S6f6UxuuvMP+5tNc17iGEAAQgAAEIQAACEIBAtxJQG1Yu2v3Rzo92cLSrI4z03Vof
5IIABCAAgc4QGBs96kz5lAoBCEAAAtMQaG/Ix2C2OgAx6B9p8qGuxYwkdRLivigu0iqdriutXMS3
h/n7dC3Kz9+jfNQBUSgf1yKvyGOiUPlF+gjz9+k4fNwf9+g86hHX8vcqLu5VqLRxXWFe1vz9haZM
iouy8vdFXnFN6eK6jnEQgAAEIAABCEAAAhBYaASiPRtt3InaygutTsgLAQhAAALzRwCFw/yxpiQI
QAAC4whEQz4iY6Be8WrUTzVjX2nCt88w0owk3d+eT5QTM/x1rjRySq8OhcJQPKQL/ifS5M+jbIUx
A0r3yikuyo9zxbXLmRL7n3xHRsftcuTLypcnOVWONqNW2G6ZEfnqnryL/HQ9fy3F18fS6lxpZLmg
MNLHPXEeYXCI6/kyOYYABCAAAQhAAAIQgEC3E4h2bHsYckd8nBNCAAIQgAAEJiKAwmEiKsRBAAIQ
6BCBfCM+FBD5gXxdD6+B7sncRPkobT6+/X6dR1n5fPP3RB4RF2F7esVHXu3l5NPmjyOvdjkUn/dx
T8RFOe28otzIV/fpWOkVxvW4X9eLvctsi1/bqhM73pb1lpOiJNIrlJfT/XEecekCfyAAAQhAAAIQ
gAAEIAABCEAAAhCAwBIlgMJhiX7wVBsCEOgeAjFY3W4BMJmlQaSPAfM4jxpFvGbmy0U+MbAe6SNd
nLena08f+Uf69jCuR75xPlm6uB7pI11YKsT1CNvTRXzcF/JGGPERtqeP86i30lXWnG7v/PCHW0oJ
xelzUdkKdd4uR/t5e3lRDiEEIAABCEAAAhCAAAQWEgHatQvp00JWCEAAAt1DAIVD93wWSAIBCEAg
EYiGfYSBJc4jjPjpwvb07edx/0zjJ0sX+Tzf8Ejznyx9xEd4pHLpPnkpFOTjPPKL8EjzJT0EIAAB
CEAAAhCAAAS6noCWS60Na+1V/ZepsBVKPSnUMQ4CEIAABCAwGQEUDpORIR4CEIDAPBOIAez2sF2M
uN4eH+dxPcKY8d9+Pc4jPNL0cV97GPm0x093HveFpcdcyx35R7lhqRB7YEheXQuFQ+x9EekjnK5e
XIcABCAAAQhAAAIQgMBCIpAsgEcPmT15m1l12NvEvpRr2fdN23haCq08kCkgUDwspI8VWSEAAQjM
GwEUDvOGmoIgAAEIQKCbCYRyQTKGMkFh/rib5Uc2CEAAAhCAAAQgAAEIzBqBetVs77NmIwe8cewK
h54Ba6w+zrN3y99yMnmYtaLICAIQgAAEFhcBFA6L6/OkNhCAwCIiEAPdz7dKR5rPkaZ/vvJNdv+R
ynG06XVfeMmivS9k/RDLKMXeDZF/hJPJTTwEIAABCEAAAhCAAAQWIoHY26xaHTXbv9N6bvyY2Z6n
siWVlq23+g+vNVu5yRUO/WalStrjbCHWE5khAAEIQGBuCaBwmFu+5A4BCEAAAguEQCgSpGiQwiGv
hFggVUBMCEAAAhCAAAQgAAEIPC8CagenpUfrdWsceM4K8p5jo1iyRnXE93VwZYTays+rFG6GAAQg
AIHFTACFw2L+dKkbBCAAAQhMSyAUDbF3RMzsihsjPtJFPCEEIAABCEAAAhCAAAQWA4GkYPCKqB0s
Xxv2/Rvcp0k4uQoOj/gyS+4rtZpPzqkli2Bdpp2cg8QhBCAAAQgYCgceAghAAAIQgECOAB2mHAwO
IQABCEAAAhCAAASWHIFa1RUL8jkXSglFSSlRdCsHHAQgAAEIQGAiAigcJqJCHAQgAAEILBkCoWDQ
UkoTubg+0TXiIAABCEAAAhCAAAQgsFgI1Nxyoe5+pDrsCodhG2xTKgyPjFhjeNgGmssuSfGgtjLt
5cXyBFAPCEAAArNDYOLRldnJm1wgAAEIQAACEIAABCAAAQhAAAIQgAAEupxAWDAolNKh4cqEiJPo
eXuGelPh0OVVQjwIQAACEOgQASwcOgSeYiEAAQhAoLsIMDOruz4PpIEABCAAAQhAAAIQmD8C+bZw
ozpqjVHfILrNyaIhFBF5ZURbMk4hAAEIQGCJE0DhsMQfAKoPAQhAYEERqI/Ynud22b6Dw+Yrx1ql
t89WrF5jgz0Y7C2ozxFhIQABCEAAAhCAAAS6ikAoELKw4cskuVVD25JKsnLIWzp0VQUQBgIQgAAE
uoYACoeu+SgQBAIQgAAEpiKw++Hv2t9+/Iu27bBEJ9p7fu3ddvKy0tiVuh+igxjjwREEIAABCEAA
AhCAAASmIZAUDK5kqI5WrSDflr7hDezkWVKpjQynEIAABCCQJ4DCIU+DYwhAAAIQ6EoCQ0/cZH/8
8Wsmke1R27ZrxBUO/bbjnq/bn33qW1m6jRfZT//UG+y4/kluIxoCEIAABCAAAQhAAAIQGE9AWgZZ
NsjnNQ6K0iWlTn90gIMABCAAAQgcToD5n4czIQYCEIAABLqIQL2+z267+kumNWPH/PF2/vnn2PER
572eev2QPXLT9cn0O83Oevb79sSOoS6qCaJAAAIQgAAEIAABCECg+wmUCg2TzzudFUvF5LXeUn7P
h3w6jiEAAQhAAAJYOPAMQAACEIBAVxOo7njYvvzsmIiN9S+2n33fy21Dj8e97vU2fLBmPYMVP6mZ
9Y2l01Ept8rS+CucQQACEIAABCAAAQhAAALtBDRxR4YNmaHDeKVDFps3e2i/m3MIQAACEICAGQoH
ngIIQAACEOhKArJmkBsZOZgsG2LTustecp6tbAzb6GhmpFfpc2WDpx2tN6x/uawgsupo1lWlWEj3
KqZYxKgvI8NfCEAAAhCAAAQgAAEIjBFQOzu8llKq1mtWkB9Lkiwa6h4jdQTWDTkwHEIAAhCAwGEE
UDgchoQICEAAAhDoJgKH9h4Y6wC5YAN95ZYSQXKOKRIKdtqrPmS/eMFuG6rW3ephja1biYlDN32W
yAIBCEAAAhCAAAQg0P0EwsLhMEl9Qo+WU8JBAAIQgAAEpiKAwmEqOlyDAAQgAIF5JxCWDLJw0PG+
HU+lsFbzJZNsvS3zpZSq1aovl1RKs6t0rFlWmeKhZIOr1tigp9T1sJLQ9ZiJFeG8V4wCIQABCEAA
AhCAAAQgsAAIFBpu3eD+MNdwZYM8DgIQgAAEIDAFARQOU8DhEgQgAIGFRqBaHfGlhmo+2F6xck/Z
jmoRoXrVRoZHtSOCu5JVestWnqXliOou37DLl+Xb4/mmQqb8UypUksJBiRqN9bZi0E25XRHR7iKu
PWxPN9F53ZUW1bQWU9HKZec2A7kmyoc4CEAAAhCAAAQgAAEILGQCaktLpSAf7WrVR63vNHHHJ/Ic
3hJXChwEIAABCEAgI4DCgScBAhCAwAInUN33rN17x132/du/ZY9uy1dmg51x0dl24QUvtNOOWzO1
8qE+ZI/ff5fdfevd9p37Hs1nko43nHGRXfSCF9jZZ51ky6f45ajvedA+/7dfs30DftvyF9qb3nSF
rSzWbccjd9iN37zBvj9eQDv3ytfblS+6yDYOjo3wq2Nz6Ok77QvX3mGVwR777nfvSJ2dzMLhTvv6
P9RteU9m0aBOjywZ5KJDFFYNpWUn2MtfeZGtnkx7MLLH7rvjNrvl5uvsvnHczE4841wvI2Xb+lMY
HbXNl73WLjtpZSuOAwhAAAIQgAAEIAABCCwFAmp31wtFN3AoJstirIaXwqdOHSEAAQgcHYEpho2O
LkPuggAEIACB+SOw455v2p996rpJCtxm931f/htmZ77WfvVtl9nysXH91j0jO+6zz/7Z/7UftGIO
P9h23/ftGnk7yd7282+zszf2H57IY6oHd9sdzz7bvPacHXzVc/bA1/7U/vGOCZPbnd/+ovvv2ds+
+AE7e93YCP9zj91td91/f0uJkL976wP35JZQGtvDIRQOERaLB+3iq1zhMJZtK5uhZ++xT/35p+yR
Vsz4g0fvu3N8RPOscs4rJ4wnEgIQgAAEIAABCEAAAouBgOsVsja4LB3aVk/yRUq9im2Ri6HS1AEC
EIAABGaVwARDT7OaP5lBAAIQgMAsE9CAuvy2u66xj3zy2nSsc83sn8in9Pd+yb5x785xA/iKH37m
Vvvdj/yt3dvMc9p8Gg/7QP0f2K3PDB9Wq1ROIZMtHTe+Zx/9b39iX7g9i5tINsU1Gs/YJz/yBXtm
dCxdoTHUqpcsGzLrhvFFalbVRF57OcgXCn1WSeHY/g3KobH/MfukKxsebtY55Fp3/Gl2/LqJGWZy
NmzH/uGWXOOl4QwCEIAABCAAAQhAAAILm0DWhndFg7e/5dtdw9vW8jgIQAACEIDAVASwcJiKDtcg
AAEIdCuBA4/YZz79nSSdOgbJnXCFvfd1l9mxq/usPnLAnnvqEbvpn662O7dl13fuOujJ1mRp9bf6
rP3jR/+hdZ7lc4b96Dt/yE7dvN76KgWrDu2zpx69x776ua/btmY5GuT/h49+y07+rVfaVIsLteRq
lnDZa95ul5y1xfqLQ7b17hvsk1+5pVW22R122/1X2WvOzuRbd/4b7T1rd1ihVLCH/vmv7Ot3x5JJ
6+0173itbe51hYLvtSBZYkmlQqFuT916jX351rb1kXKlmNXtwe980R71uJBvw2Vvtndcdbat8Prq
+p4n77Sr//rqlEa3qozXvP/n7YwB389iRY6fLuIgAAEIQAACEIAABCCw6Aio/9DsYzTrpq6A2sX+
x9vRi67CVAgCEIAABGaRAKrpWYRJVhCAAATmkoAGyMM/9r1v2tN5i4azX2O/+I4r7ZgVFdMGyFbs
tbXHn2Wvf/+v2DtfeU66b9P6ZclSIGb0P+t7PtzezEMWBPX6i+xf/Ju32Jm+30O5ULOq8qn02+bT
L7Z3/4u32LpkjdBo5nG93Xz/nnEWFUpfTfnUx5VTrx9vb/4Xv2pXnX+iDSZFwYCdcN4r7f2ve2G6
Pyu7bjfc9ogd9Dx03igts2M2bbJ16zbYCcefmeTPrAzW2oZjNtq6jRvtmGOOSX7Dhg0mv27dRtu8
cW1LpvbPItV75Gm77fpnsjKcZ33dy+ztV51u/Va14eFh96PWt+5M+9F3vTylkSzyT2+v27IVK6zP
uQS/+Czay+EcAhCAAAQgAAEIQAACC5WA2rhNvUJqg4+rh+/fYPJNJwVEUkJEBCEEIAABCEDACYz9
UoADAhCAAAQWBoHq03bjdY8mWbNB79PsXa863/ryCoiWIqFkJ176Rvu3H/qQvfTkZbn67bHbr75z
XCfizT93pW+wPPGSQsWVp9iPv+WSVnqV++3vP2QjuRwVV69nShFFZ7Jtsbf/y3fY6avLrYH6GLBf
d/Yldp7LGa4xNGTV5nl2bzZ1qtpcailLN2KNWrZ8VNwX+em87pbfuncqN9y8rnQveuXZE3KrbDzF
LvfrSqP89+2XdUjmpss/0hFCAAIQgAAEIAABCEBgoRGQza/au/L53RqkWFDLXR4lw0L7VJEXAhCA
wPwSYEml+eVNaRCAAASOmkAMdB/cttXuaSoUFFd/4dm2vjhiIyPZ4H10ABTKK432NGhotn7zfPTZ
B+3bzY6EZvDbaa+z45fVPI9qSi8ho7wQuG/zqXZS9UZ7qLkvgt3zgD178AW2uc/zlhwuU1gE6Fz+
yrf78kd9o245MJZf5Fso9NiGk12mhzIFQenRR2z7oYtts2/yrDTKK+Xp+UZ+jUYcm8s6kuoX9VWa
EbeQ0D1ZXNVGR0et5vm1WFRrVvZ0dXlPN+DLKClNvr6K9zusuNotNrZnm1LXZL3hPtsbIuOqYxwE
IAABCEAAAhCAAAQWHQHN4pE/zKn9q73SsGw4DA0REIAABCDQIsBoSQsFBxCAAAQWBoFCo5QbgPdB
/TOPsYIPoI8NymfH+droWjgNqDcamWIh4s87c5OVU/zh+bTyray1k7eMzXhqNNy+IZdvK10zTuf9
PZkyIn9t7Lhi644/Nckt2RRfdB/XQ97pwkg/UZgpD7IcUr3dOkIWDpF25879reOIU1g/tNOedGWD
XD5exzgIQAACEIAABCAAAQgsZgLR/s3XMd8Kzh/n03AMAQhAAAIQEAEUDjwHEIAABLqcQDT4NWCu
Wf/7ntuRBsF1Lt/rGyvH7HvNutcmyvIx80hh+2z8/bt2t6wRlMe61f0pLx0rrXzZN2WWj3x8gr8t
37S5lU7WBsPVeio7LBtqfr+OJY/yGqm5hUHTUiHyjfwU3yiUWvnVfRaV7ov6RvpiMZtBFfWI+yuV
SpIv6pv/GEMxoFByyKdjT1Rqnivu5s/eaNub60JFecrnidtusgdyiomBgUor+yi/FcEBBCAAAQhA
AAIQgAAEFgGBVju84BOB3Le7RqHs7XcWymjnwjkEIAABCIwngMJhPA/OIAABCHQ9gYP7trcG5SWs
D+0nmWNAXidxnA8VHwPxyiOc4rTZc7i4J841EK846agrzf5F1hk5ZKPDroVouuigTHauPPI+0imM
exWGa6Udt3rs2PJIreuTmHSnvHJKg1RGab1d9rqzowgPb7eP/fFn7c7HnrUDvofEvueetru+9Tn7
u+sfzKU51c47aVXunEMIQAACEIAABCAAAQgsVgJj7XFvpY+rZLS/x0VyAgEIQAACEGgjgGq6DQin
EIAABLqVQMzSr/peDXGsQfRisTzOqkFWCXLRIVAaHcvpOFkjNGf5R1ypUWhZM+StGnRdexzoPpVZ
92wUKr96vWzFUqbsiHwUhguLAVkixHF2X2ZtoHQlV2bk5VNcyB3lFEtj68QW3CKip6fHenszSw6l
1f2RR9ktO8Zc1kHSNblI19Mzxk/xxeJD9pVPP6zD5JRO8qp8ucvf8ko71vepyNchZEwJ+AMBCEAA
AhCAAAQgAIHFQsCbznWfjFTQhKTx+oY0zaktarHUmnpAAAIQgMAsEsDCYRZhkhUEIACBuSSggXAN
gq/YuDkVEwPptVo2MK4B8VhKSccaFJeL4/wg+aqNJ4zLY+9QtnGyImOJokgf9/s2zbbzycfH3acT
yRSypIv+J8r2g9ax8o28WtebN+Tvj2OlUXq5kKV5koLIT2ki32KzzilBm2VEijv0uH31s/dkl6f9
u85e/mM/bS89beW0KUkAAQhAAAIQgAAEIACBRUHAuxDqRaSeRNadSNXKt9/zx4uizlQCAhCAAARm
lQAWDrOKk8wgAAEIzD6BGICPnEu9PXGYwnu37rAXbzkxKQrGDb43B+sjsSwb5JSfLAUUZscFu+nR
Z+0VZ65NFgcxeK+ORFyXUqE2vN+eeki9jpjXtMp6/VdE1yJtvR7XUlEpPhQDCuUU6h75klsv5J3K
Cyc5dC4lQuSvazoOGXWuY+U1nVNe+558KO3NkKV9ob3t/RdbeffT9tiT22z/IS0PVbG+VStt8zHH
2THHrrcBr1+UpTCOJQMOAhCAAAQgAAEIQAACi5FAQe37fPu64G12+aZTW5j2cNAghAAEIACBdgIo
HNqJcA4BCECgCwnkB+KtWEkD8SHm9m//wHZdebId04zQoHi7q4+MWNUH+mPBoXL/MlvvibZFwu/d
adtfcY5t6hu/z4I6EjGYf+Dxe+3uSK/w/M22qm0zufw4fHRE2sPILw3eT2SFkC+j7bg9L52LTcQr
ecS13ZpO9/uG23KJ5/Hr7Jg1a2xgwwY78cwxixBdk9cG1nLKL89U5zgIQAACEIAABCAAAQgsWgLe
FvYG8aKtHhWDAAQgAIG5JXD4qNTclkfuEIAABCBwlARiILy06iR7xZZ8JrfZV25+rDXorsHxMe9K
hXuvt9/5/d+3z96yvTUYX1ixxS4+dSyPQuFB+9K37re63xuD9+MG1g8+bl/51I3pWtz1mgtP8m2k
x1z7fTofk2NMprE7sqO4rz0+zkOOLDxcIRL3Rxj3TRQ2jSzSpcbWr9vnvnqz3b/1CXvymWds286d
tmvXHtuzb58dPHjQqm40EdYZUY8oI5NlohKIgwAEIAABCEAAAhCAwAImIEWDZinJN5UOjaJbR7uP
tvACrh2iQwACEIDAPBDAwmEeIFMEBCAAgdkl0GenXXy5fe3RG1rZPnbd39qnaz9mr778TNuwquLr
HFVt364n7JZ/+hu77gdZslUDHt9yPXbq5S81e+AbrZht3/2sfax2wN768gtt44r+LL4+Yju23mlf
+pur7aFWSj/Y8mo7c/34pZ3yl6c6VkdFA/idcKu3nObF3tsq+rHbvmFbbx9TYrQuNA8KG06zKy+8
0C688Axb73KjaGgnxDkEIAABCEAAAhCAwKIjkLNwcNtft0nO/ukYBwEIQAACEJiOAAqH6QhxHQIQ
gECXEIgZRQpXnnaRvWTdDXZ9tkJQkvC+f/683X/D5IP5z+wd8klKYxsg9x17vr3xvG/Y1XdkSwzJ
guLZW75if37b16yw8UQ7caBgjz76aFpeKLoWSmN2qr39Dedaf3MAPuTKY+rWgfny2hfa+3/4AfvL
L92d6pWXOatbtoSS4qUUKex82L7z9UftpmtPsnf+0rvsjDV5pU3+bo4hAAEIQAACEIAABCCwMAmE
JXVL+rrv/SafnC9h6qF8Ie3lwPKiGRf+QgACEIDAZAQ6M8V0MmmIhwAEIACBCQnkB/Cz42V26Tvf
axetOzx5e4chO7/UXnnuMW2D7D12+qt/wX7kIu3mMKZ0SMfPPjqmbHAlQwzG+8YN9hM//0Y7YTB2
gxgboE+ZzPDPWH7jb5h46+eRcYkmTjMuSeskukkR0Wjss8cfuydOU7julLPshWedZaeeeqqdumWL
bdmyfpwlQ8b7Ufu7j1xve8bdyQkEIAABCEAAAhCAAAQWGQGfVNTwPePqxR6r9q9xv9ZG+lbbaN8q
b/iP7XumWuf7KIuMAtWBAAQgAIHnQQALh+cBj1shAAEIzBeB/AC9GvZpSaKe9fayn/qXdsqdt9rN
X7vJnnBh4trg4KAdOHDA7MRz7dWXXmYXnHGsVRp1Vxy0SzxgZ1z1Htt46r1262232O0Pbm9tEr18
+XLbv3+/1Wo1a6w/1V5y8fl27hlbrNc3ig55opMRYbHYmwqI6z3qsDQVFhEXoRIW/Vdo2bJlts/3
TWg0Bqyc24Q67iv3rTTJsnfvXq9fxQoT5Bd5FnrKLdnMKim/uKbNqp+6+Uv21Zy+4axX/oS93je/
lvzy2rMh1cWXpNq7/SG77hNfsIe8vKx+37YfPHWlXb65L9Uxi0uH/IEABCAAAQhAAAIQgMCCJRDt
2hS6sqG24lir9qywJy74WbPaiC+o1LBiT79VBlaPWxpV7ey4d8FWHsEhAAEIQGDWCfi4jf9C4CAA
AQgsAAJp4NtfWaOjo3ZguGo33L8zSf3i09faYG/ZKhUfjG4OGi+A6sxYRA2Uy6neOlYdq9VqplDw
eJ0XfKC+Njxs+w+N2PoNG2xwYND27j9ofT1jlgixb8LIyIhJIaE8du/enfLWn3K57Fs/jNihQ4dc
EdBjxx57rO3as9eGhj19byWV30rsB1IC9PX12bCXq58S5ZvCQwdteLRm5Z4eW7t6dcpXaTSYL6c0
qofSS/aBgQEvc9gOjXgaP+/x+xSvNJF2xYoV9txzuzzfqi0b6EsdHckrp7SxubMUFwddSaINn3t7
e73sYipf6QYGemzno0/YH//VX6W6NE5+tX3wjedYX3OjbOW3Zs0aGxoaSl7nQ49cb3/2mZtSGSrn
p/71v7eTVmV7VwRP5b2Y3GHfs/uy79kVZ65L3zNxCeaLqd7UBQIQgAAEIAABCCxVAtHuVps99TP2
PGdVb5sffO5pVzhU3bDBJzyVKzaw/kQr9/alCUNqf6vdLqe2IQ4CEIAABCAQBFhSKUgQQgACEFgg
BDTDXwoDDajHgHyt5rpjVxJs2rTJVvrgfMmtGVYu10D+oaQQ0OC+OhChbCj6YL7uX7VqVSuPpNCw
og0uX5mUDQW3bFi7epWtHOxvKRWivP7+fpP3HknKR52UcI1C1vlY43kn5YHno1BpojOjfORVj5KH
y5YN2qDnp8HuvFfnRcoGlbNmzWpP09u6HuVp4D8Ngvu9UoJUvF49bungC8+mtCpTSo2SlW3DySfb
+9///qSguOz8LVb0fFVvySJlg+ocbMVrtJjlIZkuueQSO3m1l+/p1RGL+oQchBCAAAQgAAEIQAAC
EFjIBKREULta1gzFvmVWXL7RzK0diqs2W2nlsUnZoEleMdlnIdcV2SEAAQhAYO4IoHCYO7bkDAEI
QGDWCGhAPFzjE39ptbtut5UrV6bB/hig12C7BtaH//rPrfoTb7DC/n0pje5TGjldL/px9V99wEZ+
+9+1lA4xeK7B+6SEeOoJq73hpTbylX9Mg/i6L9LoWGWNfv3LVvc09ccfS/lKORDlhGzDv/sbVvvg
+7zMalI6qB5Ko1B5FA4esOpPvtGG/+IjSYGhwX5dU1nqyOi8evcdVnvtFVa95eakfFAnJ/JRGp1X
/+5vrPa215rt2WWr3apCsiiNnJZskm3FyC+91x5539vt1FNOsQ984AP2yOO+fJTHq1O1wa1CGtue
seqPvsxGvvD3zTqX7fZvfjvJcumll9ob3vAGO3j9N6zh1yNv5Y+DAAQgAAEIQAACEIDAQicQVgoK
1cZOvqfXSvKV3mQBrbjFauW70D8/5IcABCDQTQRQOHTTp4EsEIAABCYgoMHt/AB3Y/cuK/7MT1j1
rtuSckDWA7IC0OD8wf/1Z9b7R79jlXvvtOr735aUDhrY1wC+FAUlD0dd2VC5/uvW88mP26H/9G/T
skgapFfnYe3atVZ7YqvV3/MWK7siofKhX7BD11yd8pdFhLzKGvnaNVb+1Z+zkqexn3prUjpoYF8d
FJWnpZaG/vOvW+/ffszK377ORn/hfVaojmbKAbcO0HUpG2rvf7tV7r7dev/k9+1QU+mQrCI8n1A2
FH/6HVZ++kkr/ey7bPT7N6f46AhJ2TD8fz5mJS+rfP+9VvupH3elw+5UD6WR4iMpG37lZ633G9+w
k793gz303rfZab5B9Jsv2Gg33PVwWoKq7sqG+rvfYpWtj1jl13/Z9n3q416PtVY+7RUmZcOb3vQm
e/LqL9nAL3/A6lKSeB2kOBHX9s9ngo+QKAhAAAIQgAAEIAABCHQtAbWb5dUfkFJBlsxqi2sikvoJ
alOrD6A2vNrqmrCjdHFf11YMwSAAAQhAoCMEUDh0BDuFQgACEDhyAjGwfehVr7NGpcdKP/NOq955
m61fvz4N8kvZMPDH/8UOnHeRPf0L/8YqPgA/+r63WfHA/pSm7IoLKRt6vnWt7X7vz9q+V/+I9X3q
Ezb0Wx9OyohjjjkmKRukQCi5UuOJf/NbNrzZN4n+t79oQ1/6h7TkkJYdOvTVL1rl137OqpuOsx3/
4Q+ssHdPS+mg61JsSNnQ71YH+17xWtv1vp+3nhu+adUP+lJG9VrqsCTLBlc2lF0xsu2DH7IDF11u
fVI6/M8/TR0cdWhk2VByxUrDOzNP/8bvW31wmZV/7l3J0kGdHnV4Rv7v/7ae3/sNG37hhbb9V3/T
yo886EqHtyalg6wWKt5pGvnXrmxwa4xdb3+3PXXJBXbqLTe60uHHk9LhJ1//Mht67FHb+6ZXWeOZ
J+0vz7nUtg6usIHf/nV75KMfsde+9rX21re+1Z749N/bpt/6Ratt2GjDL74qKRqO/BPkDghAAAIQ
gAAEIAABCHQvgVAghOJBSgUpF0LBgIVD9352SAYBCECgmwiUfstdNwmELBCAAAQmIxCz/DWrfLRW
t8d3DqWkx68dsB7fHDhm2SwWM998fXUcs+qH+wfs4KUvtv5/usaKn/+UjV7yIhu++u9t0Afs9517
gT38K//BDpx0qg0fs8nWfPlqG3ULg4IP/A//ys9Z3z9/w7b/5Ads+5veYXsvvMwqO7fb8i9+1g48
+4zZyadZwQfri74s0cMf+m3be+6FtvvSK2zFbd+zvs9/0g6dcLJVH3rQej/0QRs99jjb+p/+ux04
8RQ7eM4LbeVX/9HqrpSoX/UqO/Qn/9UG3Hpi10tfZVt/5pfs4FnnWsM3l1vxj39vw3fcYoUrrrLa
T/+EVX5wlz39wQ/bjh96ue3xcgYefcgGvD5DpXJKn5QNxZI98h//0PadeobtufhFtuqGb1jpc5+0
kQsutdFrv2K9v/ebNnTOebb11zteOn8AAEAASURBVH/X9rt8h447wVZ/+R9s9Lqvmb3ih23k3/2S
9V33Fdvx1nfZk2/5STv4opfYwYfvs1Nu/a49+J0brHzu+TbqSzqtOLjf/vycy+yO1Rvs++s22dm7
ttvx377WHvXy9z3xtG3+nV+z2voN9tTv/akVNx6bnrt4zvTcyamDthhc/rnLf8+2rMu+Z6p3zIBb
DPWlDhCAAAQgAAEIQGCpEwhFQ7TxFKqNKy9lg6yKQ/GgtmC0B5UOBwEIQAACEGgn4HuPNhe5br/C
OQQgAIEuIxBr/2uT3wPDVbvh/p1JwhefvtYGe7OGcDSOu0z0oxInXs9Rb234rOODBw+msPbg/bbp
3/8rKw4dtKJvDh3Khpp3CuTUEVh94zdty//736zha68WDw3Ztnd+wHa+xa0GYpkmDzf9z//HVl/7
Zav19VvBN5t+yJUN+884J6URz4rvBXHK7/269T31eMp35NjNSdkwutw3c26WM/CDu23zf/6wqcuh
cnZd9Wrb+tP/SkKkzonyWf+Fz9j6j/9Pq7uJdsHllbJhz0tfmTZtVj491rDj/vC3bJnv1VB3Wequ
pNj6239kBzZu0uUkT68vfXTyb3/ISi5TYfhQUjY8/u9/z+pePylk5Fbe/M92/J/8XrICSXX+sZ+0
bW97T2IW9d70139qG6/9qo26pYi51cUnzrrEblq1Lt0vs/H1y1bae69zq45tT5r3tGx07QZ74nf/
xHz9pWRNog6XTM3FWGblcoulwxXPW+t7dl/2PbvizHXpe6a6L6bvWfrw+AMBCEAAAhCAAAQgkNrb
wqAJXvkw2rlq+8rFeYQpkj8QgAAEIACBJgEsHHgUIACBBUMgBuCXioVD+wcTA8HDw8Np8PyQWzrs
u/ByW/6tr9vB0862R371P7pioScNgkdnYHjLScnSYdWN37Jn3v5e2/bGt6V7xTB5VzjscWuBynM7
rO/xR5Nlg5QNcspDXoP5ey670la4VUDNlzV66Df/wEaWZftCKA/JdWj1Wjtw9rm2yq0CdvuSQ4+7
ZYPfnPKJsg6cfnbKa/lt37Unfv5X7bkrX9baA0EJ666UkEXFgC+LVNq31x75zf9qQ75sk+6Pz77q
5e91S4eVrkg55FYcj3z4t23ULSKCjdId2nR8snRY5Wm2uSXHM27dEHnouhQTe867xMqutFj22MP2
0L/+TVv1prfa+eefbxdccIGdddZZtuWUk2yvW0Os9P0ltHzV/b/xX8zWbUidKy3lJC5SNCjEwiF9
zPyBAAQgAAEIQAACEFjgBKRAkI9+wERhpEHZsMA/bMSHAAQgMIcEsHCYQ7hkDQEIzC6BGFRuzbxe
IhYOMVgeioYDB7JNi4eGhrKBdN/kubpqTVI2TERcg+y9nmbk+BMmupwG8xs+qN/nGzMPbz4+nUdH
In9D0TdjlmusWp2Pbh1Lzt6nnkgKDikb2jshcd7jio1hX/oozkOZEOc2MuwKkJ026ktCycX1KEjn
le3PWt3l0FJN7dcjXY9vaD183JZUTqRRqOdHTvL2SV6v80ROaUu+QXSl5htEr1mX9qbQ7H7tH5G3
cJCJuVxL/okyW0Bxh33PsHBYQJ8eokIAAhCAAAQgAIHZIxBt6MhxsbR3oz6EEIAABCAwNwSydTfm
Jm9yhQAEIACB50EgGvQRapBbs4xiSZvY06HmigQt6qMOgdLqulwMHCu+cfKp1pObsRR56lqkq594
ckqjMnQ9Zu6rnNTZ8OWE5HQtX04oRFJ40inW05Qj8lFa3R/pGr5XRK/HxXWFcq1ytESRW1BUmvnE
gH7ImerjigTdpbwjnygn8qlLlqasuiane5WfZGnJ28wn1TF3rPNCry9F5UsqVdzLskFs5WNN28hX
eeMgAAEIQAACEIAABCCwmAjQ1l1MnyZ1gQAEIDB/BFA4zB9rSoIABCBw1ATyjX0NdmswXKHiY6A8
Bt5DUaBzXdNAfd6FQiIfp+PIR9eVbygCoozIJ8ptL0cD/XnXXs5E15W3fDjJIEWAXFybaTmRT9Qj
wrhfeSpO6RSGpYPi5eL+7Gw8D7FQPvI6DjaRlhACEIAABCAAAQhAAAKLhoDvceYNZmvU3TI4tZ99
qo/a7CWfGJRruy+a+lIRCEAAAhCYVQIoHGYVJ5lBAAIQmH0CMRAeg92aaa9BeQ16x0x9lapzpY0B
9jSD3zsIoShQGl0PiwGda+A9LAJiMF73K10Mqsf1UAREOaFQyJcTeej+UFyoHDkN8Ot6uPZywoIh
ylEekY/u0b3yecVF/rqO5drlzZej+yWHyoh0uifKijwUF3KIl+J73dpBecXeDVH//D26DwcBCEAA
AhCAAAQgAIGFSCC11aVsGNrljfdDZjsesYYvL2o9fWYV74NsOMsKFbcA9n4HDgIQgAAEIDAZARQO
k5EhHgIQgECXEYiB7Wjga8A7PwAfA/yRToPjqdPQrEcoCmIAXtG6rvQK2wfYo/pxPQb6o5yQY6bl
RHmTlaP88vUJOUNuXcvLK7nk43rIGWHIGwqDqE/UNdJFfNQnzqMsxctLnjjWvTgIQAACEIAABCAA
AQgsPgLe5h4ZMhveb4W9z1ihOuJ7xfWb9S6zwvrTF191qREEIAABCMw6ARQOs46UDCEAAQjMLoEY
3M4PiGswPAb6dSyndOF1rnh5zcwPF3lFGPdGqHSRRz5N5DXV9dkuJ8pSvSWLFBUhZ4QhY4QRH2Hk
oesRJwsRHYdCQmnkIo/sbOxvlB8hlg1jbDiCAAQgAAEIQAACEFj4BKKdnCyORw5ZcdtDZnueMrvx
Y6542GfF5RvNVm6y4Y3nWKHY09ozLt8/WfgUqAEEIAABCMwWARQOs0WSfCAAAQjMEwENjMcAeoQq
OgbMo+GvAfr89RAvrsd5pIvz6fKZ7nrk83zLac8n8muXN+Ijffv1ieRV2rAQifsiXZwrjDiF7eXk
03EMAQhAAAIQgAAEIACBhU5AiodGwyf5jA6bSfHgSysVDu21etmXVHILB/PllkI5sdDrivwQgAAE
IDB3BFA4zB1bcoYABCAwqwRi8FuWDXIxAK4B9vx5OvE/kW6y65EuwsnSTZdPXI/OR8gZ+baHR1tO
ez7TnU9WTsjZHk4nd/CeLt10cnEdAhCAAAQgAAEIQAAC3URA7WJ5tZ8btZqNuLKh4EqHAcW7oFpM
VNeHR0as4F7tYrWJo10cYTfVCVkgAAEIQKBzBFA4dI49JUMAAhCYFQLTNfCnux5CTJfu+V6frXIi
n+nCyeQ90vjpyuE6BCAAAQhAAAIQgAAEFgOBltJBE5qkfHAlQ8E1DlI61KV8qOskU05M1qZeDByo
AwQgAAEIPD8CKByeHz/uhgAEINAxAtHIj3AyQaa7HvdNl26665HPdOF0+Ux3fbr84/p0+Ux3PfIh
hAAEIAABCEAAAhCAwGImIMWCvPY4q7tv+EbR2iw6XM0PZFM9Ojrqlg+j1tPTky6FpXOkI4QABCAA
AQiIQBEMEIAABCAAAQhAAAIQgAAEIAABCEAAAhCQ4kFWDGHJkBHRokqFtORSLFsKKQhAAAIQgMBk
BLBwmIwM8RCAAAQgAAEIQAACEIAABCAAAQhAYJETCAuHtIeDL6VUHRn2vRrcN+ut5ZRqzSWWpIhQ
OqyFF/lDQfUgAAEIPA8CWDg8D3jcCgEIQAACEIAABCAAAQhAAAIQgAAEFjqBZNnglUjbRLtSIW0U
rd0bfHPocH6Wll6Kc0IIQAACEIDARASwcJiICnEQgAAEIAABCEAAAhCAAAQgAAEIQGCJEMhbLGhm
akHLKjVdw5UOySsuFx/XCSEAAQhAAAJ5Alg45GlwDAEIQAACEIAABCAAAQhAAAIQgAAElhiBsHBQ
tRsNbRE9pnBYYiioLgQgAAEIPE8CWDg8T4DcDgEIQAACEIAABCAAAQhAAAIQgAAEFjqB2DC6Vqta
w30sptQolNzCoZT2bchbQiz0+iI/BCAAAQjMDQEsHOaGK7lCAAIQgAAEIAABCEAAAhCAAAQgAIEF
RUBKByka0h4Ofpy3c8gfL6hKISwEIAABCMwrASwc5hU3hUEAAhCAAAQgAAEIQAACEIAABCAAge4l
UPI9G4rNzaKleCgWim7hUGxZPHSv5EgGAQhAAALdQAALh274FJABAhCAAAQgAAEIQAACEIAABCAA
AQh0A4H85tBSPMi0Qb6phOgGEZEBAhCAAAS6lwAWDt372SAZBCAAAQhAAAIQgAAEIAABCEAAAhCY
NwKyaKjWfQ8H9zqWq/mBPA4CEIAABCAwEwJYOMyEEmkgAAEIQAACEIAABCAAAQhAAAIQgMCSIBAm
DV7ZsGwIS4clUX8qCQEIQAACz4cACofnQ497IQABCEAAAhCAAAQgAAEIQAACEIDAIiCgDaPli00f
VSoUSr6aknwh+YgnhAAEIAABCExEAIXDRFSIgwAEIAABCEAAAhCAAAQgAAEIQAACS4yAqxxaNdZx
+3nrIgcQgAAEIACBSQigcJgEDNEQgAAEIAABCEAAAhCAAAQgAAEIQGCpESi4hYN85gqudCgm77tG
LzUU1BcCEIAABI6CAJtGHwU0boEABLqHgJrBw6N1bwLXfCOzojeBC1aseQNZa4ziIACBIyIgE/p6
vZ5M6UdGajZc1bF3Lfk6HRFHEkMAAhCAAAQgAIGFSiDf7NNxvh2YP16o9UNuCEAAAhCYewIoHOae
MSVAAAJzREAN4JHRmt3/9AErF13RUGJd0TlCTbZLiECs3Vuv1axab9iIh72V0hIiQFUhAAEIQAAC
EIDA0iZQb9R8s2j3TafpXfLh2MshSBBCAAIQgMBEBFA4TESFOAhAoOsJSNnQU3bTXp99Xa+7dYPM
fH3KDY3frv/oELDLCbQUDm7pIGuHnnIpfdfys926vAqIBwEIQAACEIAABCDwfAiokyXvTn+jj5WO
Uyx/IAABCEAAApMTQOEwORuuQAACXUygUirYGccOWrXmS75oISVXNhSbCodicWz2TRdXAdEg0JUE
YkmluncypXzQqr3lUtGtiNTvzDqeXSk4QkEAAhCAAAQgAAEIPC8CMfFEval8jyoUDs8rc26GAAQg
AIElQwCFw5L5qKkoBBYXAa0f2ucjoHVfSmm0UfdBUbNKOXulqUGMgwAEjo5Ao5F9f0aro2lGW6VQ
sqJ/z/haHR1P7oIABCAAAQhAAAILiYCUDlI2qEWYJp9kJg7ZZg7MPVlIHyWyQgACEOgYARQOHUNP
wRCAwNESkAWDXl69lVpqBPc2G77FYj1licLhaMlyHwTGrBh6XMmgrmZBm7G7tqHse6RgPcQTAgEI
QAACEIAABBYPgbBeDcsG1UwtwHqj6o3CajpWO7De9GoL0tdaPJ8/NYEABCAwVwRQOMwVWfKFAATm
hEA0cBWWfEC07pvaForZhrZpBo7HR5o5EYBMIbDICUh/p++SFAxyOs4sHDLLB75fCQt/IAABCEAA
AhCAwOIkoP6U1yy1/Pw4c62YxVlnagUBCEAAArNKAIXDrOIkMwhAYC4JxEBnhJVKJQ2G1mq1VGzE
RziXspA3BBYrASkY5CIsueJB36m8X6x1p14QgAAEIAABCEBgyRNQW7DuluPyfqyWoe+Wl3x2vOQJ
AQACEIAABKYhgMJhGkBchgAEuo9AKBRk0qtB0RgYDUnjepwTQgACR04gvkdhOh8KhyPPiTsgAAEI
QAACEIAABBYMAVk1SOkg37RwkKJBHgcBCEAAAhCYCQEUDjOhRBoIQKArCMQAqGZcy9U168ZdnLcr
HtJF/kAAAkdFIL5vEcb+DXF+VJlyEwQgAAEIQAACEIBA1xJIk7m8j1Us+LK17pPSQdKWfBtpeRwE
IAABCEBgBgRQOMwAEkkgAIHuJMDAZ3d+Lki1OAjE9yvCxVEragEBCEAAAhCAAAQgMC2BsHBoJlR7
MCafKIr24bQESQABCEBgSRNA4bCkP34qD4GFRSAathFi0bCwPj+kXdgE4nu3sGuB9BCAAAQgAAEI
QAAC0xFouJWDvJzagNoyr1aV1UO2iTT9sOkIch0CEIDA0iaATdzS/vypPQQgAAEIQAACEIAABCAA
AQhAAAIQaBGQWiFTLWR7N0jRkPbPa6YIxUPrBg4gAAEIQAACOQJYOORgcAgBCCwsAjR0F9bnhbQQ
gAAEIAABCEAAAhCAQPcTKPgW0fLh0nJKxWKycKAPFlQIIQABCEBgMgIoHCYjQzwEIAABCEAAAhCA
AAQgAAEIQAACEFhCBKRqqFcGrFEZtJG+NVZo1G20Z5k1egadAotkLKFHgapCAAIQOGoCKByOGh03
QgACEIAABCAAAQhAAAIQgAAEIACBhU1AVgvyadmk3kHbf8KVVh8ZsueOvcztHBpWGlhpxZ5+6+9b
ltJE+oVda6SHAAQgAIG5IoDCYa7Iki8EIAABCEAAAhCAAAQgAAEIQAACEFggBNJyScWSNXqXWb3Y
Y9W6LBrc5sGVEIVKjxX8WkqzQOqDmBCAAAQg0BkCKBw6w51SIQABCEAAAhCAAAQgAAEIQAACEIBA
xwiE8kChrBtKpVKSpdS/0pdUqlqx7EsrNRpu3dBjpXLZfSWlUdq4t2PCUzAEIAABCHQtARQOXfvR
IBgEIAABCEAAAhCAAAQgAAEIQAACEJgfAmlJJVcwlCsVt2YoWt2P5XQuZYS80uAgAAEIQAACUxEo
uLY6+wWZKhXXIAABCEAAAhCAAAQgAAEIQAACEIAABBYdgRgWGhkZSRYNCuv1evK6FoqGiisepHBQ
KIfyYdE9ClQIAhCAwKwQwMJhVjCSCQQgAAEIQAACEIAABCAAAQhAAAIQWLgEYpmkUDDUarVUGSkW
YtmlSLNwa4nkEIAABCAw1wSwcJhrwuQPAQhAAAIQgAAEIAABCEAAAhCAAAS6nICsGuTaw1AySBEh
h2VDwsAfCEAAAhCYhAAWDpOAIRoCEIAABCAAAQhAAAIQgAAEIAABCCw1AqFgQLGw1D556gsBCEBg
dghg4TA7HMkFAhCAAAQgAAEIQAACEIAABCAAAQgsGgKxt0MoIBZNxagIBCAAAQjMKYHinOZO5hCA
AAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCCwJAiyptCQ+ZioJAQhAAAIQgAAEIAABCEAAAhCA
AARmTgDLhpmzIiUEIAABCIwRQOEwxoIjCEAAAhCAAAQgAAEIQAACEIAABCCwtAlUh80aDWcgr7++
OEahYIVyTzrnDwQgAAEIQGAqAigcpqLDNQhAAAIQgAAEIAABCEAAAhCAAAQgsAQIaM+GhisbCjse
NhsZsvrBna5nKFph5Saznn5rrNxsVqp4XGEJ0KCKEIAABCBwtARQOBwtOe6DAAQgAAEIQAACEIAA
BCAAAQhAAAKLiEBBSoeDz1nj0D4r7tueLBvqlX4r1KtWWFFfRDWlKhCAAAQgMFcEUDjMFVnyhQAE
IAABCEAAAhCAAAQgAAEIQAACXU5Alg1yo6OjZgf3Wun+6832PGWFJ26zhls42JmvduuGTVZdvskK
/SUrl7OhJCwduvyDRTwIQAACHSKAwqFD4CkWAhCAAAQgAAEIQAACEIAABCAAAQh0C4GkeKjXrDF8
wOzQflc+PGdW9GGjkYOujRjybR1cMdFUTnSLzMgBAQhAAALdRwCFQ/d9JkgEAQhAAAIQgAAEIAAB
CEAAAhCAAATmhUC9Xk/KhGq1ag23cijU3PsSSmH5MNKMt1rNr9WsWPR9HXwfh1KpNC/yUQgEIAAB
CCwsAigcFtbnhbQQgAAEIAABCEAAAhCAAAQgAAEIQGDWCSTFg5QP7k1eTns6hJfCIeKzq/yFAAQg
AAEIHEYAhcNhSIiAAAQgAAEIQAACEIAABCAAAQhAAAKLm0BYMEjRIF9zhULdrRlKbuVQ9LDcXD5J
qoe6H9dl3aA0nlZWDnE/ezks7ueE2kEAAhA4UgIoHI6UGOkhAAEIQAACEIAABCAAAQhAAAIQgMAi
I5AUCFIsNFzF4L7g9VNcUjZ4KMuHUDIssqpTHQhAAAIQmEUCxVnMi6wgAAEIQAACEIAABCAAAQhA
AAIQgAAEFhABKRHkZeEgX/CNo+XlfJto6R6SrzUtISJ9SsAfCEAAAhCAQBsBFA5tQDiFAAQgAAEI
QAACEIAABCAAAQhAAAJLjYAUCcm6oVlxV0NkR75BtO8SvdRwUF8IQAACEDhKAigcjhIct0EAAhCA
AAQgAAEIQAACEIAABCAAgUVHQNYNTQsH1c0NG1p7SC+6ulIhCEAAAhCYdQLs4TDrSMkQAhCAAAQg
AAEIQAACEIAABCAAAQgsHAKybpCLfRviOG/ZwObQCRF/IAABCEBgGgJYOEwDiMsQgAAEIAABCEAA
AhCAAAQgAAEIQGCpEEibQ8usIVypZCaPgwAEIAABCMyAAAqHGUAiCQQgAAEIQAACEIAABCAAAQhA
AAIQWPwE3MZB1g7J4qEQuzikajd3dFj8CKghBCAAAQg8LwIoHJ4XPm6GAAQgAAEIQAACEIAABCAA
AQhAAAKLg0CjUU/GDDJo0LFcwYrJL44aUgsIQAACEJhrAigc5pow+UMAAhCAAAQgAAEIQAACEIAA
BCAAgQVBYLyFQzJxKHicPCYOC+ITREgIQAACnSbAptGd/gQoHwIQgAAEIAABCEAAAhCAAAQgAAEI
dJhA2jjal1Kq12tWkJc8rmio+UHdfanolg5+nvcdFpniIQABCECgCwlg4dCFHwoiQQACEIAABCAA
AQhAAAIQgAAEIACBThCQoiEpG1qFHx7TusQBBCAAAQhAoI0AFg5tQDiFAAQgAAEIQAACEIAABCAA
AQhAAAJLlkDd926Qd6dVlIoFn6vqnhWVEhL+QAACEIDANASwcJgGEJchAAEIQAACEIAABCAAAQhA
AAIQgMBSINBwtULYM+hYTn9RNiQU/IEABCAAgRkQQOEwA0gkgQAEIAABCEAAAhCAAAQgAAEIQAAC
i5GA9m5I+ze0KtemYiiW3MzBPQ4CEIAABCAwAwIoHGYAiSQQgAAEIAABCEAAAhCAAAQgAAEIQGCx
E5B1gywb9C9ZOvgm0aF+0GbROAhAAAIQgMB0BFA4TEeI6xCAAAQgAAEIQAACEIAABCAAAQhAYIkQ
KPj+DfJjLltkSQoHlA5jVDiCAAQgAIGJCaBwmJgLsRCAAAQgAAEIQAACEIAABCAAAQhAYEkTkHVD
KBrYx2FJPwpUHgIQgMCMCaBwmDEqEkIAAhCAAAQgAAEIQAACEIAABCAAgcVJoLWXQ8OtG+SbTosr
ZQssRQwhBCAAAQhAYHICKBwmZ8MVCEAAAhCAAAQgAAEIQAACEIAABCCwZAhI6ZAtoOQ6Bz/WBg5h
4ZA2c1gyJKgoBCAAAQgcLQEUDkdLjvsgAAEIQAACEIAABCAAAQhAAAIQgMAiIpC2hS5IyzC2aXTN
926QZ/+GRfRBUxUIQAACc0gAhcMcwiVrCEAAAhCAAAQgAAEIQAACEIAABCCwoAgky4Zsxwb9dVVD
+pfFLKiaICwEIAABCHSAQLkDZVIkBCAAAQhAAAIQgAAEIAABCEAAAhCAQBcSKPj+DfLhim7d4OYN
cUoIAQhAAAIQmJIAFg5T4uEiBCAAAQhAAAIQgAAEIAABCEAAAhBYIgSkVwgLh6aOQZYNWDcskc+f
akIAAhCYBQIoHGYBIllAAAIQgAAEIAABCEAAAhCAAAQgAIGFTCDbJLrRrm8wK/riGO5bm0cv5Eoi
OwQgAAEIzDkBFA5zjpgCIAABCEAAAhCAAAQgAAEIQAACEIBA9xOQ0iFWUMqOC8m6Ie3lwLJK3f8B
IiEEIACBLiCAwqELPgREgAAEIAABCEAAAhCAAAQgAAEIQAACXUFA+zc093BISyk1fG0l9yyr1BWf
DkJAAAIQ6HoCKBy6/iNCQAhAAAIQgAAEIAABCEAAAhCAAAQgMD8EtHVDc/uGrEC3bCgUx4aPtLQS
DgIQgAAEIDAZgbFfjMlSEA8BCEAAAhCAAAQgAAEIQAACEIAABCCwqAm09mho1NyiwX3TFUol38Nh
/PARSoegQwgBCEAAAu0EfOcfHAQgAAEIQAACEIAABCAAAQhAAAIQgMBSJiAlQqNYslrfKmuMDvsq
SiVr9CyzeqnXrOy+afeAsmEpPyXUHQIQgMD0BI5Y4aBNg7rJHekPHfLPzqd3pNyj1G7hj/zxiXQm
hH9nuEep8A8SnQnh3xnuUSr8g0RnQvh3hnuUCv8g0ZkQ/p3hHqXCP0h0Jlxq/Lul3xuf9nT8dT18
vXeFPfOCd1l99JDVRg5ZoVS23nVbXN8wYOVyT0oX9YswypmrcDr528udL7nay53sHPknIzM/8fCf
H86TlQL/ycjMT/yR8p8tqY5M4eCbBjUO7s42D+qQ4iED5esF9vS5ct1N+soKZ7h+oDY9asrfqR+g
kL9RyeQvpHDhyW/e2Ej8Sz0Lkv+Ryp+eFz0/Q3vS89/p58f6BjP+xcrM+Ov72k3y9zblL81M/ka9
uWnZob0d59/wWT2F5vPf8Od/Ri9vsU/8Oy9/+t729GfPT5qlNP3PSaMuk2qvw6F9Hecv+RtN+Qsz
lN+6TP5x75/p8bs1ezXjP7y/S/hn7/+Cdzhn5OpN+Q91h/yWf//MpAJdJn+jKX9B78+ZuNpo8/k5
0BXPj/Uta/5+zbAJ2mXyN3oz+TX4MiNXG2nyP9gl/Jc3+fvSGDNxXSZ/oy+Tv+Czb2fkqsMZ/5Gh
7uDfvyLjrz7MTNxCll9tz/z317ea7Wj7Wcz7Vzb5z6DvJfnrzffnIX9/LkD5G/nvbzfIP7Aq4z+T
Zz89P7n35wKUv+GD9Wo/FxQuEPnH+jVFt3BYZlXvazbqBV9Jyc/d2sFb4WYHdlmj7FYP1WwcpqGl
lubSaazHv7+FI3x+GqPZe7/gcneWv7979P4ZaL5/ZsJKz39Tflug8jdGsnZPyD+Tas9FmtReSO//
5u/vTAoR/6b8svLR89Mpd9TyjzbbnSMdll/tZfFvtt9mxDHxb/ZbRv13oKP8m/L3N9vPM6lAN8mf
xtvEv9n/mon8s5hm2t5SNAzrGvDzwfrSdz/h4S6rV30AoRMfvNqHlX5rbLnQX9qrrbH5fD/vSz+C
E3EZJ//Qbive+DdJfm9BuvgdeHFI/p4BK5xwcZK/vumFyTRRP+ITuXHyO/fidz6Wyd8B0ZN8Tfnr
J1yS5LdN585I/oY6HC5/4aaPd1z+RsUHy055Ufb8bDzbCpXeSQeNxV++qA6HnvvvfNwK/hx14tEf
x/+UK5L8hY1nJv5jjcPxT1F6flSHmjd0E///40qTLpD/tJdm8q8/dUby26j/4Lj89t2/6wr5G6e/
LHt+1p08A/ldUauBVvG/5ZNNpdX4z2nezvT99cHK2mkvT/IX159kNoXSJHt+pGhwRYn43/Lpjsvf
6Bm0wlmvSvLXV28xDXpP9fxLWVI45IpCl79xy2f8WEqfeSM+vqDE303Sz3pN9vyvPs75V6aUPylL
Dj6X8b/tc9ln0WH57QWvy57/FcdOK7+UJYUDOzP+t3/eCsNSWo3HMm9n4u+N3frZmfyFVS5/sTwN
/6o19m5L8hfu+kJT6TZvEo8vqCm/nfujGf/l62cm/55nMvnv/mLH5W/0emP9vDdl8g+uTTMmp/r+
arCyseeppvzXmCWl23gs83aW+Htn9fw3Z/IPrHH+pamfH8m/64lM/nu/0hXy1y/4sSR/oX/VtPI3
qt7Je25rkt9+8DUrjPhvcSe/vxosvvDHM/59/lloAGqSSUfp98sHW+vbH03yFx/4uvPvvPz1C9+e
8W92/KaSvyFlw/aHM/4PXOf8NXgwb0/8+IL8+W/0Of9L35nxL/c7/mn4u/yN7Q9mz/8D32wO3ozP
dt7O9P31Z77elL/g8vvDM/XzI/mfvS+T/6Fvd1z+hr6zl78n4++DwHp2pnx+NDi87d4kf/3BG3zQ
u7PPj/rt9csy+UNhPpn8adxBz/9Td2X8H7u54/yT/C96X/b91eCZu+nkLzx1R5LfHvte5+RP70j/
Ajj/2ot+Kn0PYtyhXf6Ir1T8+XL+5T1PexvO289P3GmF2rD1eHy5VLRyf4+V9P3345RHUV+wuXKu
7Cj7kJXkv+TdHq5qjfu0yx8SpOfHlTyFJ27N+D/uYRq8jxTzF2qiWrHHl6Fy+asXvTMpTYLzVPI3
XElefOL7Sf7G47f75yHl1fzJ3SpJz7qPlaTn/5KfTErbkDvCVtrmQcZ/yAqPfTeT/8k7nb+Ubh1w
kl8TBfX+uegdRyS/PfKd7Pl5+p7Oye/tzIaPHUr+xsUuv7d9gnuE7VQTf7UXHr4hk/+ZH5jpfdoJ
p+XYNFAv+S/w9ptPugi5I2wXqyW/fnc1/vDs/R2TX8vJFQa97ePy1877MSvMVH61Nx+6vim/t4Ok
/O+E0/Pjsif+6r/M4PmZbTH97T0zlzXcfdB177PW2L/DX3oj8/7O009Zw/8U/EvXOHhy1tHWrNsZ
uCS/lCT7nsnkdwWKD8PO4M7ZS9KS3wf8GpopL23TkcivWa57m/K76PMrvXN3FBl/n52+0QftNLtV
iqgZuOz58YGnbpDfZyfWDzp/b6ynWRrTyK96pxdfdTST3wfPCp3k7/I3NGiqgdYZKs3SDHX/zib+
nZZf2u0hl1/WMTNyDR9z9Rn2rt0u7n3aGgee6yx/DVg25fcmzIxcmqHuHb+Mf2flNw34jbgCxK3E
GnVvBk83KUkKK83w9oZKwTseDSlOOvn8i79mGvpgwYy/vxo0U8Nd759Oy+8NlUZTfl8hd/rnJykM
/bdXHSfxd4VhR/lL/mFvxLridibyq59b18wgv6eo31+fuNBZ+VeaOnEmxdVM3p/ir0a6N9wz/nu6
QH7nr4kLC1F+HyioN5+fmY1POP/m81PQ+9/fvR19fgYO+PPjneYebw/M5PvraVJ6/853g/zW7+9O
dfqlCPHnR+2bqV2b/G7l1lH+/j1M30f/TUrP/3QV0G+VBlml6HTFm9pOHZXfB7zS8yxF7NTg01XJ
WpOSx+UuSX6vR0flHxyyumZK9lTVhJ6Ra6jTre+tfn87/PyoHRAWF+n5TwOxk1cj9V2a/Bv++yuF
Z0f5+3e37n0R9b0mmac2rjJ6R9XThBf/3dL7s8PyZ+8eb0/qd1Xvn+n4ez2TktOf/8ZuVzz7Z9FR
/t4WyCxOJfs41BOfeB9fzGUdX3DFub4LHZHfhdXbXgqEkH9igbPYsc+lYWVXMkhRVTvofd/qkJUr
ZSt6fsXR5mSNkkC4n9kP+lTFTnpNJTTU59XYkyYwzqTto9w0xtJ8/k381Y7rQP9FvOpukZ2sLPy3
K71XJq1t7oKeH1mWa3UOye+/H52QX8+DBrwLajc0+Y89Izl52w8lv7/7G66wKib+/v7tgJNiXPuP
FPzdmfqzM3j3SEyNnRSdf1rdZfeTHVM4FFxhUtMgd+qLZ8//zPnvSeMmpfT8eNuvA07WGfWRVf78
+LOvOhwB/4K/O9O4j/irL9YBV5T8PnG3oNUSmt/fGfHX5PYDu33ceaePP+j72xn5NTFKk4ckf11t
zxnyn03U0yocNNCqF2NNA34asHnyjvSjmQafPH6+nV7aMqdurNrijcaaVbWmYLHHpImXa38AQv6q
lA3+o1N68vbspTfDxv5s10/yS7M0uvJE5+kyHetf/kJlhvIfsNITTfn1sMy2cDPIL+O/wmrrT/Mv
nTdkE//p5a/LFGpon2vqu0B+nyFXX3e6Pz/1bE3KQtnXosy+ChM+P/4dkAmpOkw9kl+N9g7y1wyt
mltmWM35b3C5ppPfvyf1Yed/wPk/fls26NdB+TVDq7rx3CS/rffvr5UO4x+NsfT99Rdk7ZA3Uvbv
bvL3Tmsn5ZeGe9P5/oPpVfCO97Ty+7umrlk1srBK/F1p20n5+13+LRcn+RurXX7XOLQ//+P4u/y1
IR+w2bfL+ev52dZZ+X1WcfWES/1t5R3R1SdMyV+/W2ocN4Z8wGPfc/7+6QL5fVZ3/aQrUuesNnK8
v/59pljb+yf4J/m9gVw/6B2OvTsy/vu3d57/KVc5f5/VtvxYnwBQslLTlD7en+Pk93d/svBRg2vr
rVY8sKOz8jv/2qkv9/emNyBXHOPPT3Fq+dVBGfIBg30uv54fn3DR0e/vsnU2eoZbyHi7obhsw/Ty
i783eG3Ps/7+Ef+dHZe/dubrXOHca/Vl3gAu+xt0iufHRvX8u/w+2aXk709Zy3SW/3obPXu7P/49
VvR36VTyq93ZcP4FWSh5uyG9/zst//INNrp3p8vfZwXfDNSHoCbln+Qf8bbDwR0u/5NWEX+vS0f5
J/mdZ7Hf5ywsT/K3zxSN909q9/tvtCZJmXdWy/78d17+jf576rP1fLZlo+oDIL7MwFTyq4Na8EkW
psFun6lblKVeJ9sP/s6sarahDz6VNADlsy6mlH/Y23j+2yX+xa23WNHbQZ2Wf/SAT3ipLHe5fQDQ
f8ni/eOHyR32/Oz177vL36MZ0h2X/1gf+PUJUz541vC2vwbSppI/KTt3b0vyVx4Xfx+86eTzs3KT
TzL39ozvDVDUrFHvE08nf6nJv+Tyy0K10/JXNWHE35362ZpOfvPn33a5haGeH3/+Oyq/Bp2cf1Xt
mV6fresuL3+03yLU97rko9v9oz7gOuztn133WtEVJorTWEDZFQ0a0nADh1Ze2dEc/E0F9Vhd8mvC
Qp+Pn7jLyx+lpgmCfpJ+v4Z9gF4Whs6/svX7Lv/+jjw/DZe/WPHJpk359dsrN538pjGWnU35/fmX
wrMjz7+/6Av+e5vkP+T8/flRv0Xyx/OSKuR/xvM/ZKVdjyf+DedfkPKtE86f/YJb57Xk71kxI/nN
2w/1nY8l+ctN/p0QX5u3l7zvIvlH/Pkv+PtzOv6j3nY2HzspyULVn38TfynPO+HcktxWbEzf35qe
H3+WZiJ/w7+/lZ1N+R+X/H5vJ5wmiC8/xseeN/v7x8dzXP6pxp0l4hj/7PnJ+HdG/obLX1x9vFlT
fn2XJ5N/rvBmo6wzyD0b+KtbRdNh3dd8kFD68jRqNYP7ZyuJOkf+U+cvNC/bfWoYeuNpOpdegJ6u
7lP0C+7VUPOb/bbp750u7yO5HvLHPXU1/GYqvw981xN3bzS05O6M/JJb/GbCX2kiXa1R1PBO18if
noEFyD94KlyQz096fpuyz4B/1Lfzz7/m1PtAZfPVkdjPQP66K7ek4Oo2+Wf6/Hcb/4Q8fQbZeyje
p5OF8b7qFv615u/XTJ+fzvPXsIz/9KffX72/m04fxEye/2Z9O8d/vPzxPBSnkV/c5aO90TXyz/D5
6Ur5G3p/Zs9NUfXQ8SQu5FeodFm7sxPth/HPT8gzidit6JA/nh+1faSg9ieqlWZ+Dsbkr3sbrMXf
mWZXJpYi5JclnH70xp7/zsmv398j5d9sbuSen87KH+2B5jjdxPA9Nvh32/OTvrLpKznD56f5Afic
fH/e1Iaa/Ds/KYzndWHs+U/tN+9LJQuBafIM/ukdld4/3SF/7Qjlj+9LN/DX+yfkUdg+WJn/SIJ/
vK/07HTT8zPdlgUhf3zPfa505+TXwHD6zvpMe32B9QxN4eJzUZuvIMsF95rlKwWXTjX+r0F0uchJ
aefGadzHfzlj/MllL0wjv+QI/iFTZ59/n6HuvMRMv6fal7Bd0RZyRhjy66lR67uTz4/G3YqudGho
pv0R8s9+JVT3bPxQ9ZpfJ34qO5M/jQcewfMT/OsuvybodUb+sn/Psu9BPD9TMQwZRVpV1bhnJ+XX
764/AM7On+MZPD8hv5oKPrfWa643f+eenyS/nh+XQ+9P9d0lY7wn2z+LkD/xb8rfSf6+JER6Tye5
XB6FU8nfXp/ZOJ9U4RCw9MWUH/FZTvV6yarHXW62ZrdVZZLtAqcv7mxIMl0ezR+2kmtUteFycfXJ
vp7Wait546Xk8mkmqD74eIG3yy9NU71RtuqJVybTtKpm3HdIftOGp6tOTPJrUZ9ik7Hkj4e3XX7x
b7j8oyf4zFif7SeTGKXpBH/tmVFY4fL77L6yvzxmIv+hUZfX3Byyyb+j8ov/ihOS/BV/ERf92dFz
MxX/0RGfKd3otZEukb+w3OXvW20Vf3FMxV/fCy1HNOxWAg2fUTos+X2GU6f5F5b5zO7eyeWP18GY
/P5yLPXb8AmdlT9phLUO5LLjkvzlSfi3yz+iQZ7SYJP/XqvJJN7dfH9/Q/7GwCafIL3Kevydo0FX
yZF//kN+zRDS8zOqxkppwOX/oWTp01n5B63e7zPryytN8xOnkj89P1WXXz+25eXZ8+PmsZ2W3wZ8
Zn1lRfb9nYJ/9vzXXf6Ky78i498B+WMGq35/tQdIo3edW2gOtt4/8XsVv1/x/CT5vXM16rNb6j6j
Yvikl/iMm/nnP05+Xzd9OvmjPvpeaLBv1Gez13tWNvnvn/fnZ0x+n2Wjdd/93V8s9/kLRPsLZVao
Yh78x8nv76jR8oDV+9Y6f//+uqVnTRaf7ubr/TNefp8l57PLir4eS/x+JWFyf8bJL/7/P3tnAmBJ
Vd39U2/vdfYVZhgGhk1U3BUkqMSVuEQUYz5BzKZi1EhCjIp7XHA3iRrziXEhRMU17kvAD5G4EAWV
fR9wYGYYpqf3t1TVd/633nldr+a97tfdr/v16/nfmepbdesu5/7qVtWrc+6ibS3QNud+P2gPy47L
n12hH986slaNyCkv+v0QE9/9NkMdsKn4Utbe1GHvhuj5r/K7nk9IoOcXwx3EX5+FOq7KyR/OJL8+
Y4ta37A3iNpPp+XHlG76Lkrh41Wf7fBzufrpGY2946+ASzmdN1hnAvWO1N8P2juwo/yd/P0qt348
67vVqSBViRd3Jr97/mgTqVTld/dvx+XXtuDpN5hqAXLa/mEGtPZldYjLD2VBJbda+etvCP394OlI
ebt/F7P949mYwqKVWAMEIxuUvaD96GUw+ePPT9d28PxX+Uv67An7NSJ+/ywF+ZW/V9Fnj2s/zeWP
3r9azZ51quDMyMQ2ff92Wn6dUi8MdW2AUlkKOsUM3PT8PZmsyi+QX3UPHW0/mBJQWXo6ahwKeMg+
rfx6h0/2rnd1liNP6xh//XGgUyHpc1Ll91WXkFKdCL57p5Pf1UunXpWVh2uP3j4pY+06bT9F3Dvq
3ExK6tt94wIX4I+Tw8mv7WUa+a1oe/649q/fXn7fYfqc0hFlRz6pM+0nGgqj/FX3APkDbTOq0zH2
rn4mvPpJ+SsDmyXUEX1ypM5o0In2D/kx2qUqv06y5dqPyZ+8/nXy60LjxYHDVX79btiq3706JY6P
aWngFuv3j+Ov8ut01OAfqi4T7b8l+fHtu+IInc5rUGcq0JeBjjjsjPz6/sK7S+VXy0FL8rvvd5Xf
V31jqL/h9CO+c/Kj/bg1BPD81/Yfe/40az8Hy6/vb50WqCP8Ib+OLofeGc0X929Sbxg16qn71+md
NW64crvy19+govdwp+TXeyDdty6SH3rPBvInr4PVp11+U4NDsgD340s/PMJe/eGlH99lTHGCn5rV
F08yftuP9WUDl8EiRvojJaXzkGN4mt4+7uHsTk7zxz0AVf5yVX5/UodZd0h+UfkzVfnNUjaN6O6U
8Q+q8lf0xw7kXyyFAX6swGX1w86DwUHn706lC/qDAxZLfQjP4Ex+az8dl19/PKV0DnhI3pL8Gi9Q
6+ZS4C+qaMroUHYonPAx1MoIB7XDOuu246+Gh87y14UGYTTUNRz0Z3tL/F3PBFVa+mj/HZIfD+MQ
zx/90ZVWowOeQ2j6M7cfTYe0+rFb6cHzM69TMek0LYt8/8blT6nRzVP+rcmvdUSvDo1f6dEhnR2W
X8AfRkOVp6XnJ9ib/K79FDrLH1NR4BmqCtfpnj+1dqXyo2eW498h+fHDHO0HBgf37NfF48BU7wb3
5IesyR8rNfk1Bnqm474N0H70vbHY7T8uP9aeyOjifYEqC+zVNb38+oMd7Ufv9wD3rxo+OyK/sk7n
lLi+u9J49qhMeH7CtSS/XrOggOePyo+pfrTyi/X7wfGPyZ/StoAeQ2o+cW5W8quyuZPyQ/GSwbMH
9+Q08uMU6oU4Ae51ved91356ncIb52oNsJrPQnl1/PWjO41nv7Yf+13XrNwlL38zwavhkB+/kfDs
DPWdUdb2L+mJDvMfUP7acUqfp3oBpq2B46/yY+7vUH9z+Lh/l4T82p719/BMzrVxraOP+0XbfwjF
a1b568euc7gHFsFZ+8/k9fsF317a9qNeq9MXXms/+K2t721fFd+Sneyo/FiDK6Ps0XJmoldrP/qb
Kchrp0Eo7jssv+cWq1SF0/To3VknP37/6G+GQN/bYZ+2H1W4drT9qPy4b93oyBnqELUffQeoriLI
V6SiRn/JFLXDZtThaLGe/04xpjIHBTW0gb/+g2ytuhDrHqrxzcfvt6wqXKsdFuwaJn/7tZpvq/Eg
P5iHBf3drPLje7al716tI2rpa9sJ8trpFO9flX/R+buph1R/oMYba/+t8K+1H50+DR2/XPvJljon
f0G/e5U/nj6tyg/+AeRX4677ftdFcyvaAVWzWLTfP66jlD4zs9pZB/Ljd8+s2k9cflUYd0z+Xp1C
0smvV6CF+zdqPzH+2v4l1xn53RoOvfrsQfvRa9Fq+8Gojqn2o+/fDrUfjGwJ1NiDqazcSCvXfA/+
7tXgmkMd8ayqVNtP2Kvv3w7Jj5mJcv1rovZTfftCvoV+dtdg6M6sDA6+vvRHD3ucGmhKMjI65h6A
AXpOA2oLjT9ecKv7gGFA8KOxoC8cPDz6Blaq0kAVlpjDsoWy8bKsqKJseFMk//i49rLRB3gn5E+p
/AODOjpA5e9T+fHDZSZ+OA/+w4ed7PiPj+sCTh2Uf3DFaie/2swc/2byIxwbprKqqKJgycg/GMmP
9oMfTTPJjx7ekH+0Q/xxD1j7R/sZHFzj+Pfiw2mm9qNpfYxOSvXX+E9MLG77byY/pmibjr97Tqj8
FVVNVbSHgbWfzsmvCxWDf2/EHy8e+9Hd6JkWtf1Q5VcjbTqS39ePDdy/eCYt1vNnir8q69VoMqDr
IOD5A/4zPT/dC1OfnWXtITF82Cm6nknn5O/pgbK+Xv5m965dD8hf1mdnOefJyBKRv78wxd/kTPr2
3nP89YO1rL3qOid/1IuvpydqP4P6wxXtJwfFhz5/ki5+TdwQbO3RXtYRYtZ+cP8ubvuP5O/trbYf
/fCP2v/MP3whf0Xlrwjev1H7X2z5rSel8R/QHrcZXUAR/Kdz7vmD9q+jaSphQUYOf2Ld/RtiQb+Z
3h/TFTDDObTh6Nmjz0n9/WbyDxbWud6WprS09mJt3rJ18msdy3ld98fT3w9V+Y3/Ystfaz/51Tr/
ab7GPym3yQ8fiv1JHR1T0d5No4dF/Cd0TRy0f2Nv9Y+na8d+kr/J359bKVk1+pjBsFlZjr++4cr6
vMLvh5ElIv/gLOR3/HU0ZcXrq8k/qR2mOsl/UH8LZPU3QVbvvUbPz/j1wDD8SX1eVVIDMrxZFa+q
7OuE/FD64f7Fc3NQf4vp+BjJ6/3dyFm7xjnIX1JFcUVHVA5vhuIJ8uvCx4vc/uvkT6vSXnt5zyS/
a/8qf9HkP6yz8uP+Bf/+lPrayxXjeho9O+r4a0edyb4Nyn+V8h+o44/rE4+L43a6+PMH/E3+Qf2W
wuj4ZmVbOHx0Vij2b9J38BoZFh1dEGs/kNXitlNuy6u5/Ko4bvC7x9KZTPAD/cac6FP5s2tkRLR3
bEflr96/+ns+o/dfM2fvM/gw1pZWbNHORqr3yax18heLOq99Nb3VtVle8wmP809p+xnoV2O/tv8+
lb+VKZVQdqjG/onBw1VZv17G0uucscSeP+68XiPUYSFcM/n7VX48+2dyjq3KPzawVSpqMBxP6/o/
HWg/MJCDf39f9fmD0Z3TtB+rl2v/Tv4jnPxjmY1O/sVuPzX5q+1nQPm3bDDUtdLGdEaPSqEkY1ld
P0f5m/wL2fbB0NqPyT/Q3199/rcuP9r/+KqjpdJXktH84U7+aMaaqd+fdr3a7TeVH+2net9Nd++5
9qPPz/FVO5z8I/ktTu+82PJnMjoXDZ4/A/q7wb1/p5c/3i7Q2Whi7XGR3rxn26LJD/Zw8LM6sg1T
4cXlb6X9t7s9tGxwgNAAHsBS7+mwtop+qKvCG/PQxeG2W0Cl5ayRyDdUYLBwhyqHm5ZIFX+AaGCn
KxtxPE2HVerDlPbuU+VNp+TX7k1qZUc99CE+a/l1WJo+LDEkjPJPd8Wr5xq0n7nwx3WCojnU3o0d
4a/1sPbv5EePN/2QaLn9qPxIJxhSmNZpctB+cO8u1v27zOQXVTap5bMl/u75BP7afsA/VP7u/u0Q
f/f8rMrvnou4R6ZxTn4oNrW+nZdfRyWhHXe5/J7Kj8VCW+aPeR/0R89S4O/asSq79YE4i/afkF+V
PZ15/uh0aLgPW5DftXu9L9w1QtvH/Gl2/y6y/O7Zr8+QsKAje/C7R39AprQ9xGVsdAvjPN4R7t7F
cAKT357/Lfzob5Rvy2F4ttizPyY/2rK1f+Rl9UjmW5Nf25rrHmPyG/9Fl9/aj8LUe7KZ3FYPnHeb
LtjmZfUdjt8PaXTSqbb/Dsnvgf8s5Fcrrz5zl478rj3rO6lV/gfJr8ry+G+f6T567VrOyT+o/Vv7
0fas90Mr8kf3b8Tf3b8ZbT8dkD/Ac6RH56XC81Pfwfj2msmhfpAfSo9QF4dH7/zQya8jTmK/PReD
f7fLj989ofYwDpU/vkVcu5jhAhh/jAaVrF6vBH8kX4zvd/f+ismPb/GZ2j5kM/ndCCXKDySzc/Hn
zzz4Y1YGvem1/ei3C+5fT2eI0PsXbrHaD545gU7nGaDtt9h+nIBgoMZ1tbDrKDGVPfb86R75o/s3
7NT9q7wj/jpSZC78q+2nxn+x24/Jr6PU2in/grZ9NE67f03+ubb/Gv/q/ZvSGVJi7193nyzEn4T8
IaaznWX7we8MjC53aygU9P6F3nmx5VeZ0f4x0mtO8mNEtz5/ZBHlhznT/UbQaxCo7DD4z0X+djYL
pdjY2Y8BCIx9W028Xy1s6FmPucBh4bZeKo1zaU+oyQIfc7VCJtdTTgFCLpPR4qFU27dzkBf7Jj/y
6Wb5jf+CP/ASLI0jeqqA51z5d1r+vj6dUknlx01obcTaTCvtp1PyW/s3/s3kRx3grG523VDv+P27
2O0nLn9cdsjZyC1V+e35Y/LF2068HlZH1Bv7eOaAvz1/ljp/k9/aT/L52Sn5k/ybtR+T3/hD3qXA
3+S3dtNMfmtfS0X+fF571ui96kYaanuG/NiS8lu97Ly1Hzx/cA8gH/vtgGuykM5kgYztkt/uX8jd
CflRD7Rt42t1NI7xcOwjPt7V9pun2+W39rNY/MEw3n6MP8KSbR8yGX/bx/2C547x76T8aDd2/9rv
esgZdya/1XupyW/8W5Ufz1vwx72Ka4D6wIdbjPvXOJrcM/GHXHYN0L6M/1KR3+phzyDIG3cmu9Xb
+CPOUuDfqvx2by8V+a3d2O8B4w/OcWfHJr+1d2s/qE8n2v9s5bf6mfzWfrpNfms/uC7W/u25Y378
+rVz3+5BtAVr9622H+OflD9aUzL63baY8s+2/Zh+wuS39oN8TG7z28k8nhf4g+Nc+ON3M9Ka/J1q
Pyb/bPk3kx9z2xt38+PM2rkf52/ym1zWvhEn7uzY4iX5W/tHvG6QH/e9/VbC86fb5Md1w+833ENL
QX6wRNtp1n4gJ9qFtZ9OyG9tEz7kgG/Pf5MfciIc22K4pgaHZOEQDM4AowK48IC60DccyjUwKB/7
Bgzn4GYClpQfsnez/KYw6BR/u9ki+rPn30n5rQ1ZW55L++mU/Nbu0Z5nKz/aCtIjbbztL+b9G5cf
cmCb6d7F9UE8ym932+x940z+3dX+7d7o1vYP+SG7yZ/83bDY76/Ztv9G8pviErLjOboYbq73L+Vb
Fl9EAABAAElEQVSf/9UBQ9vQfq09m49zzVwz/oi/WO3HZIeflL+Z3BZO+Y3E3H3yr3/+4/kJx/bf
Wpuy9oPnjf1+t2+Y6XJAOjj4iA+H+x/8EbbY/OcqP+RGvSE3fLxzu1F+yNyV8uO7MSjpIus6sa36
bt20rI7Q0+uC9XEW2oEbtvm2nzh/5LWY7R/lLQf57blj/nTXHrzNod0vBf4mt/kmXyN/OvlxDu0H
20I7lGXtx+Q2f6aykRYb+CMPPEPjz0/KPxPB6P3Zrfzt+s9V/pnpzC6GTkM4/R1jp7FaOPaTPipk
cWZXdOuxrQz4uNHg4OPYHmQACoewuDPZknLbseUdT9PufSsDvslvcls9KH+7qU/l1w7+ZpHHAzt+
H1jeU6W1f8/KaNR+rB3hHJz5JoW1f8pvRGbvHwr87fmTpNMt7aeZ/KYQtuf9Urh/7T6GDwUAXLfJ
b88d+N0kv8lt713Kv7i/3+bLP3kf27PZNcIF+mNlwJ+r/Mn3rz2HLO8FEt1la2XMVf747x3wh1sq
8tvzE3Vr5PD870b57b0Ln/I3urKth03X/pu1n+XC39q/3a9L5f6156i9f5P3r/Gn/K2382YxG7X/
Vvm7921J1xu6439EytV1b3R6rsq643RqkYJOsaRTBOoaUcnr10yWuYTPR35r93EfMtix5T0XuVpN
Y2XAj3O3Y+SD/biz9m9yJn27L+JpFmq/nfLb7zfUz+q4UHJbvnH58bzHcfL3f6v8Kb9Rbd2P80dH
XRzjexf+TM//ZLvvNP9ulR9XC7yt/c/Ev/WrO7uYLY9wgLBwuFHjD4r4/uyKnl1sK99AITXCLHym
3CzeUpHfZDe5KP9MBOZ33jhb+yH/iGen7l/yJ//Z3NHL7f6151CrDKz+S+391W3y24eGPX8o/8L3
0ALjePs19hbWyjWwuNb+7Xix319zbT+4301W+N0kP2Q1efGBSPlbabH1cYzfXNoP+deznMsR+Uff
77x/59J65vf+6vr7N9QRMSN7RIojWMVB58DXhafXbtd1HHRaaigOW1gLaG7Up1LN9f419lDQw3Vb
+28mPxSxi+nazd+ux2LVwTjadxf8VpylM3mt/dhxK3m0I47J0e3yx+vRCheLb7w7zd/k6bb2Y+1m
tvK3co1mE2fGEQ6WmX0s2YVPhtvxQvkAFXfJC548H4+LfcqfJDK74yRf8o/4WbuaHc3Zx27GPxne
LGeTc6ndv5R/cRV+1j7s/iV/8rc2MZ2fbCdsPxEte65Ox64d58g/uk/5/ppba2L7YfuZW8uJUrH9
dGf7Sb6fuu35Sfnnc9dOpZ3t/WvtBHO9y4Fdkv/K3zhfAlV0962V4h9eILJis3irj1AtfrSuJkpL
ljMlwfz2kvm2+vuT7Wd+3C01+Uck7L4wLsn2ZeHt9smf/OfSppLtxvJo9flp8dvltzzCwQpsVgE7
v1B+u8ptVz6zrWe7ym1XPpR/tgSi+OTfWW7kT/5zI8D7dylw4/07t6vQLm7tyme2tWhXue3Kh/LP
lkAUn/w7y438yX9uBHj/LgVu3XT/QpnqFKqYlm5iSDxsoa59mdb5+HU9B2d80H6gqJPVy/z5sG6U
tl35tiufRjJOF9auctuVz3SyNjrXrnLblU8jGacLa1e57cpnOlkbnWtXue3Kp5GM04W1q9x25TOd
rI3OtavcduXTSMZGYYtdXiMZ4mEtGxxMcPPjmXTDvsltfjfIHJfR5DY/fq4b9k1u87tB5riMJrf5
8XPdsG9ym98NMsdlNLnNj5/rhn2T2/xukDkuo8ltfvxcN+yb3OZ3g8xxGU1u8+PnumHf5Da/G2SO
y2hymx8/1w37Jrf53SBzXEaT2/z4uW7YN7nN7waZ4zKa3ObHz3XDvsltfjfIHJfR5DY/fq4b9k1u
87tB5riMJrf58XNLeT8pb/J4KcsO2ZLyJo8pf3sJWI9t9OTGPtYe0j9SUEMDjA1wuAYlrOWjW1bj
aMTaGmTWc7a9Us09t2R7SR7PPefFSZmUN3m8OFLMvZSkvMnjuee8OCmT8iaPF0eKuZeSlDd5PPec
FydlUt7k8eJIMfdSkvImj+eec3embG0is+6sG6UmARIgARIgARIgARIgARIgARIgARIgARKYgQAM
DjA8mPHBoodBNL0Yzsf37Tx9EiABEiABEkgSaHmEQzIhj0mABEiABEiABEiABEiABEiABEiABEiA
BLqbABYlxmYjHGzkg9WqoudC3TIwOuhGRwIkQAIkQALTEaDBYTo6PEcCJEACJEACJEACJEACJEAC
JEACJEACy5RA3IAAo4OnoxziDuYFjGzAFqixwaPBIY6H+yRAAiRAAg0I0ODQAAqDSIAESIAESIAE
SIAESIAESIAESIAESGC5E7B5xmF48Hxdw6FSOmgUg+/rGg+6YbqlpEFiufNh/UiABEiABGZPgGs4
zJ4ZU5AACZAACZAACZAACZAACZAACZAACZBA1xOIj3AIMbqhwQgGN8qh62vKCpAACZAACSwWAY5w
WCzSLIcESIAESIAESIAESIAESIAESIAESIAEliABT2Xyw4pOmaRbQr7QSwk2OhIgARIgARJohQDf
GK1QYhwSIAESIAESIAESIAESIAESIAESIAESWM4EMLqhwQgH8dQEgY2OBEiABEiABFogwBEOLUBi
FBIgARIgARIgARIgARIgARIgARIgARJYjgQwrRLWZ8hU7Qp10yxphd06D2pwwNRKdCRAAiRAAiQw
EwGOcJiJEM+TAAmQAAmQAAmQAAmQAAmQAAmQAAmQwLIncPBqDTA2WKgtML3sMbCCJEACJEAC8yLA
EQ7zwsfEJEACJEACJEACJEACJEACJEACJEACJNDdBDBhkl/xxcOWrIqX1mEOutGRAAmQAAmQQAsE
OMKhBUiMQgIkQAIkQAIkQAIkQAIkQAIkQAIkQALLlgCsDLaGQ9zigGUdcAoVd3+wQ0cCJEACJEAC
zQlwhENzNjxDAiRAAiRAAiRAAiRAAiRAAiRAAiRAAocEgbQX6noN9VYFHKXSKQl1w8LRnFbpkGgK
rCQJkAAJzIsARzjMCx8TkwAJkAAJkAAJkAAJkAAJkAAJkAAJkEB3E8BC0RjYEA10qDc6RKHxYQ/d
XVdKTwIkQAIksLAEOMJhYfkydxIgARIgARIgARIgARIgARIgARIgARJYcgRgZLAN0ylVAl2/AVtM
UoxoCDQE5giOboiB4S4JkAAJkEBTAhzh0BQNT5AACZAACZAACZAACZAACZAACZAACZDAoUHARjgc
VFs1OmA6JToSIAESIAESaIUADQ6tUGIcEiABEiABEiABEiABEiABEiABEiABEljGBLxQRzfodpAL
1diAjY4ESIAESIAEWiDAKZVagMQoJEACJEACJEACJEACJEACJEACJEACJLBcCTRbwwGrObiplHSE
Q3Jlh+XKgvUiARIgARKYHwEaHObHj6lJgARIgARIgARIgARIgARIgARIgARIYFkScGs4eCkd4JCS
VCrFdRyW5VVmpUiABEigvQRocGgvT+ZGAiRAAiRAAiRAAiRAAiRAAiRAAiRAAl1FAEs0YJQDFo9O
Ltegy0VrXTilUlddUApLAiRAAh0kwDUcOgifRZMACZAACZAACZAACZAACZAACZAACZBAJwnA0OCm
VPJ1DQfdki7UkQ3Y6EiABEiABEigFQIc4dAKJcYhARIgARIgARIgARIgARIgARIgARIggWVNAKs0
1K/UgEEPtTUc6k8taxKsHAmQAAmQwNwJ0EQ9d3ZMSQIkQAIkQAIkQAIkQAIkQAIkQAIkQAJdT8CN
cNBZk2pTK8VrpOs3CLaqgwHCGSEsgD4JkAAJkAAJxAhwhEMMBndJgARIgARIgARIgARIgARIgARI
gARI4FAjgBUaams4xCrvFo3GOd1oZIiB4S4JkAAJkEBTAlMm6qZReIIESIAESIAESIAESIAESIAE
SIAESIAESGBZEwh0/QZsBzmojlLO4ECjw0FwGEACJEACJJAgwBEOCSA8JAESIAESIAESIAESIAES
IAESIAESIIFDjYCNcIjXO75sQ3w/Hof7JEACJEACJBAnQINDnAb3SYAESIAESIAESIAESIAESIAE
SIAESOAQIgBDA7aUF+oohoPNCqGXEWx0JEACJEACJNAKAb4xWqHEOCRAAiRAAiRAAiRAAiRAAiRA
AiRAAiSwbAnEDQ3x/eraDVhNmo4ESIAESIAEWiBAg0MLkBiFBEiABEiABEiABEiABEiABEiABEiA
BJYtAbUxBL4vnm5uhehYRQPdrzdBxE5ylwRIgARIgAQSBLhodAIID0mABEiABEiABEiABEiABEiA
BEiABEjgkCKgAxgwhsGNY4gNZogvEh3fP6TYsLIkQAIkQAKzIsARDrPCxcgkQAIkQAIkQAIkQAIk
QAIkQAIkQAIksPwIeEEg2GrO0z6qujlDg06pBJ9Ghxod7pAACZAACTQhQINDEzAMJgESIAESIAES
IAESIAESIAESIAESIIFDgoDOmRSmsyKZvJTzq8UPU5JKpcTvWa0LRleNDlUQNDocEi2ClSQBEiCB
OROgwWHO6JiQBEiABEiABEiABEiABEiABEiABEiABLqbAAwLYTYvlcFNUsmvlP2PfY2ElZKkdERD
SsN7+tZIOp2uVTIMQ450qNHgDgmQAAmQQJIADQ5JIjwmARIgARIgARIgARIgARIgARIgARIggUOE
gJsqSY0OXjqnIxxE/P51uoB0RVKhJ+mMBqQzbrSD4eAIByNBnwRIgARIoBEBGhwaUWEYCZAACZAA
CZAACZAACZAACZAACZAACSxjAmY4gI9RDplcTo0Oaan4qyXAeg6pKDyXL0hGDQ8Y5YB4dCRAAiRA
AiQwHQEaHKajw3MkQAIkQAIkQAIkQAIkQAIkQAIkQAIksEwJmNEB1YNRAS6dzbrFo80QASMDDQ0O
Df+QAAmQAAm0QIAGhxYgMQoJkAAJkAAJkAAJkAAJkAAJkAAJkAAJLEcCMDRgXQZsGNlgxzA4YMvn
89EICI1nYcuRA+tEAiRAAiTQHgI0OLSHI3MhARIgARIgARIgARIgARIgARIgARIgga4lgFEMMCjY
AtFmXLBwHNORAAmQAAmQwEwEaHCYiRDPkwAJkAAJkAAJkAAJkAAJkAAJkAAJkMAyI2AGhOR0SWZw
sOrascW3cPokQAIkQAIk0IgADQ6NqDCMBEiABEiABEiABEiABEiABEiABEiABA4hAmZQSBogLPwQ
QsGqkgAJkAAJzIOAp3P0hfNIz6QkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQALLhEBSTUSDwzK5sKwG
CZAACSwSgdQilcNiSIAESIAESIAESIAESIAESIAESIAESIAESIAESIAESIAEljEBTqm0jC8uq0YC
JEACJEACJEACJEACJEACJEACJEACsyHAEQ2zocW4JEACJEACSQI0OCSJ8JgESIAESIAESIAESIAE
SIAESIAESIAEDjECoV8RwazbQcn5nqeTYnieSKYQ+YcYD1aXBEiABEhgbgRocJgbN6YiARIgARIg
ARIgARIgARIgARIgARIgga4n4NZsCHzxJvaLlMYlvO8GEb8sYSYvkuuVcMujRLIFSS4m3fUVZwVI
gARIgAQWhAANDguClZmSAAmQAAmQAAmQAAmQAAmQAAmQAAmQQLcQCCUsTYpMjokM3ydSnpQw2ydS
GNARDzrygY4ESIAESIAEWiRAg0OLoBiNBEiABEiABEiABEiABEiABEiABEiABJYLATeyQSvj+74a
GIoS7rtL5MAuyfz8P9TwMCypvtUiKzZLcctjRFJ5yWazruoc6bBcWgDrQQIkQAILQ4AGh4XhylxJ
gARIgARIgARIgARIgARIgARIgARIYMkTcIaHMJCwoms3qOHBmzwg4fiQSDorYX5EAl3bwdO1HRCP
C0ov+ctJAUmABEig4wRocOj4JaAAJEACJEACJEACJEACJEACJEACJEACJLC4BGyEQxDA2OCLXyyK
6JYNdOFodb56WEO6XC6Lp1s6nXYGBzM6mL+4UrM0EiABEiCBpU4gtdQFpHwkQAIkQAIkQAIkQAIk
QAIkQAIkQAIkQALtJ2BGBx2/ICGmVoLxQf+ZMaF2vjrCof0SMEcSIAESIIHlRoAGh+V2RVkfEiAB
EiABEiABEiABEiABEiABEiABEpiBAIwJ2DCCoVwq6TbpNgxrQLivIx2wTU5O6sCHotoiArfNkC1P
kwAJkAAJHOIEOKXSId4AWH0SIAESIAESIAESIAESIAESIAESIAESCNWggBEOcBjhgImVAjU8JEc7
uAj8QwIkQAIkQAJNCNDg0AQMg0mABEiABEiABEiABEiABEiABEiABEhguRPAyAUf0ykJjA06pRJG
OOheyktJqJszOlRHPeAcHQmQAAmQAAlMR4BTKk1Hh+dIgARIgARIgARIgARIgARIgARIgARIYJkS
iBsQ3OLRZlBQuwJMC27TaZXi8ZYpClaLBEiABEigTQQ4wqFNIJkNCZAACZAACZAACZAACZAACZAA
CZAACXQLgYOMCIGvC0dXIvE99VL6Rzc33sEMEd1SOcpJAiRAAiTQMQIc4dAx9CyYBEiABEiABEiA
BEiABEiABEiABEiABDpHwIwOsC8EoU6npP+wj6ENNsLB7XRORJZMAiRAAiTQZQRocOiyC0ZxSYAE
SIAESIAESIAESIAESIAESIAESKDdBDwdxYCt5ry0rh6tGx0JkAAJkAAJzIIADQ6zgMWoJEACJEAC
JEACJEACJEACJEACJEACJLDcCNjIBoxucFMoeW6cQ1TN+P5yqzjrQwIkQAIk0HYCNDi0HSkzJAES
IAESIAESIAESIAESIAESIAESIIEuI6BTKgm2qsPe1JGF0icBEiABEiCB6QnQ4DA9H54lARIgARIg
ARIgARIgARIgARIgARIggWVPAGMaYuMaxNORDdjoSIAESIAESGA2BDKzicy4JEACJEACJEACJEAC
JEACJEACJEACJEACy4eAWzha127w/YqEupmJIdT1G7DR8LB8rjVrQgIkQAKLQYAjHBaDMssgARIg
ARIgARIgARIgARIgARIgARIggSVKAEYHG+GA/djS0XX7S1R8ikUCJEACJLCECHCEwxK6GBSFBEiA
BEiABEiABEiABEiABEiABEiABDpBIK3TJ6WqUyjB+JDyUjrCIVUb8dAJmVgmCZAACZBA9xGgwWEx
r5k/KuHOu0T2D2mpOZGBFeJtPkqkbzlehkmR++6WcO+BiPDAGvHWH7FAda2I7NklYbEskl+t5axa
zKvKskiABEiABEiABEiABEiABEiABEig+wnoyAbBBgfDA3axcR0HEKEjARIgARJokcBy1HS3WPXF
iebmQkRRv/iUBJ9+T4NCjxXvXd8Qb03WnXMLMvm6m24QtQuCXH1/9TkJ/u3tjaU95wpJnby1bQtP
ufJu/XcJPjjF1nvtdeId3+/K5wJXjS8DQ0mABEiABEiABEiABEiABEiABEjACGBEQyXQNRx0wz4M
DX7KcxvnVDJK9EmABEiABFohwDUcWqE03zi//VgTYwMyvlnC34+4EsL/fov4L98u/nm6vfavJRye
b8EdSI+6NjM2QJw77l8EoXSkAx0JkAAJkAAJkAAJkAAJkAAJkAAJkMAsCNiQBksC04MzP1gAfRIg
ARIgARKYkQANDjMimlsEt8iSDkUMgt0SXPyhRCY7JNx+ai0Mr3TfPyDhD/6jFiaT35Hgzn06mlEX
a7IhjVNnl9xeEASurv5BddWOEeseMSXvZEUqFe01Mc96WXrf98XXsuMu0PwjeYJ5lxPPl/skQAIk
QAIkQAIkQAIkQAIkQAIksNwI2Pd1Sr/TsZnzsH6D27y2zVJgedMnARIgARJYvgQ4pdICX9vwjv8W
T5czqLn8WVK68ELxexEyKZlh7Y2/uk9Swbik8om+A+mpF30t/VLeuefyRF1fJMU3vdHVNZ0uS+ru
OyS1aodaINpXL/fDKAjrZ6DS/GFw4HRKS7mxUDYSIAESIAESIAESIAESIAESIIGlQkC7OtZEifbr
jznOoYaHOyRAAiRAAjMQoMFhBkCzPQ0FOBx63mPfLx6QaHWGKKfyM14sB4JREf0PhXi+t0e8YlFS
OjdiTtc6zuyJ4uFvkM0KeusjXjodLeqw1JToUOzDlctlCUeGEnX9ExkOx0T0P+RPrT9SCoWMpJRN
KoWeElP1cpnM4g/KBV83WqLi1xkcgkpJAi0D+aMcuKXGbRZVZVQSIAESIAESIAESIAESIAESIAES
WHACnn5jY4ucpyaIlNsSXSMXXA4WQAIkQAIk0N0EaHBYoOvnet7rizrcE7MgaFl+X8Ep56GAhxIc
CvNIKZ6W4l9cJZW7d6oBQsNWb5dwU07StZf9AgnahmzNyCJDibr297j6oZ6m8DcubSjWZeEMDzrC
Ie7CqrEHZaI8Kzseh/skQAIkQAIkQAIkQAIkQAIkQAIkQAIRgfgIBrdyQyxAP63pSIAESIAESKBl
AjQ4tIyqtYimUIciHFv57uskV0u6WiYyvoyPj0sul6spwmFwwAgBz9PLsWG7i53J6EgAHfmQz+ed
QcKU+ktNeW4jDUqlkqRuvy42wmG1TGpdJyYmXD0LhYIb5QADC4wtSIe6zHYEgnHACBLHFyMrNM+e
GmM16hQnpazyuFEV1ZEUxs38WHTukgAJkAAJkAAJkAAJkAAJkAAJkMAhTyAIfZ0CWbeqC3SEAzZz
+J7mN7XRoE8CJEACJNCMwNIyOBR1nqGirmmQVvWxjgSYk/N1wYSxiWpSncwI+aTbVE2TD2r1vn7N
t7mEUIxDIR6gLjW3TYordUgiRj4ket4nw5A27pLx4+dEFew6lECDtJ6q2J9Orrp0bTow2f20W5ii
mus2mdS6oh5mVJixOFy7Sb12+H2TrjKeIZFj7CdZtbBYdLyd5PUa5efQ3mrtAfLOo83OUEeeJgES
IAESIAESIAESIAESIAESIIEFJ6B6ClVWuGLw1wwMbn/BC2cBJEACJEACy4VAmzTxc8cR7v6thD/4
koTX/AfWUI65DSJH/5F4T3+ReA89anorur9fgp98WcLLvyqy++ZYHtXdDc8U7wlnivfkJ4tXaDwW
EEpzue8HElz0NlXaa7rBF0jq9eerIrki4S8ulfCr/yoytLs+75PeIN5Z54q3egojFODhjV+UzBe/
Ium+Xinc9bNYml/J+s9dKGtVl+6lYK1QWdADX/fcK33qjxo0HiNj55wtYSEyTjj5EK/68pexnRJ+
/xIJr7w4wU0jbThNFejqx11xTLwz3i+pxx0RD53zvskRXP8FSV32dSn05iV99//E8vuVrPvMG2Vt
Pqqnpwp+/9S3S/AHO5wBovbDZefPJbz62yLX/uhgvlJtA2e8TFInbI7lHXGADNFIBweudj7UUQ9m
6DA/OlmR4OfaTr79uYPbSeFYkUefI95zXiDeYKZpewsnd2l7/U8Jf/rlg+VFHk/4C/Ge+RxJrdCL
TEcCJEACJEACJEACJEACJEACJEACS5wAvq2xYSzD1HiGKYPDEhef4pEACZAACSwxAlOa8g4IFv7o
3RJc9qkmJaty/7aLJcS24XxJvfWvxWs0ouDOb4n/3tc0yaMavPu7En4d27Hi/d2lktqhqzM3ckM7
VXmv5cLwMXSHhPtuF/nU0yTU4Ibu2vdIeO2nRV7/A/GO1BEP6tyL+jdfk9Tea8Xbe3Cq1NCv6l7g
B8ewkL2SLp1d61Fgoc6/9asSfPCCuqC6g93/r+7QDsIHbeSHhczPR13ld1/Xev6q4aCK9IFf1xWQ
un9ISjYEc/h68T7yfF3joi5K4qDaBj56sfhPvFjSZz/ZnXfl6p5jXf1hFE+oP5Vq56bC90r4gedq
e0oYjSzCpBqqrnqThFf9QOSjn1bDlJ2I+Td+QYKPvDEWkNhFHldcIKFuwcuvktQj640kidg8JAES
IAESIAESIAESIAESIAESIIElQQDf1zA2uA6Ruu+hXx8Wb8BW38dvSchLIUiABEiABJYugUU3OJiy
OPihKsy/oiMSWnG7PyTB5c8Q7/TttZ7nLp9bPy/hh97eSg7VODer0vlR4r/u15I6drAuHXrCSyo+
NY8aKN7y3bo4jQ92S3jRqyX8sI400FEFLp9wpHHUWYUO6ExQB/eSDx74iUgjY8OKR+p0VL86eLRD
vMz9I5F8Gubt/6WEl3xLwv5GmvV4ogb7pf0im8+U8IzHaH4jDY0NDVKJp4s7Y3olN7rh++8SmdbY
kMjhqj8X//irxXvk+roTZnSoC8Qok6ohwnz/czp6IWlsKOyIRoIcuDWWfFSCks7plIv6ddj8lMH1
/ybyzxfF4lV3VxyjO0MiB+orE37yieK/8mpJPVxHaaizfNwB/5AACZAACZAACZAACZAACZAACZBA
hwg4fYqWbd/LEAOGhiDUqZp1wz6+YYPqZt/xiEdHAiRAAiRAAjMRWHSDgxPowSsONjYMvkjKL3uF
+IetEBl/QNI3/VgyX3+3eDbN0n3aQz08ckpxW/xdA2PDI8V/0flSOeFYCXrS4g3fJ5lff0My31Zl
cdx9+P0i//rOeIh70SIAL9ZGLnzi+6Vy2hMkSD0o6Sv+RTLoCV9zV2rv+NslePKRLsR/xj9JcfOt
Usl6kv7eq6X/AYu4Ukae/g8yUUhJoadHp1VKuYWNUWqgxo7sFW+W/M5aZEsU83V6p8teXy/jsW+V
0tnPE1/rqws5SOqGL0nu4vfWxQn+8msSDqiif8NRklJFPJy3Ww0ON/yH25/Tn2tXSvisR0vl6R8R
f9vdMumXJfffr5Xemt59pQw/9QKprOh1dcxlCuId8ZCacQJi1Five5FUnvV88Xds1+umVhudfil1
//WS/bxOpRQfJfKNb4g88i9r1wpy2w+lZnVwP6Amfyfe1bfEopwqlde+QypHrI3CikOSueW/Jf2f
b9P2psaiKqNaAm1rBxkbjnujVF50ptYvWhLcG7pVspe8QlJ31ACIfOJfDmpntTy5QwIkQAIkQAIk
QAIkQAIkQAIkQAJLhYAaF5yhAfJgVINztZDqMT0SIAESIAESmJnAohkcTDGMOfflq++bUjZDxs2v
lf2v+BOpqKLXmyzqSIMBkROeLakT/1D6vqNK+Kt/KuHWjeLrwsjpNBTrann/3gdrymsXIGfK2NtU
mZ9SpXyoC09P6JZdJd7jVGm9dYus/sSbo2ju76W65sNfSXjyZncE2ZxcFR/LQSfcUTL58k/J2OE9
VeX2OpGnvV3y6bIM/D81nJi78kpdo2CLlLB+QGaDjB7TJ2Xdl60nqcHh2mqsLTJ8xHEy2pOR3t5e
19vfFlSGDIWt25saHHA+mLhOUtfFpgTK/7kMveSZUgkmJRip9uo/7AxJv2ivrPuijriouvDOkkw8
7RgtT+unMqGnQkoXWo768Fus2fqBVDSvYnq9+MeukeHhYclve6QaHHSUhXNHaF2Pl/KqfslkMtLf
3x8ZHvT6o3z/yNMkd/tRUv6jc2XyyA1SKpUkVKOFjJYdZ2+FTn913udl1dvPnrrOe34g/vDLJOyt
74nRSHLHqzrSIfi9GgxirnLWm2RojY7sGB2thmYke4yuF/K2p0q+qIaZnLazirZF+5H1o4/XsQpP
+oDsP/OJ2vujpHnoBpfZJN7LLpOBi18gubvMSnKp+Ne+VuShq2rttpZnlIp/SYAESIAESIAESIAE
SIAESIAESKDzBFTnoFMYRJvuo6uiag7cFu13XkRKQAIkQAIk0B0EFs3gYDjCSZ3O6Jp4b/OHy9jZ
L5aSD0MBXmORgyI+DAsy+eyPSvmp45JbtcYpfd2URXKPpL73E4vq/IlX/I2Me6qs1ml7kI8zIOgZ
GCiCDU+R4Wf8jwx+7ztTaX74IwmfcLY7rimnVQlfb3DYLuN//RkZW5dWZbgaStRZvv6p50qvGhwi
84eeKA676YpqeeEFjfqUp+qE+Y7CciB+zq9NbRTVBx0IPD0Xj4v3/JRRIJqqqf585dnPlXJVqe6M
GyoGyqwc9RQpycUS9b3XvA8MOblxDsp/lBVsfLLI6VrbDGJBVvWmcaZ7d1HKahxY9wTxtWzIBSYH
13Xc1RXnbXPl6rHzTzxHyg9RWdWIFGDTcOQB35znbZOJxz5M+n/xGwtycWaStRZZd5BfaqJ+1Eig
rd7KQ1zIAzlSqaz4fXmdWUvTaPuL3B2S+ub3q/vwniJjzzlV6x7V2eRFHp6XkZHnvUZWf+TNNYOa
d821Epz4pFh67pIACZAACZAACZAACZAACZAACZDAEiOAj358bGOrKgCcmqC6D2nx3UtHAiRAAiRA
AjMRWHCDg1NEqxSmlK7c+YuaItwJd9izZZ+MSnlU5wqMORgK8DJDunQ6I2Gx6JTA2WxWF/69Assl
TLnVr5EHBielMlqvsJ6KoAMejjld+tTgUDMQ7PmxBMMvlrBPFf36QkUP+6BUlviKBpPPfJfcXxgX
cbPsRBp5q4/nDUjvSpEBnb7fueGfiP/gS6XcE8lQVHlhBMjWacdV+a6GlbIaHSYnddqgmlI7MhSk
SnEGvlRKRZUp7eI5A0xZleJamL3iSznPjSxA+ZALm3FepbaEnA4YcOfKEwJ5bHSIU47nj5Dw6Vtr
inco3F3cOnkP/kFhebi4WgdwQ5moT0YNNlMOslScIh9hyB/yoR4oH2xw7Lirgt/OI6+4S6dy0l8L
8MXHddL1FZAH0jdzMAQgjst31Q7X5oxb7tILJf3nb5EDq/KOCeKhXUE21M9kRHiw69d1bSJ4+HNk
f3lMKhMRLzM4mByZ/MOkR9ck79VlLpy75bc6MueJThbkF+dnaeiTAAmQAAmQAAmQAAmQAAmQAAmQ
QCcJ4Ps6rQoHqCmwj+9nDzNMJPQWnZSRZZMACZAACXQHgQU3OBgGvLCwBUH9GILJhx8nFeshb5Fj
vqUz3yl4dQqhuCuf+DApVhXm8fD4vp87Uib7RPrGLFQXB9ZyPYkQOEW9jo6Iu3I+45TpUBSjfDjb
D4K8jG89Xg0ON1aToH7opR+9nKuB03rIE/nBRYaCeHTNT5Xm8XoHpbhCXwcn7Noj4cbNLk5dPhN3
Sr5qbHA5qlymgLd6mG+Kfpy3suJSWL4Is33zLb7lFU830348bS29GijSE8PiFaNpn0IdfJHec0cs
q8iYo6K2pLiv5btymwCHjfgQuUbWXPwcGXzIa2T/yafL5Jopk4YVZmnDoX0W5Hxv7C4p7FSjF6b+
UueaBf5Ur6NkJiVdnWXJRchnHXu3zz8kQAIkQAIkQAIkQAIkQAIkQAIksBQJ6Detn+mVMNsvpZ41
4qkewc8Naoc/nfI6FXXdNF3AUhSfMpEACZAACSwdAotmcIBCG1vl3lvral/O5Vxvd/T8xssrp8fw
ofCFbz3OkQhhUJB7v99Zl8fkel3AuBrfpgyKx8e5Uikl45u3St+tllZfnuNF8fPR1DjIN9A1HOIu
LI2pIaDgerwjXzjUAQ499MtefJxFtKZBkNfpl7Q8yO1kcrHtT0rf07peQDZdqyfOIF6yZ7+Giq9l
YLohN7pB4wRqEOmxrNTP/fhi6T/hzTLWM9XjH3FXXX1J1YwSRfb7C07u+I8DMzRgZIK7LloO5LD6
WTGWxq6PXQ/jYbLhOJWyMQRIrbM96o8ShGOzdJZfLd3EvdL3i+9J/vqfSObBu6zYJr5es0pZt4gt
5G3k4vXAyI4gWCvDL/kbOfySj9RFz17/T7Jet3DDc2Ti9BfLxHHbauftelSCch1z77aPyLrbatFm
3gkwoqWs131qpAoSGYeZM2AMEiABEiABEiABEiABEiABEiABEmg/AXyXYsP3eZDvl5Ftp+msApNS
3nyK6wCZ7dG1GHMF6c0PuG96i99+SZgjCZAACZDAciKwKAaHOsXwvnqDg84ZpIruHveCw0sOm73E
kj7AI6/Ug/V5eBV0KdeVhNVZHlYmFOiREj2t1noXpfpnVHupo+zplNdTCm2Ty/LFcW1uI5djNCJB
+967o7js8VK9ah1NgY9zyNPFj0eshutJd97VI3Os9sh/tKy9+ppqzKtl48fPl5Fn/pWMHLFZvOF7
ZO3/fEpW3HlzLKdjZd9DttSY2okwnJD07gckqwp5jKRIV9fQwBoYdU5/fMDBmIB/aTUeeLqfHtwk
lf58Ld9I/nqDg9XVrgnqbC6V0vUyfvBO6b3i2xbUgh8xDoKZpiaK6mDXChmXNj5T7vqTvBz2hYsS
63ToZdz9X9J7qW75Z0nxNRdKeV2PqxfSp278ZQtyTRNlNOKLvOLyTJOCp0iABEiABEiABEiABEiA
BEiABEhg0Qi473ntMBiq0SFI5cVXPQl0EX5Wv/kx/bB2nEQcOhIgARIgARJohUCdCr6VBLONA0U5
FK3oUY9e45Vi/bRAqXTBzZ/f09PjLOYY4WDK/fgLDWHIBz3WdcXeOjECfRkiHRTahUI0IgH7iI8e
/Ch3YkIV7HXvx16pZFS26ogFyJfMFwrzfD7veujDhzzIE/mNj49LBkaHmENezhChYbYmgJsEsRYn
JbmeXunrywjqa3Uyo0gaEybGHMrCtE/w3b7mXy4kDAJyowx893WigxwbusknXSATgznpU1nBpCbf
zi/IwL99omGa1gJfJiPvPk8qKhvyBZ9sJi5/SrJ6LbJaT4xwwHmUjX244Jt/L/krfnRQUVjM2l97
uOi4AAnToeSu+2JstIayd+1Ip5PSfMCksZu60HbNELe86TS57dWP1lEuV8nGn31eckMP1icvfkfy
779F0m/+mkwORAtZFzcerWx/Vovnb3upDG1dKVldWwJ5e15UZ6xXgSm1Al1nQ6+WGmXUcOarYeSk
Z0hJRzjklAUcrnWUbkrGWubcIQESIAESIAESIAESIAESIAESIIEFJoBvUjj4+E7Hhu/6XF71Mhmd
jNiL9Cn4jkc4Oh46X/ct7QKLyOxJgARIgAS6mMCCGxyMjSnMS1tP0in0f2fBqpTVKZL0JWcvLyiS
7aVXixTbQT7FrY+Tgat/WwvNjY7rC3JdTaFtL0zERb7wPW9CCrt21tJgyiIof/VkLCyxq8pky8vk
sql2mr1ko7KiYYmN4livf8iFvC0+9qvv/IQQ0QgIBIYjv5CNl//vQecbB6ySkSe9U+5/xGY35iLK
P5LLxa+bDqpxDtOG5ksRmyo/y38qjf5wAXutlF1fxHFu748k/6N6Y4P/pH+W4Sc9RvxUdF3GxjCd
lS+59M2y9VfXTmVb3QO3ubm8jO04Xe498VmSPXCTrLvyU1K4eaotidwmmU9/Q7zXnuGuja9DSOOu
vOkJsvthm6S3t7fWNnAe0yZBXhjE7JriGq9Y0SsZlRVhc5c5LgH3SYAESIAESIAESIAESIAESIAE
SKB9BPCtju/Vmt5DRzXAxQ0Nte/59hXLnEiABEiABJYpgQU3OJii1XrxVwrR1EfGs+eWWyVzwslu
hAJebtYT3l5m8fSm7A9hcY+5wq03Su6Uo93L0NJDyW1pkW9x5D7pGYolks06PFCVwNpjvpFhADE9
HTaI/EwuxIMMThHuRlTEe/RrXjBgVB2UzXBh3bAKNayoLMjPRnIYF4TVr4FQzajquZf/zT+uTtiE
wMfLnjNfLNl9v5Peu26SzAQWMe4Rf9Vmmdj6SNm3/Vgp6m+EvMoBWZA/fGyoR0UXgpqXW3M45lly
8iC/aKvPEb3/M/pDBWXieiKOcwfuqYsYPO4T8uCTH67Xy5eSTnMFJsa5fqHsaEQKzoMHnF3jugyr
ByjP2hFGnFieSIP9cPBY2fv8j0r+rq/Luv/8p6kZsh64SUL/GS5OuVi/rkd2zy4tc2O0LoPWCfnC
IT/IlXQmn/nJ8zwmARIgARIgARIgARIgARIgARIggU4QsO9l0xdABnzXYkYGOPumtrU28W1v4W6H
f0iABEiABEigAYEFNzigTChbzfnZeoODd9MPpE9OrSqsIwVxpLyOTTkzPqqa8+iFh7yC/nU6PkFf
fpbpzm9KYfI5UhmIRkrgpWll4oWI/fxN341NzaMJDztJJrU3fXzZZ8vOfK+qnLeXLHy8fKeOLWa9
j/PmVBVvu87HuaZbIm5dQj3I3H/HVFDvNhnaeIRkjjxODjx2SvFdKkUKe/S4R8lggc3KtAzCrWfK
yEXPd4pz1Mkp4JWTcbN45lseZjyAot3VU9PAufMJ+a1MnDPn0twyNUURwssnHOe4xhX22G8oS7U8
y6+Znyw7+cMIeaMMbMVtz5OxYy+V/psfiLIrTkpYUgOCp1NYbThGYEawGqRv/74MVB4hxarNKy6j
lYlMjJeFmR8VwL8kQAIkQAIkQAIkQAIkQAIkQAIksDQI4HsVzr73oR+AS37XukD+IQESIAESIIEZ
CJgedYZosz8NRWxcGWvHlfVPlLG+eH4/kVXf/ZnrgR/18p+axggLC6euuEhSf/8oyf7XDU7BjXyC
dY+XkRXxPG6Uwa98TzJVazvOIC9szg39XNZ/71vRfvXv2KmnSFCVMS5nXSRVoFs+ePHaVsu3PnKt
vtPlZ1Mq4cUd39wLvt42UZe7q3dmynAj41+Qo778WRm44VrJ3XmjpO66ReSenZLZv1fSI0OSVy05
jALYbH0L+7GAvFx+qmzH2hXYYKDABoNFfEMYzlsYfnhYb/54PQ+WXysTM65YZVz6FZvsMPLvv9+t
iYH1NlAOynQ/cO67Qrb87jd1cU32usDEAWRBXXG9cK1yB+6Slffukx5dRwFrfGDUCuIgL0yBNDl5
QMIHq8YG5JVLSzmMuIT5Y2S4Ttyfy+Yf/9qlNVngW9sw3iinLx3xhwzGPiEqD0mABEiABEiABEiA
BEiABEiABEigIwTwXYwN36z2LYvvZXzP2oZjnEMci98RYVkoCZAACZBA1xBYlBEO9TQGZeixz5K+
K75TC05d9w/SWxmTyplniGxYrfPTTIrc/XMJPvMXIrujaOFgNMIhOuqTB059oQx+67JaHt7t/yiD
n9wr/kvOcXk4ZXBlRNK/uUx6P39Rfd/73pfK/q11Vo9aPsmd5AsVx3AuvD7XWlKLE8WrBc97p3T8
6SI/m1r/Ir37a7LuO19rnm/uBCk/7IUy9vSnH/TDIK4sT+4nM8R5KMzh4qMQEG4uvm9h5sfPwZAQ
rt5cN7Ik/90PyMq1b5L9G+yaFGXF9V+UzZdfalnM2ce1yFz9Jsn/9DbpW/PHMvzMF8rIlo2RQUNz
DcNJGbzqX2Rgb6yI3GrxtW6QOwxzsu/kl8nKr/x7LULm5nfI0eVXy/2n/6GUV0dTKtk1zwzvkr7b
fiorfvEpyYyeKGNvulj8gWjYKTKweLXMuEMCJEACJEACJEACJEACJEACJEACS4CAfa/a978dLwHR
KAIJkAAJkEAXEVg0gwNeVNjw4io+6sUydtV3pK88Rcq7/p2S1c0cprGJO++BA07ZbfmUj3qhPLjx
Mll9/1Qs7+5PSuZdnxQp7NApmDT8wK2xNQ8s3nGy96w/lgA94HWbrue5lWUpza+FTzMiweK2y4fy
2z/s+XLvo6+Uw6/5dWvZlm6Q7DVvl5XXXCL+331Jgi15p0RHYptOyEYrYBQDyogbFBAPdYUzTji2
eBaG8xYP+41cpLwP3WgJf8NjBWr6qZU4/ldWff75Mrj5DKn0lSR76w9rUxg1yquVMLtGGHmQym3U
JLeJ7PuaDF6im6wV//AT1KgwLtnfX3OQ2Wj8qafJpI60gMzIx9/yx7L7iK/JhrunFgFJ3fHPslk3
yR0p/oYjdF6ofZLa/1vxsJRGzaUlV+iRIK9rWbA3SI0Kd0iABEiABEiABEiABEiABEiABJYOAfue
x/czHL6F4SzcHfAPCZAACZAACbRIYMGmVIqXH39JRfvrZee5H3KLGsfjNd9/npSf+rDE6V7Z/cLP
ytCWVYlwPZy81RkbDj5xiuw5573y4IopO0tctoPjRyHxOPH9ZPzG9oeJumiN49RFqR0grinqo8A9
MnhXvbEhHHy4FNc8XCorjpVK71YJ+hrwkNsl/YH3OcU65G+0wXjQypZMWxPW7YzXHcbravVwfvYo
2fOC8+ri4iC969uSTxgbKlicOuam4x+LVr/bW79uiMgDkr73Ssk1MDaUH3aR3Ld9pUs/VVZa9p7x
Mdl71LH1+eKodKek79HFvO9PGhtwUkdsZCOuOKIjARIgARIgARIgARIgARIgARIgARIgARIgARIg
geVMYErz3uZamrI27mMfPb3hioWj5Y5XfFY2/PQLsvJX353q0Z7Rfu+VUiTN4ClSOf3lUjr5Ybre
QlmCcrRgM/KBclxkjfz+Of8uw7d9Xzb94ouS3f9glE7nzhc/Nnwid6KMP/oFsvtRj5GiLgScqqY3
BTsSIc8w0x+lr/71s9GC02bdj590inMY/2vyrpZAj+NKdsT3B7bo3xuwq67HLXaNvToFvPYecMfV
hbFxHnEDXdTaHEYe9PzXBTIYW2qg9JC3yE2nPtzJDq6oj/OV1eC9P5ZVX/rgFFf5oqRuOl/84wZc
fMzBiDJRbxvtYDJZmXEf8bBZOej54JhpHkjv9vsP0yTXV5NN1RUByBvO1oyY3Ppsuf0lm2TzNz8k
PQf2u3N1f/qeKMNP/iu5e8uQ7PjEa6TgTmqe1XziccO0TcUUhQYqm8kEP3zKP4o/+AjJ/fDTknog
PnfSVC7hiifJvlP/VPbvOLzGDHWyelYq/bLnGRfJ2L1XycaffkkKD+ycSpzcGzxZKic9W8qnPUky
PdGC3bg2yA8bHQmQAAmQAAmQAAmQAAmQAAmQAAksVQL8bl2qV4ZykQAJkEB3EPBUgTul1V4Amd2c
/VoEFgSGg8J5//79bpFgKIMjBXYoAxPD0pfKysBxahzYebdUMn2qrC9UDQtVg4Dmg/hYvOjuu++u
LXSMl2FPT49kiqPSXxqTFUceL0GpKBP33COTvYMy2VNw5Tvls+aBRY+2bdsmw8PDNQU25IOsY8MP
SqqoCvt1G2Ttpk0ujuUP36YgGhoakhUrVkhaw3bddrukBvolpYruvr4+p1RGWdhWrVoloweGZN+9
u8RTg0LfqkFXB8SDEhr4IfsDDzwgY2NjMjk8JKmKrpnQ2y+e9o5HPGw9hbT4b3yyZEeqFoeBc+Q3
L3ymTumTc+Vt377dlbd7926XLxaKzl33YVn/7f+KrqqumyCv+56UByODj10Xm0oJx3DNmgPqjs0U
8LgOcFZPyI68JtR44OTvUQ66+LJjpFws/vj4uIsH9igTW6Y4JIPjI5IJdJqrTEH8lRtltCfrzk1M
TEjoVyRTLkm6MCADa1bW2gDKx3VDueMj+yVd0mmhcgUtNycDAwNOVnCAQ72w+SN6ffUahyOjEF4m
1EpUGlglI2oHwHm0DVwX+PHrjXJwHmE435PypTA6JIWycnNcdLqqvgHxV63V6byyLh7iWj6ov6V1
AvEPCZAACZAACZAACZAACZAACZAACSwVAvq9q7088WEcdeDU71nx0KtS/QzmrKYjARIgARIggdYI
LNgIh2TxplxfuTKarsYMECWdKx8ut2KDbDziCKfM7d1+tNx3331SUqU0FNxIix75vTo1DhTJcFu2
bJGdO3c6owOU3lBMp9Rgse6YkySrCnq4yXyvDGk+oZ4rl6MRD1Deb9261SmtnTFgdFRMBqQJUznp
WbdaNmr+UBBD3gMHDjhlM85DQY7yEG6ybNpxtNx///0uDs4hHdyaNWvUHpBTA4kuUqxjH/bt2+fi
QHENJTmU0JAH8deu1XUFNO/x8ZwEelUyOrohpfFgXBkcHHT5Zf72Ugk++KcianQYfdQTBOQ8rdeO
HTtqcZD3rl27nIyhjtBwTo0Nqb/9Tx2BERk4jCfi2kgH7M/krF7wsSEN6gu5kSc2GFWCXChpLduM
ExYf+Vs8nIMDh3JuhYwOrHd5xsORt5MrpXFVma8Z1tKbLIiPOB4MFelocWuUAYdwyAaHa4zjiqd8
taywf507LhaLzk9X4+GaID2uG8owGey623FJ86ms2KjTgkXGBSszFVTEm1QjSjUf8MU5V4+qTJDH
5Mc+HQmQAAmQAAmQAAmQAAmQAAmQAAl0ioD7Xq3ot/HumyQsjklqdI8zNASDh+s3vuos1m3X7/Ho
G7lTMrJcEiABEiCB7iEQaWYXS94bfiulH3zbKeuhjDcHQwKMAJWdd8nki84Q/567ZZOOLoAy2RTa
GAUABX/p+9+S4nnnSk6VwTA6mIIaL0gcQ4E/9pYLZOyT/+R6169fv76mdEZvc5STGlMjw0vPlMqv
fyn9/f11SneUgXxK1/6vTP6f54o3fMDlg/xN2QwjAOJNfOaTMvYPr5U+lX/z5s01JTzqBWNGVmUc
f9W5Mv71y2TDBh0xoUYFc1BCQ9bwvl1SecnzxL/zdhcHLOBQHkYHIJ/i5d+XyXOfJaKK8pQaHWRg
rfTedrOb+ufoo492cUbe8UYZ+fB73D5kCYLdsuaHXxOpGhsklZfg4k9Y8c6HDFB8w29lQ1zwtnQ4
jm/xcMvPCkyes3QWjvrGt3g6i2Np4MPFfYtjvqWPXzfsm+HAyrJ4ljfqFx+NYPU13+I1yxdtxNqJ
lQGfjgRIgARIgARIgARIgARIgARIgASWLAH9lpWJIZGxfSJDuyTUTcZ1+uNJnRkC5+jmTQC6AV9Z
TpR0do1ipW4bR9hkWSY0vJEGIdC0THfwJSAXtpf4vTTTfXRwC2LIQhFYsBEOpmStU7rqNEfZC86T
YvgxWf/0P3IKZowewHRAMDZ4575A58bfI6Vzni+Vz35FDttyhNx7771OMY9e/sXvflNyr3+VeNob
ffK8l0r+45+Vo446Su644w457LDDXC//4Te+Tga/8SXHa1h7z69+1flOAbx371458sgjnbGh8rKz
JH/LDRK8/CVS+eQlMvAIXdtBe7pDUQwDRfHaaySr59JqmCif+0JJf+Yy6Vmx0k2vFI1YKMjEv/+r
FD7wTrdmw2gYSN97PuoMBqiPGRuKr/lz6b3yvyXUbUxfDuv/+Cw3nRTKgqEj2PV7Cc89UzK77pXK
y14olU9/SY7Q0R2YLgqGB8gy+aPvSe7vXikpnVIoOPMU8b7y08jo8NGXyqNWPEVSq1fLyFtfLwNf
vsTVeaRSllUXvEUGbt0nXkHXIzj/P3RYgQ5/fOEfi3/kVldPKM9hNIHyHMr1ubj4dYWS33r0I1+c
s2OUhc0U9eAHpT/iYXQDwsEdzvYtLvKFkQgOIwWQT9xHOPKyeCjXykI85GPODAFmDEDZ5hDPpj6C
XMgDx8jX0mEfZdnUStiHs9ExVi7iYcMxnHFyB/xDAiRAAiRAAiRAAiRAAiRAAiRAAkuEAL5X4TAj
RDih0xzf+UuRA2pouOvnuvalfgMf+xQJV2iHxjVH6Qd7pqY/iH9rL5GqdIUYPmw6alj49Z371VdF
cZ1lAfoZXc0zl5FHbFulfqRTQMWidBWmI5dYO2d7afU+4vMq1mwWcXdu2uY5CIgXmX+EGha2bJPc
379K584PZMMznyPr1q2T8t13iqcjDtJjI3LXi/9Mtnz1UvHV+OB/5suyZes2p8Cd/O5/Sf71fy1l
TT/2+FNl1Rc+IxOvPEcKn/icHHfccS6OGRv2PPF0yQ3tk5Uf/6DOza/TFZ33OlmtivlQRytAsZ/T
0QEP/tl5api4TNKvUKPDv14ia9XoAGfGhkAV1nte8pey8dJPS6VqdFixcpVTYhc/+3+dsWH8oY+Q
yQ2bZM23vipj+jLuffeH3XoMqkkXGBsKamjY85yzpP+3v5Let/ytjGn+q9ToABaRseEFktq3V/b9
1Wtl5SWfktSfnSXli78oRxy1I6ozjA1/+wopaxlDJ/+BbLjsEgnV6CAwOrzzcl3jQdcNeOVzZeDK
ayRYp6MVVAc+oKMugj23SOb9GvcROipi5IDImX8osvdBGX3JF+M/FgAAQABJREFUSyWl3KEQb4eL
37SmYDc/rnjHvsXFPupvowjM6GA/dJKyIRxpkS/OmR/PD3VBOOLCxznbrJ52bOnMt/IsXxxbOZYG
x5DT5DajBfI2uRuVY+mtLItDnwRIgARIgARIgARIgARIgARIgASWCgH3Xau6gkDXxBRdGzM9odNK
q45DShNqjZh0HfF0AdClIm5XyoGe+KVKIMVyIEPjuuaoGh6y0I9Ua4Pukmkfuppo+mqrZKRz0I6a
GnFc1xtFD+74pWA6conrpdheGt9HuP8m9d6By+sU8CmnN7S7jP5CEFhwgwMaOzbXU7yvX/Ze9DFZ
e8ErpfAPr5ZxDU8ff6Ib2ZAeHZEb/uZCGT7qGBnZeqSc8JF3iY9pj3SkQ+X630jPG14jxcO3yt1v
eZ8uJj0oJZ3Xf8OlF8v4K85Wo8NnZfjtb3AjG3arseG2s/9KUtoD/biPv09WfewDMqLkev/0XClh
BMVtt8i9r/57GTvtqTL06CfIlje/TlI6mqH48c+pwT7jRjbA2HDbm94rxc2Hi79xkxz2oX/UkQ4v
cCMdSjo9EkY2jJ14ktzxt28RP5MV9M9f980vO4NC7zveL5NqbOj5yeWy56xz5PdqcEif8Xw5+r0X
OqPDREqtkI96nAjy2/eA3Pumd8vYQx4uD2qdt7/rjZHRQUc6+HfdLgUdDVJav1FlebeM6yLME3q1
tv3nlNEhfM1Z4lWNDeExGffSSd1UkdR3rlCZXiLeGz6kIxvOcMaGXa88X8ZOeZKsqo4IwPUwZTsa
1lyV4jAc2MMNeeLYHPI3w4KFoxzbR3yMeHBtQ/eRjynpTSaT0QwJNvLA5MUx0uM8nOWBfOFwzsKw
j7JxjM2cyYSyLH8rD3EQF+eQ3uTFCAeEIwzO5IaPuIgH3/Ix+Uxul4h/SIAESIAESIAESIAESIAE
SIAESKBDBOx72XWw01EO2VJZ14mMOtthOocS9jVMh/u7mSbwjYtvWvu+7ZDYXVOs6R3gF8u+3Hjv
ARkeL8tde0elohaEjQM5ZRnNzIC/no4iCXzPdXisqIoDvJ3eIYxmhvADX0c7ROuKGgSm03VFyUXY
XqI7otH9gOfVeNGXK2/aq4a7UB5/tE5Tn9eZTbLa4dgZHqJ70O4p+u0hMKUdbk9+DXOxhyxOVtRY
cN+7/0k2vuHVzoiA45Qu6nzj+W+W0aOOFVjNR3ccLzfr8bEfeqcEZz9Peg4MSfEwNTa89QNS6dfF
gzXO3ufqSAH9hxEIpWecIoN77pc9f/CHcsfZL3fTHIX6YL75Va+X4z72PlmpRofSlz6v0zXtlXte
dYEcOPlJklZFcXH9Jtn5jg/L1re8TrLnnYOnu5ixYWKjrsmg5Rx47BNFzr9QjQ5qAHn+06Sg5WBk
w51/91Zd3FmNDfriveelr9SkKVmrRofyL34qPbvvc8aGPWf+H305l6Tc0yu3v+Ef5aj3XCg9F54v
/qo1khoZdsaG0RMe5vIobT9GbnvDu+To97zJGSOyOtqjtE6NDRe+R0oDK7SnQUl2PeW5+uJJydGX
fU4qT3usZA6MqEFEFe5HqUJcZUfFKydq3jf7klajQ/lnT5XM/n1yx7nnycRpT5Os1gfXIn49Gl6w
OQTaDw9TwNuxKeItS1O4myLe5LEpjuw80sPF88G+HcNHWju2cq08ywflIB7OI8zKS8Y3w4jJZfmY
3AhHWUhnZSIvm1rJyrN8EMfi2TnLiz4JkAAJkAAJkAAJkAAJkAAJkAAJLBUC+M4Ndapot1aD7jul
Skw49z2NcLo5E8AIBUyjZFMpYWxDPqOdNKszJ+k8DTqFtE73rEpQvRhOd2GFQfeg2gwXP9JlRHoO
nEe6TIbpyGWqUy3by8H3A9ZOOaDGPr2VpKgzmOT0XtMJ1e0Wo78ABFSnDtztd5YtFMm48TH3PfZH
R0edkrZ4/32y7R1/L7m9u+W2C97uRjbEpYCytk/XWdjx/rdVe/m/R4LBFfEo7gG8XpX8m7/w7/KA
jli4+8/+2lmrEMnKT6tB4OiPvksGf3ed7HzV38n+J5zmFM+mBIafu3+XHPmOC8RTOW+/8CKZ3HSY
KwfnkA/8lb+8WrZ+9N0yevzD5M4L3iphTqcz0nPRQy1SjB/+mY/L2h9+W+5/wUtk9/P/tCaDyZIZ
H3VGh8Lv75G7Xv8ON7IB6a0M+IXbbpId732zlFetllvfFBkbEO7mVKz6my//ruz48udl92NPkRvP
foV41d79BsfzK3LC//2orNGpnG5TY8i+U09361tgXYOVK1e6dRCwRgQYQ5EOZzwsj1Z9q5sp3u3Y
8rP8k/nFRwggjXG0dPCx4ZztIw/LD7LDWTrz4+lx3uSx8izMwuN5Y99GX1j+iA9n+bueHyoTHPKw
fFyA/kE6yxN+Ul6LR58ESIAESIAESIAESIAESIAESIAEOkHAvmNNXzOhnUDD0Qck+9NPSGr4PunZ
9Wv9uM3IyPanqB5mk3iP+VPxele6tRjboUfoRJ07UaZxhj5nbLIiP75xr1sYOu2p8UAVnsevz0e9
rKt6hKzOyJDW/YH+HudDpwAHfURFdVujOhUTFKfIzxziMB25oN2wvUS6zeT9gPtwSI0Nn71yp7t/
Xvj4rbKqLycr+nStWOWW1P/ZvUV/fgQWzeCAhZLxMhsZ0V75+qDEC80b2i9pVfaPb99xkOLWbpS+
O25Rg8Mm8dXYYGFWZXt491/7Szlw4iPQsuxUXX6ePowHb7/ZTYOECMgnmVfmvt+7IYKlw7bU8kju
9F1/nYwdfawzNuAcykc+Jgf2+3/9SxnV9SAsfztneWHqqLwuEj153ENckJ2Hb/uFO26V8uo1Ulmx
qhbHDA5YpBjxVt1wnew/7qE6r+LBdUEiGB1W3nKjjJ/0aKf0xiLVMDhgQWso1Xt6etpqcDCFvNXB
6t/sxrX4SUOFqzDk13rBJX3Lz8KtPMvPws1Pnrd4LvPYH8vXDASW3qJYPiZvs3wsneWX9C0/+iRA
AiRAAiRAAiRAAiRAAiRAAiTQCQL2fWsGh/Hx8cjgcNXHncGh9/7rJFSDw2jV4BA++sWSUoNDu/QI
nahzJ8o0ztDjjKrB4fLf7dGpXSpSyOri0GpweOjmHh21EE3LDF0CdDbQIdgUzaZPgP4BG/RqyDNu
cEC9EB/pmW7KEEMubC92X+De2D9Wkk9dcbdbC+Wsx2+W1f15WT0Aw150/3Xi+bDcy1ywKZXiilfs
40EJZS4uOJS27sW2Zq0EqlgvKGXEsXh4gOJhCr9y/EMlrecy1fPWAx15WLziY06Wnup5ywcXzs7D
L6kRIKdxIIOVgziQA+dl6zbnI46dh49zlk9Jlfd2HmlxHs7iwC897hTJV/PA+XgeLp7Wv6J1zlbP
gQviWH3di0SNERh3gM1eMFZfjBRBnNGHP1oykDvhTKaUrm0woXXOa3lgVigU3MsLLzAwMA4WP5FN
y4eWHvnBoY5wFu4OGvyx+Fa/VtMl87XjpJ8s0sqx8GblWT4Wz3wLN9/CLR87Tp5PHls8+iRAAiRA
AiRAAiRAAiRAAiRAAiTQSQL4nsUGfUOgupG8TquUwtRKpmvAPEC6QQehf2q6j07K3E1l1+l53NoL
WH8BG3RAKWc40Mmbna4mXi/oEeaiS2C6OMWpfXKZYhHfW+5ccP+hjniemXHV1+cZRglhQ5haHGr3
GuLStY/AghkckiJC4YuLbIpm+AhzLy6NbOGmGHYXXsOT5y2e5Y8XI5w1jOR5y8fim8HCyrEXKfJB
Hpbe4ln5lk+zckwOi2/prRw7b76FJ+NZOSavxYOPvGGwgW9yW7ykj/iQFfmjTjA0YB/hlmcyTSeP
jetiydCu8tqVz2LVm+WQAAmQAAmQAAmQAAmQAAmQAAmQQEMCMDSYsUF9dCd0XQotrGEiBs5EAPqb
AMabqsM+wqBPMN2N7cf1NQizeNjHBmd+NbtaPvFjpos4keeh2V7i9wh0qKarxT2CewMb3cISWHCD
g93cpuzGRYXSHeHYx0VHQ8B5+NYooHiPNwLEt3hAgjwsL/iW1vJBHITH80EcKN/NRxw7b40vWQ7C
4/m0q5x4PiZrvByEmZzwTQ4MxcO++ZYWPpzlCx91yetIB/hYswF1t+uAsIVwKHc2brbxm+U9Uz4z
nW+WbzK8Xfkk8+UxCZAACZAACZAACZAACZAACZAACXSCAHQRqvhwvX6xcDS+6jF9c6B6A2xQzbk4
nRCuC8tMsoL+ynRYOAe9AlQn6BiazUYdRKGjsSmVTG9lehvToUG/g/TQ68SdxTef6SI6xsN8cjk0
uNh1ho/7xbbI0BfpgSuVtNOt6mCj2rON+r74U2X++/VPqfnn1zQHXDhcbLvwuOFx0e0YD1bEQRic
7ePBCmeGBIsP3+LiPOJjs3gIs/Pwbd/KQVw4K8dGFlh6K8fktPTtKif5wDM5rBwnnP6BvHBWB/hm
HMG+8XGR9A/kNhnh2wsL4bYhnI4ESIAESIAESIAESIAESIAESIAESIAEpgg400J0CD2K7jkNje7T
zY+AThUvWZ2+BVteNXG5TKS7gZ7G9EPmm07HSjQdDuKabsjOwUe4pbG4CLd9ppvq3Ewuh0Z7iV9n
3DN4kPXk1ICq+6odVaMq9KJ8roHTQrkFNzjYAw4PTjgc42JjaiB30as1Q7idqwa586ZctweonbO4
WJvAHMLgzLf8zbdzltZF1j84P1M5sCSbs/zNt/zj+diLws4hbfx8s/rEy0EaKwP7cGbRjlvHozP1
f5EOGwwoKMsMKfDhkvnWp+YRCZAACZAACZAACZAACZAACZAACZDAoUIA+gqMZcBmeoyUp3oc3XQF
B7o5EABHY5lRQ8O2tXkpVzJqbNBRDWlP+nryktV96MegtzE9Evbjzo6tw6npdSyO6XcsnoXbMdOR
p7UJ+Mu9vaCOuO+g57X7r5BNyWOO7HcmhsGCLsyOR1tVh4z4dO0nsOAGh6TIuKDYcNHjF9f27YFo
BgB7kFp8O2/H1nisHDtvx8jH8kaY7Vu8dpaD/E1eK2u+5Zi8yA91Rf7xOsf3EcecpUN87Ntm5+mT
AAmQAAmQAAmQAAmQAAmQAAmQAAkc2gRqOgXtv+n0J6p3QOdf9P01PQL7Ac+/jWCEQ49qOWFoyOkG
A4TxhQ9n+qNmpVm85Plm4Rav2flm4UwXXQ/jkPSbcWsWbumbnW8WznRzuw7gBqam78V9lU4FMtiT
VX2q6m3V2OBsenywWRNbEH/RDA724LQbyXyrlZ23Y/PjDcTC4r6dt7BkPjOdt3QWL5k+ed6Ok/Es
fbPzFm7xkumT5+04Gc/S21RLdmzxjWvSt3ws3OLTJwESIAESIAESIAESIAESIAESIAESODQJxHUE
GN3ghVPjGYJQlXa6IU483qFJava1NmY248fa/lxk1FE9KnQ0+Vy2ttYm4prepllJlk+z883Cma4x
GXJZnlzMiIr7CfdVuVxWI4Mnh62M1kDpyUf3XUqtgDhv92ljGgydK4FFMzgkBWz1gs4Ub77nTa75
5jNT+oUqp9kLyeQx38qnTwIkQAIkQAIkQAIkQAIkQAIkQAIkQAIgYMo59CWO76sWrgaIeoUaijnt
gB90N1B6hlUlqIWR7ZyQMhEJtEzA7jWsmwIXGRqmZsBpOSNGnBWBRTc42MPU/JmknSnefM9b+fPN
Z6b0i12OlUefBEiABEiABEiABEiABEiABEiABEiABGYiEGLOc91qDmtxVtfjrIVxZ0YCph+Cj816
WtuanMggHt6sI+mMBTECCZDAQQTs/sN9BSOqrSFs4RjZgn3zD8qAAW0hsOgGh7ZIzUwWgEBF5MH9
mq82iRWr9EfFAhTBLEmABEiABEiABEiABEiABEiABEiABJYgAR3RgAnOsekiDvHpzeP7S1DwJS8S
lJvAWvajhWxTqbTrZQ21iylBl3wlKCAJdCEBu78CvQGLlWgR9x69/9J6T9ItLAEaHBaW75LPPRoy
OSnhBx4i4W0m7pnifex94unbz25OO0OfBEiABEiABEiABEiABEiABEiABEhgeREIde0GG9CAfTjt
m+82Ghzmdq1Nn4Ke1BUdOXLnvqKUK4FkM57ksynZvm5AmUfzzM+tBKYiARJoRsBGDsGfKAXy8ztH
dE2aUB6zfbX0FVKSU6MD7lG7T5vlw/C5EaDBYW7cllkqHd0wEq/S3SKTetwXD+M+CZAACZAACZAA
CZAACZAACZAACZDA8iRQP8LBDXFAL2BstDjM+5Jr32oZL/pSLPvSq8pOYIXyk44ESGBhCcCggDvt
wHhZF20PpaL3nTOpIlDvQ7qFIUCDw8JwXfK52mJQgZufUedp1Btt6j7DMCPM3YjFVKJFVWjxW/KX
lAKSAAmQAAmQAAmQAAmQAAmQAAmQwKwJOP0AlHCBLx425KBKOh9Kcd3SsYWO2SN41nhVv6JKTh3Z
sG+0qD2tfRkoZbSHdSi+Kj9NNzP7XJmCBEhgOgJ2b8EvVXy5d9+43nOBjE+UpaAji8Kcm9Rsuix4
bh4EaHCYB7zlkBQ33tRwSauRhsEQEU6ZIOwMfRIgARIgARIgARIgARIgARIgARIggeVHABqAei3A
wSHLr9YLXyPoXQLt0QkDA7ay70vFjzp3LnzpLIEEDm0Ckd4TRofoHsS9iC35tDu0KbW/9jQ4tJ9p
V+RoN5yvL7ow9LXbgo5mqEmuN2GlImEl+qmBHgyYc5COBEiABEiABEiABEiABEiABEiABEhgmRJA
x0M3C0I0i1LKUy2Bbpz4Z27XG3oXOMwsgc2HwlN7WgeqiXPHfkVUJcOZJeaGl6lIoCEBu+/iek/o
PqP7EMa/aKuo3lOHb9XWcODMLg1xzjlwSsc85yyYsJsJ4AbETVfvNKx6M9aH84gESIAESIAESIAE
SIAESIAESIAESGC5EdB5DtzoBnQ7xD4c/tLY4FDM+Y8pP9GbOlKAIqv4vjKuGibmXAgTkgAJNCUQ
GRqm9J7RfcgnW1NgbTrBEQ5tAtkt2diLDDcc9kulklrUi5LVey9bq4QvflkXU6mk3cgGrOPAtRxq
cLhDAiRAAiRAAiRAAiRAAiRAAiRAAl1P4GDFW8LEkNKZDrDRzYqA6V2ML3pSVypYsBa9rDGdkrjN
FKEWf1aFMDIJkMC0BEzvidEN0ewuMO6JlFXfWS6n9F7MujVq7P7jCIdpcc76JA0Os0bWQoLiqEix
rBFVhd/Xr0N0WkjTKIo/KTI2UT2DvAqa1zwuGfIbHY/yy/RKmJ0a4JK07WENhzCcOt9IvFpYrb4a
ku6J5KydbHEnXte85pHXutKRAAmQAAmQAAmQAAmQAAmQAAmQAAksOAEb2WAjHbBotJkfUrpPNz8C
IJjV6Vsq6VCgisnoZgaJ+eXM1CRAAs0I1IwJOqqokPV0OiVMJ6/TKOk/jt9qRq094fPQXrdHgG7L
xTXW+34gwUVvE4FOfPAFknr9+apo1zUPfnGphF/9V5Gh3fXVOukN4p11rnirM7W5weojTB2FlQcl
vOorEl7+VZHdN0+dsL0NzxTvCWeK9+Qnq1L+/7N3HgCOVdX/P+nJtO27NIFdylIVkF0EpAs/G/AX
EGyoiAI2pNh7R3+IgoIIKqL8AEURQXoXQQUFKStLk6WJwLJ1WpKXl/zP976c5CU7szOTySzJzvcu
N/e+W8699/Pey5BzbtGFeCP84Xf9fVz7e+XPRZ74h0lxr1Zs1kGSOOijktt2pkRrLA66ryD2EtTt
zIb7A1jKPi+lGy+V0l2/W3O86fkiu39QIm86RKJTqusmKo1rJHjpwex3UrrmV2uOFTJ2fa9EDjlC
Ij0jcwvLZpwESIAESIAESIAESIAESIAESIAESGBsBCI68RC+6qCUU9Wc6h1G0j1U6zBmBEyfgjAW
jci82RnxdHlDMh5TH5VYRM07mhfoR6wWQxIggWYSwPuVikdkwdwuZ0TtSUclqRPD+Z3WTMpryqLB
YU0mI6esfEYkq0YFXTAgK5+U0rJ/i/zsIClp8pDu/tOkdP8FIp+5USLzuocs4hKXXC3F75w4fD5y
XrxOSn+Any+RUy+WyNbT11JeFfq/+ZCUbvvT0GWW3ijJi2+Uqdu8Twr5uiJYZzScW/xrKZ75+eFy
lYsaSm77lLb7KSkef6dEd9loiLJLpfS9Q6X0RJ1xxkpCxp1fUOPLjSJnXSARLngwMgxJgARIgARI
gARIgARIgARIgARIYEIJQCNghoa1aAcmtA/rk3C1N+gM66hb2ZCMRSSungrP9ekOcyytSgDvGQx+
PZmEGvd0dRF2itMVRjygZmLvGBDTjYKAWZ3dHnvRsMVflf9fXouxoSL7RSl99+NSHCy6Q5pNnoX+
IxeKP5KxoSILkUeldMau4j+62smzLJPn+nnlJ4Y3NlgFDaOP/FKS/RqpLEYIDpKGDHMm1190nvhD
GRumbC0yZbYVr4Sl814v/v0vVKz2FTm/eu+axob0VipDfY3rk2Ler9SvyeIFCZAACZAACZAACZAA
CZAACZAACZDAuAjY73QpqQ4AvuxwjHRwlLSlMBwLATPY4EzMuG6nNKMzIbO6EjIlE5PudMylIc/K
jUU2y5IACYxMwIx6MPBtPDWlPimdqYSueIir0aG6esvKjSyRJUZLgCscRkuqXA5/iOGwsHAoV3r9
6VLYZ3cpRpdL7LazJY4Z+hV3h87Yf1IiB8yrpLhIbpHID75emya7iP+OU8XbZispdeiL0PuCxO69
QuLX/rS23PdPFzn3a7VpelVapu1ee11t+pRDxTvqOPFfNU1K/3lAEld9WeLPL3VlSmpsiODYiTpn
43XJ6OePvltbYpvPS+Gow6UwJenSIysfl8T/nSDRJ1+qljv3bJGffKN6rXIif3msei17SeETX5fC
ZjODtNxKiT92i8Qu/apEsr3YfylUllESIAESIAESIAESIAESIAESIAESIIFmEsBvf+g54J0eQH+G
VxTh/Ek+LtTgGBgd1IDjplYHbM3YMC7hrEwCJLBWAvb+YRszuMDQELyDa63IzHERoMFhlPjsdPNC
QQ820D33KosBKvW3kOzxP5P+TTLBH2eZJXLQ1yQV86T7T7dVSskdfxJv71dJXK1pcO4P+fVn1Bkw
jpDeL31Scgns5afbIg14EolPlcjrPiDxuZvJ1HO+WJUnF0vxz8eK7LVpVZ7G/Bt/VntWdff7ZeWp
x4v2Xics6AqGOTtK6YO/l/itX5OZd948pLHBGkEfcaK73HKuHq1SdaWdvicrDn+9HrqS18Oo1cPF
N5TIMb+V7p8fIcmnAmOGyCXi//NEKe2ohg6VVXr6AQk/eIUjvyArZ+ieSX19gQzNTWz9Vol89UBJ
5dTan1QG2nF8ScRiuvZJHeJ0JEACJEACJEACJEACJEACJEACJEAC4yfgfmHrmQKiPohHxNff3UX8
Dufv7zEBNn0FQngzLCSTybK+KNBpWDpCOhIggeYQsPcP7xV0kPbeWTr0iohb2JxWKaWeAL/V6omM
cA3Dg+9XlxgGxefJwMculN6NUk4xjzKe5zk/sNf7RVX1VZdb7f54mwGjhIMfrrujmq+x7EdOlmw8
2HoJBg4o+xHCe7P3l1X/86aa8pGbb6nZpqlYfFqid9xXU2bg6GMkp3LQL5OFcNVun5TnX18rT00S
rq4zDujLCVcsPiGRP97g4sHH/tJ/yF7i61gxFpOJvvp+XHr/nxoYQqUj994fGBtgcMi+HMpR2Wp9
CLiirl+R5/sJ8Ts73HVNBV6QAAmQAAmQAAmQAAmQAAmQAAmQAAk0lwB+/5d1APg9r+py9y/82765
DU4OaYGiMyKeX5J8QfUnRTXmlIJJlKYEnRwkOEoSWLcE7P0q6vda1ivJYF51mO4LjZOYJ/pOhCea
T3RbbSkfSnc4U4Tn83k9U8CT8BnG2Td9S15ID4i43X+C8lYvGu2WzqkiXSvLw1/1Z/FXflAiU4I1
EsXHb5VUOcsF0z4uy3qykl09xP5GWgAvS2SrA6T7huuqqw1eul2Kq98tpc7ghSku022NwjK7jpPl
nTnJ9wdnM6BvkIMQ4xl89Xsk88B1Mk37H7jq/06gDIwBxefvr1mVUHzNIbLC65fCINZMBAaDoG7w
GU+9WjLTRDpWlFMfe0jyud2dEaI4dUsny17v5CVflNixX5ZV01IVC2MikXCzAGBxhIdBA9ZJs/zb
l0a4TcZJgARIgARIgARIgARIgARIgARIgAQaIxDR8xvgzUVVb6DKA7tkOEYCprdwOg3VqyxZlhNP
DQ7Y2iWlB0jPndWl+o7gDIcximZxEiCBEQiY/hBh1ivKPU/1qrGhJAu3mC4dqagkoV8t+xFEMbsB
AjQ4jBGaU74H5rBKTS8VdwYJU+Ijw+K+n5b+zbZVg8PicnlV4Oss/mgp7soU/WxFDiLe9jtIXvPN
YBHONEOBJOdKtkuV+bYDkejByvrHq6RWcudefNitorC6xa22l2ydTFdeX7SKQcEKW6h5cMh3fuUy
y3FhpP8pST+jJ7xnc+7aFceH/c9IPCux8i5LrkAyYASppZ7NBOaU4NQH5P5DZvz8EOnZ/kRZsccB
kp2hg6MjARIgARIgARIgARIgARIgARIgARJYNwRgW9CWnFahrFpwv+/tN/666cV624pqVmQg50vO
86VTD4wGVig/6UiABCaWAPSzUOOuHvRUd1oST70zq+L1s++6ie3CpJROg8Mob7sp5oMtg6oWf1Qv
5fvV4JB2s+/tbAYo9OHc1kqR8BoGXT7n5aUU6Oml9OxTknElg4/sBjMqs/nxUmCmPxxm+KMPQRiX
gY02lY7HdDsm53SbpwG1lMcD61ypqJa6cg6C3KyeikHE9igLDCc6e2GY/3mw8aI9lPGLXk0/I0+c
KbOeCDUyUlQPYfCwOkTLFYuzZNW7T5JXXXxmTa3Ev34os9WX5hwigwe8U7Lbzq30DxZJ9GO4/tYI
4gUJkAAJkAAJkAAJkAAJkAAJkAAJkMCYCBR1++hIaAvpYiSmZzjorgP8LT4mjvWFA11OUZb15XRL
F1+y+bgaHXRSpio+kUdHAiTQfAL2biHM61m8zywdcNvCD6jhIa0ri0pJnBFLi0PzyQcSeYbDKMja
Q4qitjKgtlr1DwQU46bUh3LcKcprHuBghUNF4b/88RpRUT/YoqhSt/yHHYYMyA2cbjFkUZegeyFl
PfeHyrZ+Cgv1ujoqynrIMA+ZpsQf7hXD2OGji/8eFjn2eG9OV2AE5z24l32DN8qSoz7tVjrUC4u8
eJV0XPJOmf7Nb0hSlxzSyFBPiNckQAIkQAIkQAIkQAIkQAIkQAIk0BwC7je3Ghb8jml6juIMyWVm
Sb5jlpQSOj0yoRtKRwLVEX+bN8YbOpCiblUFAwO8pztQFEKGncakshYJkMBoCJhe09N3Dueo4F2E
p7FhNPQaL8MVDqNgF/6jag9quFpEjQypVEqgwEeI8igH5f/AwIDEomF1vqbj4OZ8MFs/pg972BX1
dAMYKTo7O12IFQ6Qh5UGMFIgDrkRlV91Hbq6QZfm5corFnRPwLDLPPOipLaa4QwN1j/kQx6c73sq
10WrH/iDqPk23tycLaVb/lbJ9zd/n6zcdKokoknXp0j5f0B8NZiU8PJ6Guo/sIn4ymP7/XX5YM6N
yeR6G+4jj330tdL9xF2ywd3/J8mVyyvyXSR3jaT+9zEpfu0qiWSCU+RrC/CKBEiABEiABEiABEiA
BEiABEiABEigEQLQL5gvpqfIf3c6VvUVOfGzWf0tH5PM9NmSSGUkHgv2ULCyjbQ1GetAnwIHHQi8
r7oaX2daF1UT565Vf6LqHacnQTnwpSMBEhgfAXvvTJ8Z7FSj7517D2FwCDz0rKqwrbx3fP/Gx72+
Ng0O9USGuLaHFVnheKWoKtthJIC3VQN4oOGGemAx098efO9VC0TuXlQRlegbUDk9ThZWIkCeOchE
G6VSn2T++6wla2jL8HRfMpWtH6E87UNB/2eh/D8S1j9XTksF8vUFq61RubJ+Fjtqz1XwNtxdXnz1
htLR0eH6hH7BYQsp9DOnxgXURbsYhytXkRqOpKRPD8F+bse3SGLVIzLrjp9J+tGHQgUel+hP/yCl
zx0eSmOUBEiABEiABEiABEiABEiABEiABEhgvAQqOgs1MBQ7ZqhCvCAFPZPRpae6dYWDToLU3/uV
cuNtcJLVr+qQgompgQ0iHA/0TOQ7yR4MDnedEQgMDVU9qek511kHJmlDVW32JAUw1mG7PwJ1VudI
LFjZAOW9rSAwC1oymVSFe3jnKli09TwDL0grlMJ5IunHH5XUwk0lqBdzIdqEPLwksMAVBl6UzKpw
zzeUfMRzMp2SXy3mYRd/8QVJaz+i5f4FRotgBUMgU1dM1FocKtXRHmR6erhR2CVeel7TN3AGBsiz
syasn+Gy4TiMDyiPEONC+5CPeqWe+bL0sLMk9dQfZNalP6waQZYudmXCchgnARIgARIgARIgARIg
ARIgARIgARJonIBNHIQeA7/RMYHQ6QjKOzekdYIh0k0/gd/wTifSeJOToiZ0HHAI4Z0epwC20Otg
OyU9p1M9WJtOZFKAKQ8y4FOQFUtXSEF3+UhPmybdqp3ks/XKPAXr6/2wd8v0s3gt4d1Zu6qTLRYT
ekZN8J6CPJ+/5j5/tdru5sqeNNIiZeU5Hk78wYZH3K41uobDC42H3+/SfRHDuaps78hW5ZgsU9Tj
OvXwNRIcJV2uuOFrJBc608HfcMfasxH+e7ukvPIWTtpXk2n9Sy26SKbUGDDCHQri3pytg1Pcy1mx
f98g3YVqzzGe4EsqeElrx19dpmnpGA+8XRsPMMnPfZv0z59Z7UQuq3+Nq/KrGYyRAAmQAAmQAAmQ
AAmQAAmQAAmQAAk0SsB+k0NPgEmU+J2OCYXwSDOPcnSNEwC9hE5GdV41cXH1YT1K45LbsWZWLj8h
KTPmzJE5c2bIlOQp8u/gONN2HMx60Of1935U9JQ6pTmdiEgmqfpW/adaSr1vVZ3menATW24INDg0
5ZZE3B9m++NsyvRgu6KhGgiU5+6Py8yF0js1XOZfMuX31+seiYFCPvzH3f2PwKq/y7SrrwxXkN49
dnd7kNkfq1JiM+kP6etF7pOe6/9RUe5DjvUx8a9fyIw/XFQjT00GlWuTKen5snrDSrJG7paNbv9n
5Q+klavI1f85wSyIdDotnbGEW/mBWRO4zvQ9K9P+s1w6Mhl3batCIANbMQ0OrpTSiperjaX08Cr9
B2OEWSirmYyRAAmQAAmQAAmQAAmQAAmQAAmQAAmMlkDYyACdA4wL+P3e1dUlPT09FY9rnC+J3/lh
3cRo25ns5UxPghBne86bnZGtN8jI3Fmd8qrpGYlFQrohLbO+O9Pp+H5Olr4QHu2T8mJfcG4pyrSK
Q1+e++tPZL/yhOJI5NVy1s1PVfRgrdLPRvvRbvej0XHi/UvFI7JgbpcsnNctPemoJHXSNr4H6SaO
AA0OTWJrf7BNnD24Lj2kwLd8C0uljCzb60i7dGFkyWmSOed8ib68spru90n0gUtk+hknqi0u5Dre
J0s36QglINopK1/9xpq0yD9PkinX3yWRXDl54FmJ/+YEmfKb82vKDX+RkuV7HFOTHX/067LlVddL
R2++YszA/4Tgf0ZS/S/K9Ad+L6869yDZ5PunSiZX3UYp+dcvSfdFb5fZZ5+hhoeXJKmzKKr8ctJz
54+k+6VQU0ndR7K8pVQolVESIAESIAESIAESIAESIAESIAESIIFxELDf4vZbHr/nw5MpkW5lxtHM
pK+q9gadYR3VGdZ6GLfOtIYCFFwno4MCOFFjXylJvEUNLs/e8Ru5vXKTHpI/3Pt85Wp9ibTT/WiE
Od4zGPx6Mgk1NiR0gjcOaldJNc9gI5JZZ20EeIbD2uiMMm+4P76V9Lq/IXiZw66w5ZGyfIPLZHrY
wrvkHEl86xz9i7SVSEpfhlWPh6uU49vI0qMOE1/flJR6/I8ALJRoN7fjUdL/5+ul06tWi915isTu
rF4PH6v2D7LgEBY2PUxe2uwKmf101RASffJHspF6Sc4Vf85muhnaMomueKhq2HC1dc/HtFrvU8HK
imhqA019QmTZFdLzf+plpvibbCd+aUAS/9GVGK5O9SP7pv0ll89XVpFUuGoR61+1NGMkQAIkQAIk
QAIkQAIkQAIkQAIkQAIjEYAOAc7OZISxAc50FpZv6fz97fCM+sN4gWM8VpIZnbpnvJvBX3L6m7hu
sYS8sI5j1MLbqKA9T+7sTtWHeV5eCjULGYriqc7H80qOhT2Pxm9dDzW4R7qzt55p+vLyZTXNdyf0
DA5NR9/a9b1ot/tRcwPGeGHPUDwWkY2nptx3WyaVKK/aqm7/PkaxLD4KAjWT5UdRnkXWQsAeZBQJ
x+urRENK/KBch7xwxIWyYpNp9UVFsmpoGNLYsIe8ePRpsmJKdXVAbZuz5Jmjv1V7lsOa0l1Kae5n
5blDPjRMbpCMP4LRaEJeess5snSL+WuWzS+R2LO3S+yFemMDinbqBoXVFzmiB0/Vupcl9twdkhzC
2FDY+XvaXnXPKftirK3PKxIgARIgARIgARIgARIgARIgARIggfEQgE4BPvj9v/4rwsfDaix1jSmU
ngk9vCGhU6zDxoaxyGrnstDnwLutfGoGoulqiEF6K+l80JdNt9yhpqc6m9b1sZX6WdvB0V9hDPDt
cj9GP7Lakvb+JfXdSyWwPRy+59aut62VwKtGCHCFQwPUSjFVoIdcsTwLIJRUEy3VUJ4uRf0jY+c7
uBdbv1QLhenywtt+KQNP3iSz77pYEiuX18ioXCS3l8GF75D/vmYnyevkg4S2bUse8RIhDqsxwkjP
TvLYsWfLJrf8TKY8dX9FRCWSep30H3isvLjNppJ98rJKsshmUtTVCJCHfuILCCGuc7kueemN35X+
5+6UDe66TNIvPxOqVxft2UMKOx0s3j77SiSjBgutD1n+G74thZ6dJXnTBbpt1NK6SsFlacq+snzv
98iKrTaWmFqPjZN9IQ5ZiYkkQAIkQAIkQAIkQAIkQAIkQAIkQAJjIgADA5yFY6rMwmsQgO4EDiE8
uCLEORnQaViepa/v3E2PgxC6nWw2K57vMJQ/ipLTtJIqz6yMsQuXmui43Rv0EXGsZJj3jnNk0Y4f
lhcHPEl2biDzt97Q6dxwz1DulejneDlgbOZb+X40Ok7cEzjcI4zT3jtLd/pSLWNho+2w3toJ1KjC
11508ubaQwkCeGD9Vx0qT3zi9RLLF6Sk1s2I/tGozsFfk1N2n/+VJ3ZeKdGC/mHp7JCI/i3PhF4A
1EAbeBEGtn6TPLPNW3RNQF6SvSsk6Qd/jErRtHhTpstqtcThC8HzPLf1EPpj3mQgNC/pTeQ/b/2a
rIgXpGP5S5IuauN6IFSpZyPJT+uWvv5+KaqBwp/zFll07AG6j56+kNrHqboiIRaSY/LwQrovpM32
kWfm7ieZqC/pvpWSxl8LLR+L6RKlzm7xp86QYjJeeYHtQQu+1JLi7/wO8XY6Svze5RJdvVxKvX2i
gmWwGJN89zTpwwaH6pLus/qHunzJgARIgARIgARIgARIgARIgARIgARIgARankCgq9EdqFW/A31K
NBrMssYGVsibLA76IIzf6YVqBg0FeLDCoZV4oK9F1aHN3mIbmaV9dwpqDQO9VqCrqxlGm1202/1o
BK89T0W9b1ndsgtj7kjrxO1J9N41wq0ZdUwP3AxZ660MPJBhhwc2Ek+Lr3vw4QsHPqz0d/koo76S
nsqoAl4PxtGVAlbH8rEiAZZTfJnZXnB98YREuudU9lK0L+WCGhrQH5ObSqXc6gNY7CAPeZCHdJOL
tFwpJfnpmzrLnpUrqbEhr/vkBV+iuoFePCkxleO+RMN913hYHuTCQ24+kpTClA0kp0YMGw9YRYq6
p13Od31DX1HWpZf7iHaR5mn9YvdsKXXNcte5XM6FUZUPh737rD+Qb95l8oMESIAESIAESIAESIAE
SIAESIAESIAEWpAA9Bdw0GkUVN+zZFlOPD28INjaJSpzZ3VpXrD6oQW733CXTP9T8gZlRe+g0znF
012SjBbLeipf08LiVRemui7omeCsvpWov/YGV0vvYCHIjmdkek/GirrQuFtifX1Lt9DkxVVWd3fa
9Rd14E0Xhzj0ddBvIQ3O5Fpo8urbt/T6cpZeX76+nPXPlR/FeE2uhSavWffD5LZ6iHsFhzDrFeWe
p3oFhoeFW0yXjlRUktQxTugtDOhPaBPtL9xefoTm8cAijtAeYox0bWWtvIX4o4O6Flo6QnwhwJsx
wEJrA2XgsdWR1be+1F+jnDmTY6GlW13rj6XXy7Jy1r710fqLPxAmOxyavOHKW30rB/loKxwiLzwW
K8uQBEiABEiABEiABEiABEiABEiABEhgHARU/yD5fpGc7j6Q7Q1CX5W6xZq9b8bRwOSuqhoeGdBJ
mX3ZguQKvuTV8ADl5/rolj50g3zjhLdJLNUpM2fOlNmzZ6tRoENe944T5bK/PKM6Iz08e4ihQy80
rMs+LzdceLocfcBOkuqc6uRC9sypnRLd6QA55YeXyyMrykaIIYQUnr5Bjt5pJzlA6x9w9OnytJYp
rV4sPzxh/4q8qSorttMp8s8VVQGFZ2+RTx12mBx++OGy/+EflVufy1Yy/331N2Xnnd+gMg+QnQ44
Re5cOnz7Vin77z9qPw4I6ux0tNz6/DB1xjleaw/hhNyPcAMtHoceEc/b6kFPVuvWWJ5eOJPRWh63
Fh9SW3SPKxxGeZug/IbDSgIo4WHZxJehKeQtDCvEUQcGAYTpdHCwDGbs49pWJOAaink4hIODgxVD
A9LQTtjZWQpYcWBy0TbkWNuQY6sQUBdxk4M4yqEuQsjDOFAfDiHkob8IrT3kWT8hA3vuoR7icFix
AIc6Jh9tDOdQD/LgIcf6h/Koj/EhtH4Yd+s38uhIgARIgARIgARIgARIgARIgARIgAQaI4Df4nAu
zKmx4d93BEYH3fqnlFCdwOa7qBKkU8947NGtoYPf+o21NLlrBTqPoizry8lgXvUp+bh0puPiq+LT
7kE7E7IxFIt5ufNHx8q+J1885HAWXX2BfEj9QR/5nGysNq2qq11JYOmmg1p27yVy5MKj5XbLqA8f
vE3OPAle5Ae3PS0n7r2JK2F6I8jpX7pELn7wwXLNhfLcF+6Sb223l/ysXtZDZ8k/nvuSvGZKp9NJ
5Vc+J7+6665KqSWrTnfpkN33n/vkoYduL+fdJt+7/F2yx3G7OH0bEq39Kp+i3HXxF7UfD5XriDy2
9GzZb8OeyjUi4x2vCWv2/TC57RIad4R5NfI9s3RA37miDKjhIa0ri0pJt6lZuwyn7fpJg8MYbxm+
MOChWMdDixBKcPMQh3x7sJEPZ6GVw7WVM3koBwW/fani2uSgDJzVQwhv8hCG5ZmhAOlwkGOycG3p
iMMhD/VRz9rAdX27qIey1k+TaWEgLWBg9U0G8sJpFrd0hNav+rEhPSwHZelIgARIgARIgARIgARI
gARIgARIgATGRwC/50u+J7HVL4rodjXFkk4sVENDKTegP9JVbaTbQ9M1TgB8i3pGAQwM8J5OwCz4
w0/QbLylV7bmQxd+fFhjQ7hnN/74tOByaw0eC+esGV9x3/kye+GH18zYe295qyyXq+9YVJN38n6b
SeQvL8jHd5tVSXf6qmCObTntZ7LXdmuYGirlu+KBHg8JkcTQk10hc/5+79QSf6zUu+rca+Q/H9pZ
XlVJqY2UvMVy2VerxgaRD8peW+h7prLMBeP9iF1WwzGM1ypNxP0w2e0Ugi+85wfvIN5FeL277TSM
tusrDQ4j3DJTcpvCGzPtYRAwxTiqI24rDKCIh0M9pGOmPsrbCgLkhcujHB58KNhRzuQjbi8F6sCh
rCniIS8sx9q1vqGsxRHaigzIRJ7JgwyLIzRjA/qBPMg1WVYX8qyfWKmAdKSZHJQ3j3KIW2jlTSbk
DzVOpKN9W8lh/bD+usb4QQIkQAIkQAIkQAIkQAIkQAIkQAIk0BAB/BaHczsODKyW+KJrRFY9L7G8
7mjQOV386XNFpmykM4F1hYP+g74ADr/n6UYmYHyhL4H3dRslX2daF1Vt5K51yypsGmF6jnbjauNz
+qaXdMuiD/60Fsqex8klX/mQLJw3TZY//ZBccfbn5LQrHnFltlZjw2MhY4PphRCCjdMZDTwoH19Q
a2x4/Qk/ku997GDZbEawK0b25cfl4v89Xr7wq4crbZ+0xxny5uw3ZHPVKZm8vFe7e0ilsEaO+PRZ
cvjO0+T5B26RC74zIDN6gl043H1ziulqaRxu7el5E+hfZJPd5Ot7iXz5z+X8h74mtz76CXn31l0u
3+6r6cFW3ne9hAnt8IX/J3OjeZVXXj2UXSQnLqw1NoxlvPPK+kj0u9SE+1EddXvF7Lm0Zwr84d39
xHZKeMbUu++90Bkq7fb+tfpdWf9MqhNI3H2h6JcKvjRM8Q9FuCnph3o4w2URry9vMiEDHvm2rZGV
tXSEyAunW30bNq7RjoUoW+/DcsJ5ZsRAvsmAHDhrJ9yXcF2km0ddyArLMznhMiYLcix9KJn1fbGx
MiQBEiABEiABEiABEiABEiABEiABEmicgCnlSlCKD66SknrJrnYeqx5KRd1OGgrMsnGi8ZYmZ80q
NzurExzC8erOFu1KCGO87zfnS81agz2/JPdd9hXZe7sN3QTUOVvuIsd9/zq56gfHuGGGjQ1IqHIK
jDFQDj/yh3Pl0hCUPT99qVz6lSNk0+nBRGAo/mNTNpcPfPca+dnR24VKni6/vXuFUzBDrimaQwUq
0a///j754Ulvl333PVCOPuV0+dPL58pe06OV7cMrBcsRvAtwkOv70+Sgo9/vru3j8mvvd3nh8SAO
f8/vL7RiLvzwW3aqtIP8xVc0Z7yQNd77UdPRNr8I7n9w3zAUux9tPqyW7z5XOIzyFkHpDQeFOBwU
5HCmSLd8u67Pt3r1+U6IfuAFgEM9PPxw4ZcA9awuQpNvoeVZXWsP/bK0oeQhzeqiTRtHfYg8uHD6
UHKDUkE5yDVv9awOrhHHCgaElm7lIQfx8DgszdpgSAIkQAIkQAIkQAIkQAIkQAIkQAIkMDYC9vvb
Zv26MxnzOUnqLOCI000EOgmc3agHOEpC05Bu9fBbnW54AsYJITxmUhcKnup9MMsa2ynpqhL1pgi1
8sNLbK0c66/N3C8UlsjvTq1uLYTenn3au6Wjt1f0CHLnjMW8A0+Vy/9X5PBP/6KcgyB43lxMecEV
i0/I+e//uYsHH++WL7x/oeT6+x03pFk/8Dzuc8KJss1FJ0iwfkLkkhv+Lifusp+riud7MBecOxrI
Cj6P+t61cuR2HdKr/YSOynbYwFmikInx5T29USFXUFm5XM6lIH+T3d4k28iFlXav/vSVsuSju8lm
IV2ce8/yj8hvz/hXSNKpstu8uJMV6AOXyPnHjG+8J+16QLnfT437ftj9MsahjrdNFFzRf/CHx6MF
D0OV50X1OdIzdfWrzMbI77Xm3lqucBgjTzyAQ/nhxAxVdqiH2MrhSw5GBFxbHNeIIy0cH0qO9WM4
eZBjPiwvnGZ1h5JveSg/VD+RFu4jylmdcDhcfSsfljFUP2ycDEmABEiABEiABEiABEiABEiABEiA
BBonYIrvsASncNQEbD1iCjkLw+UYHx0BmGgSun1L4HVyZcxWOVSV7aOT1Hqlii89IfeEu7Xb12Xh
7CDBPUfQ8qpzindVAm+2/zHyuX2C/MpnuYyVyz99v/y4kimy+2ePkC3jpjgOnknItmfXn7FA3nNg
tcK/7viXLNe2LL+oW+nUuLd+V05902Yu3/pYH7q6uu9/2MFgZOWcInvqjnJsqF2Rs+S2xatq5ELO
sntvkl+FBB34rX1lo3L/IK/w7ENybigf490ihi23qu2hnI1nbeP1X3xC7g7JkkbuR7h+G8fBDE41
uZLW8zgySdW16j9chw1drhA/mkqAKxxGidOU3sOFw4mB4hyu8pCr0WAoVy/XygxXz8pbOQstvT60
fli5kUKrX1/O0i20fOunXdfn11/DsBB2Vr++XP11uA7jJEACJEACJEACJEACJEACJEACJEACjRGA
8hIKTcz41Q9VZhYkogdGmyquqGcOlNQXtExMve1A0Fhrk68W9BzmY9GIzJudEU+XNsDokIzrJM5I
Nb8d6ZgBYdmSB8WOMcA4Fu6/rXToqo5SeTKt6XWglzKFeb0yEpyQh7J4HntfeKkGyfIV/5ZHnoiJ
N+hVnkNTxqNeLDYoT+tuYBXXqXo4zGTXBKxw8OpWKpx61OskpX30VTdlZ5jatuDWX9enssLa5Pq6
UgUrVlAmGEtadjvyeJGbzrMicvHVi+SdWy50ZZDoeYNy9x9/WckXmS+H77lFxZiA8fa9ONR4o1LI
FkY9Xl9XXuS0XyuefFDuDLXWyP0IVW/7KO5jKh6RBXO73FqanrTec1XV2n1u+wG26ADq3/EW7ebk
7Va7vADj7ed460/eJ4QjJwESIAESIAESIAESIAESIAESIIGxEYASzpxT9Oo1DA3hKZLh1Q1WlmFj
BNTeoDOs9VxPnXupgVvh0M56kPDz40cTNVAWbjnDKXMxPngYqlDe6rj0mhrVC5RBfilefT6R++h5
n5RDqjr9aoXhYirHGQQ0HzIRr3GlwGiAtsI7cNi19df6XKkbGoelzdp5PzlAzpNbygl3fvVy+fdH
dpVtEsEYigOPyNVnVg+1lt2OkNduGGynbn0rRmv7h/EeOsbxwgDjg12seffDxtjOIe4pDH49mYQ+
C3j3sA28jqj2EWvnIbZk32lwaPC24IEdixtt+dGWG23bzZZn7Y5X7njrWz8YkgAJkAAJkAAJkAAJ
kAAJkAAJkAAJjI1A+Dc5FJU6bVv3T9IQvuwKqqTFIblx9eEzHCyf4doJGGMotOOxkszo1D3jofhW
dVKQFmx5jXJWdu0SWyMXY4Ci3Cm49dkp4ECKkJs5s8cZGTo6OipbbiMbKw2COmlVAIcqlKNmFMCM
/yf+8pc1C4wl5ekByekznVG2WJHg122pFNXVFjirAcYQ6ydWOth9sL5AQR12uMa9QzmUceU7d5C3
HSlyy2VW8jy59eFPy9xXT3MJLz/wp5rtlI48Ym/psaIaguUzf6/ZBCmUO8qojndAVzjA1JDL67sc
co3ej5CIto3a/cQWZhtPDc6QzaQS5ecyeO+sTNsOskU7ToNDi94YdosESIAESIAESIAESIAESIAE
SIAESIAEJoJAeOY24mtMqQwrWsPxiejMei4TCs3AwKCzz93U6mA7F1Nct+vw8dzA15+PcO+/XpR3
bdtTMTbYCgfb6juqs82HsDc4DPZcztpqmxosC479orx/l5lqsKieJwquUPrDQIEQxgykJUoJ2WiB
KvXRvxop1Qu7J7gH6Jd5k4lwOIc8q48ykUhcdj34VJHLzqhUueCaB+UDO+6t1wX5xxUXV9JFdpM3
7bGpu7b7jzHPaHC8EJTQfxvturd06fiL2rf6UY/nfoQ63rZRu1fYxgwOzx9u79rucdsOtoU6ToND
C90MdoUESIAESIAESIAESIAESIAESIAESIAE1ikBVdaqxra2SVXIQTnuFORl3aspWmsL8qqegCky
jZcpljGD3hTqyLN0hO3kMAZ4KPixesBWA9gYsrpKBmOFhyIfZyPAIY46+XzKbS1l5bHkAzxsxQDK
JLq6qtka23KrhbL33nMds1QqVVEWox85ndlfY3DQ9tCWsa4RVL6IJZKVFQ5Y6WAGB2SHZUExXe/C
987an7Lz/vJ2OUN+Wy68+PSr5eETXydbFhbL7366uCri4CNk4ZyEniEQq9x/jDfZ4Hgh2M6esPHm
686raPR+2PNb7Xx7xNBvOLxXYGLvnaXjXiNuYXuMqv162V7fau3Hlz0mARIgARIgARIgARIgARIg
ARIgARIggZYkYEpKdK42HnXnYD0AAEAASURBVMwAhmJOdXZ04yAQKDr1MGS/JHkcwl2MiF8KlKKm
BB2H+FekavhZwVkfYXfTv54VT5W9GBs8FLtQ/pqPRBKaHq5RG4fsYr7WAPbYk/91zyfy6j3agGxr
LxxHGlx9e9FooHQO98/q1/am9iosx9px40psKW/82MJQ4Z/LXY/pNkeP3iJXhFKPO2yBpFWItWX9
K3m1DBsZL5oJ3xdrdrz3w+S0Y2h88YxmlfGgPlfB7lpreQDbcaAt2GcaHFrwprBLJEACJEACJEAC
JEACJEACJEACJEACJLAuCESlqFvc1Cp4oagraRK8KVbXRV/WpzZMqQyFOwgvWZaTJ5bm5KllWfnP
ypxqwYOtfKxcO43dFLnoc8dmr5ZDwp2/9CZ5XIeHrZTg4cJjXHbPRfLZm8MVXIFKApTmHZtvJwsq
KSL3nn+9PFmoNTZAJp5N8IXHygfztmrB8qNhSwGa0211UMf6h6Zwbc96eHyhbjjLBcrA2yoOrDCA
32n/Ggpy8403y/XX3xKqfrD8z45zKv1FfVv90Tm38fFCjq36QL+7Nt9RDg61Kg3cj2HHH5bb4nG7
Twix6OOep3rlbvX9Hja6UnW4ssI4zbf4cNquezQ4tN0tY4dJgARIgARIgARIgARIgARIgARIgARI
oEkEVME75DIGKGnh6cZNAPvqD+R86csW9DBj3VZIVzrUrwwYdyOvlIDU5rJPja79D/KNX9wzZG9e
+Nv5svCdpw2ZV5PYua0cdUQ45Qo566J/VpTDUBKbQtkMBwjhC2qYsDyEwznkmbIZ4Viclbf6qJue
v5t8MCTk5u8eLx8982/VlPceLPO7qv0O15XO7eQdDYwXBhMbrxlMRO/H3jUWhybcj+oo2i4GzljV
sHrQk9UDnnh64cyrtYtK2m5crd7h4d+8Vu85+0cCJEACJEACJEACJEACJEACJEACJEACJNAQAbf9
ihob9Lhd59dQueq2MwJPNy4C4FxQA8Oyvpws7c3JstV5WanTrH1VfA61Bc64GltHlWv73Sm7HXpC
Tct//fYRcuLPbpUX+goufbD3abn2zA/J9m/5XE25ygWMXmUXKOLT8vp3fsmSXHjbD94vx/7oBnmh
P+LOX8AqBvjOzk6R7Er511+ukM+8b0vZaquPyePFDrd6AAr5GsW+SVQltKVbaFkjhVbejBq2qiIa
3UQO+uz+w1b//JtfI0k1ctiKCDN4oI/xeKfs2eB458//uDzuZ9yKC8iORrtlt0OOr+nHWO9H7f2t
EdU2FxiD+bwa+Z5ZOiBPL+2XATU8eHl/jcO122ZgbdJRHhrdJjeK3SQBEiABEiABEiABEiABEiAB
EiABEiCBphOAsjek8K3Ix6zvMc78rtRlpEIASs+i7k0FAwO8p4cEF/z2nv8Lpbs5KM7n7H20nLL1
T+T7j1mqyC9PfZv66vVoY5ANmR1bHSbnfODX8tELHq9Uvfu8U2Uv9bLtHnL4rltIZHCpPPzw9eor
RVzEd6sXgjMNwn2tLTW+KzM8mBT0eZsDdGnBd261pFD4Htlnhx5n5EA5eOuXyenc+nA551gd78/H
Ol6dwa8rOyKRkpMJeXP2fo/ej/Oacj9Cg2jLqBkdPD94B/EuwuuXW1uOp1063d7fcO1Cmf0kARIg
ARIgARIgARIgARIgARIgARIggRYjAGVcXPVu8IibQ8wUodVUy2U4GgKm6CwWVcGp3tdVDr7OtK5c
+wXx1fhg5UYjsxXK2HNhWxgF4YZyzC8ulreOooNbv/dMueo33wiVVCOMXpki3uSmUh2y3ycvkbM+
sl+obDm6+C9y+UUXye9+t6axQaRbOpPhQ6qD1QxrCmkspX78WFWAcxTQ/8QmC+XEXdeUu+Ck/WWL
dHDWQ7CiITjfIliREPTVjffURsbb5cZrZ0IEKyg2Hsf9wBkH7evsfULo3jt9x/Ce2XuHrczgC4X2
fP/a5c7Q4NAud4r9JAESIAESIAESIAESIAESIAESIAESIIGmE4BJodasAKWqpSJO1xgBKD0Dpzw1
HlyG47WGnsZaeeVqmfLdhVNeI9/+2zXy7eNqDhCodm7bw+T0S26R33/6DbJJyrgge0uZlgqK2bOG
MDBAdMu+x58pN//6LDn+kN2qsoaIbf/6t8vXvn+J3P/0D2X7dG0BbFkUdl3lw6zDaYhb+4g7A0Ki
G9GKC9dzY6700wwcM+XA99VuLyWyq7znf7Z3siHTHOI2ThhZgvjYx3vfkrNkOx2vyTL5kSbcD5PV
zqEZGmwMZpCwa4YTQyCioMNv+cS0QqkkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAKvOAFTuOXzefE9
T1Yt/Y9EVj0vs2/4vMT6X3L98ztnysv7fUlKUzaSjg3mSiyRcvvl1ys1X/HBtGAHTM0GRSfiuVxO
D4v25PaHX5ZB3Tu+Mx2TzlRcdttyhnRoiBnp4Aqlczs4e348fXYwc7yvr8/NFkeIMSM9ku+VpS8t
k5V6SHYmk5H01A1k9vQOiZV5OCWwPn/5YkSmzZouaTUAdHV1OSU/WCAf8iA/m806jlDQ+/kBWb1q
lazqz5XLJqRjyhSZPXOmdHckHUecqQAZcMYfs9n7Vy139yHV0aHcUzJF62G1AcpDNvijvM18r4xr
5bKaej09Pa4eVhSgHfQRfvXq1W7sCAu5fu1/VnyVifIpbQft4V7j2gwM6CPeQ7Rp7TU6XrsvJq+/
v7/h+5Ep9xN8cE5Guz2f4AqmYAKey/X8lAv//Lzb0uywBbNleldKZvZ0SDwWnKmB8mFjEK7pxkeA
ZziMjx9rkwAJkAAJkAAJkAAJkAAJkAAJkAAJkEB7EoBeVpVyzocXMiAJWRiV+0CErlECQJtQ5WYh
VtIwoopOW+XQnnBNoY8QilrzUPAiXkr1yIZzp8tGmm/KdVMAV+qoIjuh+ThIGWmWDhmImwEAIQwQ
cPFUp8zeaIpsUFfHZZY/UBZ9gAw4kxtJpKUrnnLGAuSbs3JW1kKku7rJTKWepYVDN97yuBGHjyU7
JN0ZrFpIlPuCcSAvXBdtufLlPIs3Ol7XX7Rfljee+4G+tbvD+OH0Tko6oYYsvdQ75K75xTaxd5cG
h4nlS+kkQAIkQAIkQAIkQAIkQAIkQAIkQAIk0LIEYu6w2VrFN66iqiAvqVcNqVOStuwAWrRjUHaa
j0UjMm92Rjw9wwGGh2RclcLK3fJbdAhr7ZYpz7FCADPhbaY/VnSYwhwCEIciHEpwOMThwvWRBxmm
cDdFMWSiPGRg5j6ctYOycKiLMvBIwyoCOMs3uZipD7mmjLcQ5ax+uB5WMKCMGUqsfDhEPXOQj7Zs
5Yf1A3xQxzhZeygLhz4hrbOz07UFmY2M1+RBJuqj3wjHcz/Q7zAbyG43B74pPaRmwdwuZzvtSev7
p49i+N6125jaob80OLTDXWIfSYAESIAESIAESIAESIAESIAESIAESKDJBKCMg8oUHvFaZzm1qbwa
OwG1N+gM66ionUE0cCsc2l3haf2HshzPDhTeSIOiG2lQdsMhDmflLUR62JsiH/nwuIaDXBgZEKId
k+sy9cPKDxWijLUPeahv7VjbJqc+NHkj1bNyJg/9tDYhE9f1baKOOcStLsqNZ7wmC7Jh8AC3Ru8H
+hTup/W33UKMAQa/nkxC7z/ePTwTOor6r7t2G1iL95cGhxa/QeweCZAACZAACZAACZAACZAACZAA
CZAACTSLAJSu5qGBKxR1Fjl8qAEo6XReuurkuLohhGVMUVPWQnEb162UZnQmAmW5gg7SAoU7ylnZ
MTXwChW2vkI5DodnCUpypMMYgJUBCKHsRp4prm2cVt+uTUFvMlAe9bAiAHLsGisc7LlFaK5eDhTt
qAMPh35CjvUXachDOdS1ckiHwzXSbRzh/HA9k4c060+4v1D0w1k7GA/Kop71GfkY91D1Rzte9BNy
4SEX8iEP1+iPjWOs98P6CTnt6sADDluYbTw15bhkUgnHKKpGiPB9aNcxtmq/aXBo1TvDfpEACZAA
CZAACZAACZAACZAACZAACZDABBOASi5sbKg0B2VdWWFXSWNkzASg1ITS1p3bUFbeWpopRMcstIUq
2BhMQQ1lN7ylW4h8OFzDWxkzNFi6haY0Rz0ozqG4R5op8g1BWNGOutYPxMPtQQaclbd2XGLdh+Wh
LORZXyzdZFs1S3f3WQ0IZnhAPtLMWzmrZ6GlW3uNjjfcL+OAvsNbnoXIh7O2rUz9/bA+tmuI8YEr
tjGDCwwNwbjbdUzt0G8aHNrhLrGPJEACJEACJEACJEACJEACJEACJEACJDABBCIlXd2gPuwwf1zV
dPqps7fDGYyPSMAUuqbIhbITccw0h1IXzpSgFo4otAULoO9wUFDDYZxwNpMecRsv4igPb4ptq2/1
TAGOsnCWjhB1zJvhIChVlYtryDQ5Vt/6YOn17Vo5k2fXNq6R6pl8K2/1Ld3aq8+39iwfBhU41Lex
IhzteK2fJtf6Md77Yf0zua0eWn+No713lg5OiFvY6uNp1/7R4NCud479JgESIAESIAESIAESIAES
IAESIAESIIFxEIBCE2pjeFOQVsSpUk41c5VLRhojAOUm7AyeHyiPo9GYm2WN+eWmBG1McmvVsrGY
ohuKcktDTy1u+XZt4XCjQT68yRuufL1ck2fl60PLHy6sL2/XI5W3ftj7NFK9enkoD9/oeE2etWv9
MXnD5Vt5C61cO4c2lqK+gFkvMFp1pGN6YDu/1yb6vtLgMNGEKZ8ESIAESIAESIAESIAESIAESIAE
SIAE2ogAFHV2hgMUlqa4a6MhvOJdNWaYSV1Q5fuSZTnxCrqnvm7tktKTo+fO6tJZ1u3PNjxOQDcF
92hvgNUfrrytDDAFvoVWvr5+/XV9ueHyhytn5S20chZaen1o+RZavl3Xh5bfrPHaiodm34/6frfq
tY0bYdYryj1P9QoMDwu3mC4dKd1iqWzYMe6tOo527RcNDu1659hvEiABEiABEiABEiABEiABEiAB
EiABEhgHAUz0dQpcrHSom/Sr86xVcl3iONqazFV1brUM5HzJeb506gxrsIbyk27sBCabgniyjXfs
T8Taa4BfUV+11YOerhopiafeneaB149fb2uHN45cGhzGAY9VSYAESIAESIAESIAESIAESIAESIAE
SKAdCcDQAB/xC87Xj6GEveTV042PABgXdGXDsr6cDOZ9yebjanSIi6+KT2fsGZ/4lqs9UQry8cpt
tP5Y6421/HA3sNXkDNfPVk23dwthvuDLM0sH9J0ryoAaHtK6sqiUdJuatWr3275fNDi0/S3kAEiA
BEiABEiABEiABEiABEiABEiABEigUQKY6ls72151dME2Sjo7GHG6xglA4VksFZ2BAUYGz/el4NOQ
0zhR1iSB0RPA+wfv+cE7iHcRnssbRs+wkZI0ODRCjXVIgARIgARIgARIgARIgARIgARIgARIoM0J
QBGHmdTwiNe4iCrF4cvOytk1w7UTMJ44rBfe11UOvs60Lqomzl3ryhK1PVTOPGjWjPa194q5JLB+
E7D3DiG8ry8ZfPAewvgX+EKhIBI6Q4XvX3Ofi+pfjubKpTQSIAESIAESIAESIAESIAESIAESIAES
IIEWJoAtzE0xF97OHMo3zAF284A1TtcYAVN+YjZ1wBlywvHyGRqNiWctEiCBEQiYwc+K2fedXTOc
GAJc4TAxXCmVBEiABEiABEiABEiABEiABEiABEiABFqfQFGn2cOv4TBHNVpZAbFGNhOGJGBGBlNs
YiZ1oYADazHLGtspifOmCLXyQwpjIgmQQEME8H7h3bIVDhrVaxHP89RH9V1MSFFtqfb+cYVDQ5iH
rUSDw7BomEECJEACJEACJEACJEACJEACJEACJEACk49AeHOlcHzykWjOiLFGJKHbtxRiJQ0jEldv
BonmtEApJEAC9QQqxgRdVZRO6Kot/TKLwoiq/9TUUF+c100kQINDE2FSFAmQAAmQAAmQAAmQAAmQ
AAmQAAmQAAm0EwFsnuQ2UIqqEg4eWjm4aCLwwRU/x0jADAoIY8p13uy0eLq8IRGLSTIelVgk2GPe
lKJjFM/iJEACoyCA9ysVj8iCuV3OxNCTjkoyphubcau4UdBrvAgNDo2zY00SIAESIAESIAESIAES
IAESIAESIAESaG8CsYSU4inxMjPU9ICtRvRQ1Y6ZlQOjqZgb/+2FHSediIraGSShF1jhQK7j50oJ
JDASAbxnMPj1ZPR7Tm2pcTU2RLFbHBc4jIRuXPk0OIwLHyuTAAmQAAmQAAmQAAmQAAmQAAmQAAmQ
QPsRcApvNTZ4HbPFi/XI0gWflKKeNRBVbVwskZSOzpmSiMd5hkODt9YMCuAZ162UZnQm1Zijx3Bj
IYlL081dNEQ5K9tgU6xGAiQwBAF7r2Dg23hqym1jlkklJKarjKJqhOC7NwS0JiXR4NAkkBRDAiRA
AiRAAiRAAiRAAiRAAiRAAiRAAu1CAMo2KLzVuqDT7kX8zllOIY7jo4uqkIPRAYo5c6a8s2uGoyNg
nN25DeCtztLIdHQMWYoEGiVg7xq2MYMLDA3cUqlRnqOtR4PDaEmxHAmQAAmQAAmQAAmQAAmQAAmQ
AAmQAAm0OQFTcpsiLpVKSVxXMvi+7wwOMELAJ5NJl26z8Nt82Ous+2G+xhgheNp5DeF0Z/RZZ71j
QySwfhOw9w/vFd43e+8sHUZUxC1cv2m8cqOjweGVY8+WSYAESIAESIAESIAESIAESIAESIAESGCd
EzDlGxqG4g2KORgdECIPyjqkm7EhXH6dd7bNGwQ77B3v+Xo2hm6pFI0G27lg7Qi5TtzNzS59RG7/
6yLpy4t0zdlB9t1rG0lPXHNrSH6l21+jQ5Mwwd6vor6AWS84pL0jrau39J2km1gCNDhMLF9KJwES
IAESIAESIAESIAESIAESIAESIIGWI2AGBnQMivDwNRR1WPkAgwPScW3Ku5YbSIt2yHjBcFNQvkuW
5cQrFAVbu6T0AOm5s7rUqBOc4dCiQ2jLbtkqkkWXfFjedNLt5THsK39ddavs1j3xRp5Xuv22vGkT
0Gl8d8EhzHpFueepXoHhYeEW06UjpSu4yt9p9p5OQBcmtUgaHCb17efgSYAESIAESIAESIAESIAE
SIAESIAEJjMBW8UAxbg5KOEsnQo5o9J4qHOrZSDnS87zpVNnWCtep/xsXCJrjkQgkdo4VKQHx5Ss
U/dKt79OB9vCjeH7q6grjFYPempYLYmnXo9uF30l1frUwh1v867R4NDmN5DdJwESIAESIAESIAES
IAESIAESIAESIIHREjADgs0AHu31aOWzXC0BzHgv6MqGZX05Gcz7ks3H1eigZ2ao4tNmw9fW4FUj
BIwlziKBK/hOrVwWpVvq+AW9D+JW7CDRnvtygXEHr3T74x7AeibA7gfCfMGXZ5YO6DtXlAE1PKR1
ZVEp6TY1W89G3TrDocGhde4Fe0ICJEACJEACJEACJEACJEACJEACJEAC65SAKV7NAGGNW7pdM2yM
ABSexVLRGRhgZPBUIV7wg+1eGpM4SWsVsrKid9ANPp7JSHd66BMZwBs+jhnsIReLFjV9bFPaC9rm
4OCgM1SopUK6u7tlJEVqM9tH9wvZXukdVEsJXDwj07qHHndQgJ/1BOx+eGqAwvuHdxGeyxvqSTX3
eqT3pLmtURoJkAAJkAAJkAAJkAAJkAAJkAAJkAAJkMArTsAMChbWGxxe8Q62eQeg6ITD+Rjwvq5y
8HWmdVE1ce5aZ9xjMr5xt/vQ5sNuWvcDfgV55NbL5Pwf/VzOvPK2Wtmv3k8+9+5j5egPHinbTIs7
pv/58/nyse//WTpnleShC34dKv9H+dB73icLuyKSLe/t39+1UM48+0TZPBEYIex+Lf333XLNNVfJ
lX+4Wq68/aGQDER3lEOPO0I+cNyxcvAuG9Xk4Z6Op30T5vqRfV5u+PXF8n8XXSwX3/agZQWhjvuk
D3xEjjv6UDduPje1eOw+IoTHihf44D2EwSHwBSx3CZ2hQo61HMd7FVH4dTa/8YpkfRIgARIgARIg
ARIgARIgARIgARIgARIgARKYvASg4ITKDYrNvmxBbl30kttSqTujWyqlYrLAHV4brxzKbYaHyUus
duSl0kty4QkHygfOr1O41xbTq3fLAwMXyXYJX+770eGy2ylXrVFi6IRD9SDpK+R1PWWDw/IH5Rsf
eI185cqhS9enHvrdm+W3n9q/suIB9/u+Hx0mC09urH2Tv/zei+WIXd8jdeYVy64Jz7zjOfnEXuGz
KmqyJ+WFqbnt/cvlcrJctzO74E/PuhUOR+6+sUzvSsm0zpTE1eAQ15UrcDQ4NPdx4Rqu5vKkNBIg
ARIgARIgARIgARIgARIgARIgARJoOwJQ1Jmyru0630IdNo4WwuBQKODAWsyyxnZKel2ZcR0YJci9
egON21//96g1jQ077CP77LNPtbCL6ZZDatBxM9mLK+vy1na5UuuU6+n9eOBXXxq1sQFSr/zMG+Tb
d7xYnjlfdIalgj/29oOZ98EqmGX/+InMGMrYoGM+eJ8d1hjMSXtvImf9NejDGpmTPMG42goHTLeH
9zzPecu3522S42r68LmlUtORUiAJkAAJkAAJkAAJkAAJkAAJkAAJkAAJtAkBVbqWdHZ2pJhzGrmS
RCSCbWcSHZj22yaDaO1ugmJCZ1MXYiUNIzqzOuKMOzQ0DHPfsg/Jdz97eyjzHXLZfafJm7eeFaRl
V8rj/7xJzj75GPn5olUSK68m2f6d58h1Wz8nsXRR7r7gVPnSrx8py5gvX7vodHndtKhEUyndxsrX
x3tT2bGzamTLqzLa3A4Hf0o++/EjZM9XbyEzdSa8HqQgLz+7SH7++f3km1dbKZGvfv8K+cieH5Kp
0GSr2+FdP5br5z+nbaD9U0bVvkkrDT4on1jwYbt04d4fO0/OPvVwmTcrOLchu/QxufCb75VP/nxR
pdxJe5wph/rfks0rKYwYAXu/9BtN0rp1lh7hIPoE4BtOi4RuuFVg2DQCNDg0DSUFkQAJkAAJkAAJ
kAAJkAAJkAAJkAAJkEB7EHDKOJ1xX+pfJpLrk9Iz/1TFqhodEkkppbpEtthLJNlR2WqEW46M7b7a
zGmEsWhE5s1Oi6dnOCRiMUnGoxKLBMpuU4qOTfr6V9o4YEXI4BP3S3hjos9e8TXZe6OM9PX1lQce
l013OUROv+N5+XJvSaYmcpLL6d78mY1l+52muNUGg9tvoWXN4LCF7LTjVjKvMy5dXV0S03uQ1kOn
I/m8FMpb6kzf4QA56qit5NATPyhv3HaO5DWvVPK0Tc8Zh9KztpGP/eTP8uwme8kvDf9V18rilcfo
2RD66mi/ix2buPYxi36k9jN68HVU6+Rh7FPD3qOXnyMXm1wNX//Zy+SyT+4PwdLb2xu8h5mN5L2n
XSszCm+UY375cLn0d+TSuz4hn9lztrvm1lwhiBrFc5WKR2TB3C5nYuhJRyUZ4xZKtZSaf8UtlZrP
lBJJgARIgARIgARIgARIgARIgARIgARIoA0I6CxfT40MuQGR1f8VWfmcyKoXRHqX6snGeqgqXVMI
qL1BZ1hHJaOazozOtIYClAacodFCQez1v1yTmdBFBtgCx7bHQRwKft9PSE9Ph8tDPaQjhM9lwzPY
+9WAUFvfDhK28nNed4ycf/6X5aD5swLjgcqqtqNbYWl7BZkrR33zjaG+6YqV8pX1zeSNpn3UgSuV
/i0/fd/PypIQvF++ccLeUlLDBfoAb1sBYcxvOvkzsn2o9CU33e/GHEpitEwA7xkMfj0ZfVbSCV1d
hIPaNTP8eJBW0wlwhUPTkVIgCZAACZAACZAACZAACZAACZAACZAACbQmAShE4aDsLMHYsOI/amR4
XuL3/15kcKVEMlNFpmwk2S32kUgsI4lEoFKlgnxs99N4YcZ5XLdSmtGZdIpj7OYSpOnmLpqHclZ2
bC2sX6XNWADFfnLO1rKnDu+u8hC/8eZPy7Z3flN2nZ1yqxPAC4f9gh+eZ1ybAQGHBEM5X/DDGuWi
GhywCiLmnmeUxSoHeLQLF66PNPQDspEedsW4Wj8qzpfc4KBk1YCEsqiHlRFjaR+iCs/eJ2dXZIrs
/vm3yaZ+v/T3BzKRZe+te146XyPvPkjk8zcGlRbd/qAs/cJ+Ml058H2tgrT3CluYbTw15RhmUgl3
36NqhHAslRld8wnQ4NB8ppRIAiRAAiRAAiRAAiRAAiRAAiRAAiRAAi1NAApMnN1Q8j3VeOZFsrpt
i/pSJKZbKvViSrlT0KGcKe5aekAt2jmwCwwMqpR2U6uD7VzM2NCi3X7FugWlfXH65rKH9sAMDnpE
s7zr9VfKUZ86Q45924Gy5Qa6h1HZmSLerhsN3fuAd6LsnRw1OvT1r5Zs1nPvAGwNzz9p2zShRNWo
gX5b3dH0ycqi3sDLtSs6VqxcIg8/FhVvUN/NsgvLTCSy8uxqy9GwW5XoaL/8fIVyJn3U3j9sYwYX
GBq4pdJEPxg0OEw0YconARIgARIgARIgARIgARIgARIgARIggRYhEFZ0FnX2djGflYiudEA65vpi
vjfUqJilrR9rzMKn8WHtN9L4IDRlJ8JkUs/GUMZw4XQYHiazMybO0KBKc6woKBQ2lKNv/IGcftDJ
NWh+c/qp8pvTRbZ520flcx98jxzw2rlupQN4Wn3M8Me1/hdyemaGrmbAqgjk2+qGsNEnqKOV+p+T
2667Rm66/la55Ma/hmQMFdWVEFhNUaiuVkEbcCO1j3LWbz8arLKwFh758Uly8I/tahShr2dRqHHE
1zGCH+RijJPRYexwuLd4tuy9s3RwMT6WNhk5TfSYJ/e32kTTpXwSIAESIAESIAESIAESIAESIAES
IAESaEECUMbBF/XgaPiwC9KDveMRp2ucQKDUjIinW/zkC6qgLur2P6VAKUqF55pc7bnMzH2r3Hvt
j+WtaxaRR644R973lt1lk/2/Ine/lHcKZLAM+2itxl8V8PGKocGU/ShvRodIxJf7fv0l2XTbPeSY
U741CmMDOoZ3KHhPwm07uSO0Hx7WU3ePZNgIlx4i/kzOHT4NowtdlQDuA1xRv8OyXkkGcY6Hfp0F
ptVqOcaaT4ArHJrPlBJJgARIgARIgARIgARIgARIgARIgARIoCUJmEIXM6KLmJ2te9tH1Kvm1PW3
FNGZweqxF71+uBnCLTmQFu+UKTsxo7qgiuAly/RsATU4YGuXlB4gPXdWlyrAgzMcWnwo67R7tlIB
z2nH3P3ktIf+IR+57w657KLz5MKbH63ty8PnyZu3XSzXLLlW9poRKP4xox1GhER5C52gQlSSqZSk
03H1aWd4QDm7Ryiz6P8+IW888Re18vXqjYcfLVvN3VQyUT3AOVGUe7/1PbmtUsrOWAjuI9odqf2U
9sNWWEBMNpuVGVtuU5GIyIJjvyjHvBaHVwcrFdBPeLDByiNjhLLJSFI2XrCvdGO1UrmMze5HfniM
uJ4sDgzgEGa9otzzVK8zPOw2b7p0pDSvzHSy8pno54AGh4kmTPkkQAIkQAIkQAIkQAIkQAIkQAIk
QAIk0IoEdAIwznFQDaYq4DDzN3DOKKFRzA9GnG58BHQevAzk9IBhz5fONLZ0CWZdj0/qZKmdklft
cqB8fve3yskvL5brLv2xfPZHN4QGf4e85XNXytKfHqLK92DFgimbQ4UkoopnpJs3JT7KlJ6/QY77
SK2x4fgfXiWnHL6bTNEDv6Hg7+/vd9sV7ZlcLLd95Zqy6Np3AzJNfrhtxMPtWzkz/iW7q2dSoOz8
bfeUfffdzBkmqltEBQYHGCjM8AA5MKBgxYbJQn26KgEwKuptWq3nYRQ14ql360Bw6/AFRzchBLil
0oRgpVASIAESIAESIAESIAESIAESIAESIAESaF0CUFq6/d51O6WIejMslHS7H3jkwdONjwC4FnRl
w7K+nCztzcmy1XlZ2e+Jr4pPYz6+FtaP2lAMw0N5HvZIg8OzmJ6xjRx1yk/kn9eeIduFh73oYVml
xgTbnx91Erp6pOpUrp7dAOW9eWsDZfuXPyuLqoXliG9eK199+wLp1m2WoOCHt/chmw1vWxQYI/Au
QQ6MDQjX1j5WQNgqCJRzrno2tLtc/Pizrj23Ckll27uK0AwL1o5dWxgaxqSOGg+E+YIvzywdkKeX
9kufHgAOwx+MgHQTRyD89k1cK5RMAiRAAiRAAiRAAiRAAiRAAiRAAiRAAiTQegSwgiG0igFqOKri
mneboPAs6j7/MDDAe6o4L/hhpXXz2mp3SRUFvA4EBoGwAcFxLCvfp213uHz149tWh7soK4OF4NIU
8dVMxCJSzq5N1ivIffbeO2vSF+6xbUXJbxmm7LfrShh6d5DWSPuZzbeTBRWBIveed508WQgMUuhf
2EN+2LARjof5hcRN6qix8/SdwzkqOHMDnssbJvaxoMFhYvlSOgmQAAmQAAmQAAmQAAmQAAmQAAmQ
AAm0JAHMry74Becru4tEY7rxeayi5GzJjrdBp0zRCUW1m6Guqxx8nWlduVbumDVv5dpgSBPSRVPQ
21ZEWIGQX/aULHp0qcR1uyBsGYRzD1AOrHK5nAwOrpTnnllc7c92uiqimHfnG1hiwRuwqIa3yN2P
r64YA0yW3Yv07E1CZUWWPP2CDAwMuJUNOMsE5ybgXg08dYt877TrasrahY3DwpHat3ru/ndsK+84
wlIQXiFn/ureyrOBMpALRnb+A5jAi8Qq51IYQ5SdrM7eJ4TuvdP7hntn9xoHSMNj9Qjfv4l7Smhw
mDi2lEwCJEACJEACJEACJEACJEACJEACJEACLUcAyjg4F2oc6knEoai0FQ6TWWnp4DThwzhjNjXi
AfZwvHwPmtDW+iICSvMlV50sbz7wtbLpB74jdz3xovi62gHPY/BM5uSB339fTrkyNOJpM6QzgBs8
05o1a6vtQwVEvvXpc+XBVVjnUJClT/5T/vjHO2W5Fyile+bUGhzOPeY7csfTfRVZIjl5/K6LZeFb
PyH31kgd/mKk9q+55i5ZWVl2kZI93/mlGmG3/eAYOfaH18qzK/IVY4MZHHKrXpJ/3n6ZfPp982X+
/I/Kw9nYsGdH1AidhBdmaLChB+8h13AZj4kKeWj0RJGlXBIgARIgARIgARIgARIgARIgARIgARJo
QQJhY0IsCkVu0Emo4SL6AY/EcLkWHEZLdsmMDKbYxEzqQgEH1mKWNbZTwqoSnNMdrHyw8i05mHXY
KTMoIEymNw5avv6H8l71ItvK2961s0wrDchdl/5BHq3r11c+ub+kdBVCQY0Vxn32/F1kvparlF18
thw0/+xQzYPlLy+9TrZNeJJ81UI5RnN+Ucm9Uo59w5XyhnecIDtOz8tff3yB/K2SN7rIaNq/84Xd
ZUsdLwwJHVsdJud84Nfy0QserzRwz08/Iweol233kMN33UJkYKk8/PD1sji0uAMrHCKptDubAnLC
HCuCJmEE7xeeBaxiCFYywLgnbrWK50X1/UtIUb/37P3jd11zHxKucGguT0ojARIgARIgARIgARIg
ARIgARIgARIggZYmYEo2dLKkijmniXMX+gHrAzyMDnRNIaA03SHGOMg4EdMDjNWbYrwpDaxnQjq6
O+tGtFiuuOQSuWAIY8OhX/ytvO8102t4OuXx9AVy6nEwOazdue12klvIR//wnTUK3vzrn8gP6owN
+75515pyBbwrdW4s7VcNBHHZ88Rfyg8+vG+dNL1c/Be5/KKL5PLL640NKNolncnA0IArKs5BIXD2
PaemU0knIpJJqnFH/+GaX3BGaWJCGhwmhiulkgAJkAAJkAAJkAAJkAAJkAAJkAAJkEDLEahXdJd0
1j28c9DD6YoH59fUo7bcWFq5Q8YZIVaRzJudlq03SMvmMzKyydSUxHQZSbhMK49lIvtmDMIrPuYe
ebr844/nyvvfUrstUrgfW+/3Hvnhb26R77x7B7cfv9VHGcjUY6dlr5N/JWedXHM4QlXEkfvLrETO
zX7HKpTO+YfKPTf9So7db+tqmXDsde+QMy7+s/zgW1+Wd1XSOyTu2qokVA50HrH9ow6QDTPl906r
4zyGZHKq7Hf8mXLzr8+S4w/ZrSp0iNj2ex0pX/vBpfLAs+fIa7rilS2VzIAxRJVJmYRnIRWPyIK5
XbJwXrf0pKOS1GNqaJiZ2MchouBps55YxpROAiRAAiRAAiRAAiRAAiRAAiRAAiRAAi1BAMpVKGez
2awUB3slv/gmia7+r0x/8DcSyfdLvnuO+N0byKr9viiRKRtIT0+PO6g2mUy6/lNRt/bbaGo2O5AW
hxx7uofSi6sGdSuloiTU+BDXlQ4zejKSiMdUyZx0ys+4nlMwGZ3xCm+BgzgOa0ZebtUyWbpiuaxc
0Sd5vfZKMemZNk26dMY6HA6ZxkHKXV1dTumONNTv6+tzxgQc+Cy51dK7OicDmt4xZYbMnDFDZk/v
cfLRDt6J1atXu3q4b/nBFbJqZa/k/KjE4xnpnrWBzOpOOHmDg4NS0vKoF+volg1mTtMyceno6HD3
EbIgY8WKFWttf86MKeiqk4Py1l88L3A4LLvoDcrgQL+s7Mu5MUYiSe1/j8yaOVO6M4nKc4OtlNAH
vJv2HE3W99SeJ/ueA89cviBPvdyv91tkQzX2pZJx6cpklKmuONLnBw4M6ZpHYHJ+mzWPHyWRAAmQ
AAmQAAmQAAmQAAmQAAmQAAmQQNsSiKoWDr7iIpj+q55uXARM4euUwbGSzOhMOoU2dnMJ0nRzl9Ce
++NqbD2oDEUxPBT5ZnBA6MVS0jN9jnRPmx0YIFSBjHJQ0sOZwQGKduOJekjHNQwOpWS3TNtwuszQ
ayjyoWh2hgitj7KQh7JwUFQn0lNl483mOAU+jBmWbmVVgHR0dzsjAOqZxz1HHPJgSEIf69vPOEV3
zOVZeci3/lobCCPxtEyZoX2fVX1WID+iB1/ncsVKn5Fm/UTbcPb8uYtJ+mEMsIXZxmpoAJtMKjBQ
Rd3ZNTynZqIeDRocJoos5ZIACZAACZAACZAACZAACZAACZAACZBACxNQFW+ld4ibgs4lDrE3faUw
I6MmYEpld26DKobhLK2G96glrv8FoRg2D6W9KdEtNIYIw8p+8DRvin9jbPKcIl/LmSzkOyV+ua7V
s3wLjTry4axeON3asjy0hfJmRICs4dq3dmE4QBlzqBOuZ+lW3vqH0Nq3Mgyr9ykZD+5bYGigQWai
nw0aHCaaMOWTAAmQAAmQAAmQAAmQAAmQAAmQAAmQQKsSKOHQ6KqCE7HqVat2unX7ZUpfhKZ4RogZ
76YcDqebArt1R7RuewZG8DA0wJuyHisPzIEfzjxAGKxYCLamMpaog3zUt611UBflww7XUPCjHuSg
POKm8Ec+4gjhkQe5cLayAvcVMqwMrlHH0uvbt/EhRB1bmdDZ2VnTPlZ6wBkHG1u4LauLcpAVDt3F
JPwwDuAFxvbeWbrxs3ASIlonQ6bBYZ1gZiMkQAIkQAIkQAIkQAIkQAIkQAIkQAIk0HoEoKYMq2Gh
mDPlXOv1tv16BJaq95SCWnGKRSiZsT2OKprBvawkbr9RTXyP7Tk0RhaGFe+Imw8rkFHWFM7YagkG
ADMcID0sG3Eopm1LJij4LQ2jRPmwCxsKkId24c1ZeYQmd23tW3nUR7s2DvQH9VE37Or7Hs5jvJYA
WMEVlWPWCwxZmbTer3J6bWleNZMADQ7NpElZJEACJEACJEACJEACJEACJEACJEACJNAGBKDMhCbc
9wtSUm9Gh5Ke3wBvis02GEpLdtGUnVAgF4q+PPlyVg+P1pnvcZ2dn4jJ3FldqlwOlN8tOYB11Cnj
ZAp6rCAw4wBCU7y757XcJ9QxAwHKo64p6lEEZbFiwOojhCEBDmXhUQ9yrF2sWEA9mxGPOrhGGeuj
lYcca8/aR3+Qj3oIR2rfzmxAPXOoa/3BCge0b97KQDa8jR/9RR3rj5Wb7CGYwCHMekX5+9O9zvCw
cO506UhpXpkjWNI1n0D1qW6+bEokARIgARIgARIgARIgARIgARIgARIgARJoUQJOoap9g8oN8bDD
FVVxYSKNx8FyIKcH/Xq+dKbLiuk63o1LX39qmvIXoSnQTeEOZTwc8uBNwW/lLN1omMIZ5dxzXlYs
W3nko46Vs3bM8GBbOKEMnJWzelY3fI1y9eXX1n64LtrHNfqHsdb3A7LhrI6Nw8Igl5/1BHA/dGGR
rB70lGtJPPXuSeIXXD2qpl7T4NBUnBRGAiRAAiRAAiRAAiRAAiRAAiRAAiRAAu1DANuLRMtKVahW
o7rlT0k9jQ3NuYdQJBd0ZcPyfk8G875k80VndPBV8Yk8uoCAKeqhoIfDNfhgBQFCY4V0K4vQykMR
H3ZWBgp5q4vQ6odD1DPDgLUVNnAg38qHZSAd8uEabd/qOyH6Yf2t74flWz9wjbjVtxBpdFUDKjjm
C748/dKA+GrIee1cT1cZRXWVg9vUjKgmiAANDhMElmJJgARIgARIgARIgARIgARIgARIgARIoOUJ
qEJONbJBN6GsRBSeisum3DooPIt6KHfBD7wuctB4rXK8KQ2tJ0JMYW4KfCj+LS08RMsfKg/lLN3K
mZz6dLu2OvXlrE0rZ/Ls2kIrZ6GlW/l6uZZu5S1EPfj68pZvodW3diydYS0BM9x4+v4FRj5slYU1
DjTM1JJq7hUNDs3lSWkkQAIkQAIkQAIkQAIkQAIkQAIkQAIk0BYEoHIrFPUMB/VO/aaGBl8PNIZ3
Roe2GEVrdhKKTjgojuF9XeXg60zromri3LWem4FjBag4Du6fKc7rwyAXNrGAp+Vbev21pduMf+Nr
6fWh1Tf5Vs+uLb++nl0Pl29yRtu+ybPy1r6Fll/fXv21lZusofFCCI+zO+CD9xDGv8C7LbNCZ6iQ
Y3OfGBocmsuT0kiABEiABEiABEiABEiABEiABEiABEigjQhAkRsoc4NOw/TgzA9tNIbW7KopP8Ez
UICin+F4oEinsnPk+7euGa3r9oYj0Cr9GK5/rZ5uBj/rpxki7JrhxBCgwWFiuFIqCZAACZAACZAA
CZAACZAACZAACZAACbQsAVO8RXXGL7y5CM5vcL66V77lMRyZgBkZjC9mUhcKOLAWs6x93U4JWypV
Vz5Y+ZElT64SzVK0j1bOaMuN9S40KrfRemPt3/paHoYGvFu2wgFfcfCe56mP6ruYkCIWcpW/+8i7
uU8CDQ7N5UlpJEACJEACJEACJEACJEACJEACJEACJNAWBHTTEbeWAesZEIeD4g0eV1zn4JCM+wMc
E7p9SyFW0lAPOlZvBolxC6cAEiCBIQlUjAn6TZZO6LkY+qUW1X/6Daflg++7ISsycdwEaHAYN0IK
IAESIAESIAESIAESIAESIAESIAESIIH2JIADVINDVIP+6xG9Ak83PgJmUEAY0zMx5s1Oi6dLGxKx
mCTjUYlFgj3mTSk6vtZYmwRIYCgCeL9S8YjsunmXMzH0pKOSjAWG1aHKM605BGhwaA5HSiEBEiAB
EiABEiABEiABEiABEiABEiCBtiIQnueLuC5sqLhwvJLISEMEcAZ3OhEVtTNIQi+wwoFbuDSEkpVI
YEwE8J7B4NeTSbgtleJqbIjqe8gFDmPCOObCNDiMGRkrkAAJkAAJkAAJkAAJkAAJkAAJkAAJkMB6
QkBXOAi8c9hKKea8bahkWyytJ6NdZ8Mwg0JUtZtx3UppRmdS941Xzmp8CNJ0cxfNI991dkvY0CQj
YO8gDHybTEu5bcwyqYTEdJVRVI0QfPcm7oGgwWHi2FIyCZAACZAACZAACZAACZAACZAACZAACbQ0
Adv6B520cxwsHlrw0NJjaOXOQakZGBjUmOOmVgfbuZixoZX7zr6RQLsTsPcP25jBBYaG4B1s97G1
cv9pcGjlu8O+kQAJkAAJkAAJkAAJkAAJkAAJkAAJkMAEEDBDA9RwgSouaISzfscHG/zgjKMZFpLJ
pJthbXmWjpCOBEigOQTs/cN7he84e+8sHasbELewOa1SSj0BfqvVE+E1CZAACZAACZAACZAACZAA
CZAACZAACUxGAiVd5aDKOHj3r6w8n4womjXmQNEZkYLupuT5JQ0j4peqRolmtUM5JEACtQTMyFBU
w0PWK8lgvqjvHlZyce1WLanmX3GFQ/OZUiIJkAAJkAAJkAAJkAAJkAAJkAAJkAAJtBQBzPYNO1PG
WVoxGhf9TySmH+rr860cw9ERMH6YSV0o+vLky1nx1OqQjEcklYjJ3FldOss6OMNhdBJZigRIYLQE
bOUQwqxXlL8/3SswPCycO106Ujr/HkbVsh+tTJYbPQEaHEbPiiVJgARIgARIgARIgARIgARIgARI
gARIYP0hENFtR5KdUkx1i9cxSyLFgvjpaVJKT9VVDqoM15Ga4nz9GfS6HwlMPQO5guQ8XzrTgTEH
yk86EiCBiSWA76+ivmqrBz09tL0knnpdbIRlDvrlNrFtT2bpNDhM5rvPsZMACZAACZAACZAACZAA
CZAACZAACUxKApj566uxoXfTPaSQz0l2zu7KoSTxVIfEkynpzkyp7HNOo0PjjwhWlhR0ZcPyfk+3
dPElq9u6wOjgq+KzftVJ462wJgmQQJiAvVsI8wVfnn5pQN+5orx2rqerjKK6yiGmxWlxCDNrZpwG
h2bSpCwSIAESIAESIAESIAESIAESIAESIAESaHECZkCI4GDVZJcUIynxuxJOAR5LpaQU11n40eBw
1RYfSst3DwrPYqkoBT/wushB4zxSteVvHDu4XhDA+wfv6fsXGPmKeo01DjQ2TOQNpsFhIulSNgmQ
AAmQAAmQAAmQAAmQAAmQAAmQAAm0AIGKkaF8EDTOFoDLZDKSTCbF9jxPJBJuZQPSUAbe6rbAMNqm
C1BywhV1VjW8r6scfJ1pXVRNnLv2dfsqNT4YdzJum1vLjrYwAXvvzNDg60sGH7yHMP4FvlAo6Fk1
1TNU+P4196bS4NBcnpRGAiRAAiRAAiRAAiRAAiRAAiRAAiRAAi1PwBTdCKGcg4EBYVxXN8DIgHQr
0/KDadEOmvITs6kDBSg6Go7rJlbKnMrOFr2B7FbbEzCDnw0keA95forxmKiQBoeJIku5JEACJEAC
JEACJEACJEACJEACJEACJNBiBMyIAEUc4h0dHeUZ9zrdXp0ZGrDSAYpwWwlBpfjobqQZGUyxiZnU
hQIOrMUsa1+3U8KWStWVD1Z+dNJZigRIYDQE8P2Gd8tWOGhUr0U8z1Mf1XcxoVvJBQY/yOP322io
jr4MDQ6jZ8WSJEACJEACJEACJEACJEACJEACJEACJLBeEDAFm61msEHZFkrItzKWx7AxAtgtPqHb
txRiJQ0jEldvBonGJLIWCZDASATMmKffZJJORHQ7JTWo6j9cq6lhpOrMHwcBGhzGAY9VSYAESIAE
SIAESIAESIAESIAESIAESOD/t3c3PY5j1wFAH/VRqh73eDyJ4wAO4AT5WATO0vv8kPzVIMvsA2SR
AEFWsRPvxjPt6S5JJHMvpVel0vR0ldRVJVF13uAVJZEUyUOxB+DlfXdMAjWIkEMnZasZD5nRkK3O
l9kwcBz9pwYUcjqdNOWvf3FdVpHaMI/hqq5mkzJtNsVs603RozdkRQIEfiCwe/0tZk35zV+9HUIM
P72elKsoX1P/nfvBij54EgEBhydh9CUECBAgQIAAAQIECBAgQIAAgfEJ7N94238/viM6vz2OeEM8
YT0pEWco83iTAYhVG8WkSwy31Ofdz1JmmxGthp2fRHZJZkHkNJetbRgSJgvgxosuxoOJkEWdZT0u
fi95ReRFEm21iqLQ8bqN6yw/++mbeb6N6yqDrLHA/UtnWMefpxNoAh3x03n6JgIECBAgQIAAAQIE
CBAgQIAAgVcqUG+z1THkl8vlMI78+w/LCBJ0Q3BhHZP/+7Yty7Yv332I4EHcmquBnogxRAbEtPzd
L9+WN1ez8lXcKK1Bh5tVW/7r9+/K++W6fPMu6kLEevWunvW4+L3cXQ95HeYwZr/603kE+SLQUNoI
yJSymM9KZnddXy+G7K79zK5X+s/Wkx+2DIcnJ/WFBAgQIECAAAECBAgQIECAAAECBDZDt+SwVUPd
huHR6nzwuosMh758WHXl+5t1iZf3Ag5tDDa/jKjEfBqRib2WQYf3y+yRHRHL7QYcrMdl7+dSXuvv
JQMOV5EltI7i0Bl4mDXtELibRTBvspM1tO/l/dMICDg8jaNvIUCAAAECBAgQIECAAAECBAiMVqA+
mV+ftB/tgZx4x6tfTrNnsCGnV1dXQ4ZDOrd9G30VPV53m4BD3e1cfp0RiByPJHobQwXFt0RgIYeH
acs66kAMva0Bh1xwU4vDemHDxe9luCLi2snrb9vz+ptF4CFr0wwBwMhyqNfqdnGTJxQQcHhCTF9F
gAABAgQIECBAgAABAgQIEBiNQNzELu2y9DHUT9Otht3uJvPS5E3y6VU+dj+aQznXHa03NWvgYb2O
seWjLebTYUik6+00P6vL5rwsKp1VGupnOT9bFpxuu0lZxHSW563JAek3zXpc/F42wbm8InJosqyb
koGGJq6nbBlw2DcaZvjzpAJqODwppy8jQIAAAQIECBAgQIAAAQIECJy/wFBPYH1Tyu/+vZSbd6V8
89theJ7pn/1l3A1/W7pf/H1p5gs35448lTVjpE5Xq9WQpZDuWcj2Q9Z2iNc3MaRSDIx0u5UcX34a
AZ/rxTxulE7LVYw5nzdINxkOm/XWkenw4UN8X/6XQaNo1ltGdgMXv5e7wEJmNyyiDkpeT4ur+W22
UV5Pajfc/pPzLC9kODwLqy8lQIAAAQIECBAgQIAAAQIECJy5QNQSKO//sOl/+F08UV9K9+bLHMcn
Xv+wfsCZH81Z797uU9WZOJJPX/d9PHndtbHfd5kks3gke7ghGk9l7481n+9n0WNOaa42T3LfBRys
x+Xud5QXw2v+vUyHrIa4XrbTmmGU19butXjW/2iMeOcEHEZ88uw6AQIECBAgQIAAAQIECBAgQOAQ
gXqDehja5/0fS/M//1ZKBBvm//2vwxBKq7/9x1K++mXp//zX8bUzTwIfgruzbL2pWac5lEu1z8+y
HkO2Or/O2/kKLwkQOFIgr6vsGWjYDTZkJlC2et0d+fVWe0BAwOEBILMJECBAgAABAgQIECBAgAAB
ApcmkDe4+3i6frJ8H0MqfV/6D9/GIcZNutWHUmKopaFY8Xa4nks79lMdT73JWW+G5jnIm6G7wYY6
r05/bF/rd9X5dfk6rZ/vT623L7J5z+WyXR66Lj5+9D49VkDA4Vg56xEgQIAAAQIECBAgQIAAAQIE
RiJQb2pnDYF8nRkOffT5elmadlMwOkf2Wa2jNsAqC0nHsErxFP4QeIgnhfMJfe14gQwsZKsBhsVi
cXse8vN6furT2HVan8jO+dmttxk6isumVkH9ndQpl0+7pJP2/AICDs9vbAsECBAgQIAAAQIECBAg
QIAAgbMSGAIPEVDooo5Dk7Uc4mZ2Zjjk3+xdFDZuIjihPa1AfdK6DqlUh1raDzjU5Xa3vvsUvvXu
ZLhshg/adUid3fd+L3e/F6+eX0DA4fmNbYEAAQIECBAgQIAAAQIECBAgcBYCGWjInje8+6wjsFyW
yWpVFtu9a9cRhFhF9kPMywyHXDafCq43xHdvYp7FAY1kJ6pbzRSp76vr/mHUJ7HrcnV+fW+9+wWS
uWye3K8Ofi8bgR+7jqqP6fMICDg8j6tvJUCAAAECBAgQIECAAAECBAicrUDesM7shrwxlLduY8Ce
e/vaxfzJkPVw72Nvnkhg/8bwY7/Weh+X4sLl4wI+PYWAgMMp1G2TAAECBAgQIECAAAECBAgQIHAC
gQw0DMGGbaZDpDqUoW/3JQZSKkOP+ZHeMCz7Y0/Tn2D3R7/JemO8Tg89IOt9XIwLl48L+PSjoPxh
AAANp0lEQVQUAiplnELdNgkQIECAAAECBAgQIECAAAECJxYYMhu2AYj7A9SceMdsngABAgRGKyDg
MNpTZ8cJECBAgAABAgQIECBAgAABAscJ1EyHSGOIL7grDh0DKcXgSm4XHadqLQIECBDwfxC/AQIE
CBAgQIAAAQIECBAgQIDAKxTIoENmNtRMhyTISg73qznkpxoBAgQIEHicgIDD45wsRYAAAQIECBAg
QIAAAQIECBC4GIGa4dBH4ejs2TLQMG0mQxd0GEj8IUCAAIEDBQQcDgSzOAECBAgQIECAAAECBAgQ
IEDgUgRqhkMez5DpENMMNuRrjQABAgQIHCog4HComOUJECBAgAABAgQIECBAgAABAhcgMAQYurb0
0YcAQ9OUdttLTDUCBAgQIHCogIDDoWKWJ0CAAAECBAgQIECAAAECBAhcjEDmM2wHUIqaDkOgIYMN
+VojQIAAAQIHCgg4HAhmcQIECBAgQIAAAQIECBAgQIDAJQhkHYe8MZQ9X2ebNNOhD2/8IUCAAAEC
BwoIOBwIZnECBAgQIECAAAECBAgQIECAwJgFanAhx1HquiwanZkN29oNkd3QRJffMOYzbN8JECBw
OgEBh9PZ2zIBAgQIECBAgAABAgQIECBA4MUFMqBQ2yRCC03f1bel65uh5zK7y90u4AUBAgQIEPiE
wOwT88wiQIAAAQIECBAgQIAAAQIECBC4MIGa4ZBhh93Xu4WiBRsu7KQ7HAIECLyQgAyHF4K2GQIE
CBAgQIAAAQIECBAgQIDAuQn0OaRS9Ns2nZaSXSNAgAABAkcICDgcgWYVAgQIECBAgAABAgQIECBA
gMD4BbJwQ1RrGApG36/boIbD+M+uIyBAgMApBAQcTqFumwQIECBAgAABAgQIECBAgACBEwv0Ubuh
JjTk62xNmQz9xLtm8wQIECAwUgEBh5GeOLtNgAABAgQIECBAgAABAgQIEPg8gfsZDlE/OiIO8Vl2
KQ6fR2ttAgQIvFIBRaNf6Yl32AQIECBAgAABAgQIECBAgMDrFRiKRcdQSl3XliZ7UkSgoY0XXfTp
JDId4v1uf71ajpwAAQIEHisgw+GxUpYjQIAAAQIECBAgQIAAAQIECFyYQAYahmDD7XH98JPbWV4Q
IECAAIEHBGQ4PABkNgECBAgQIECAAAECBAgQIEDgYgW6qN2QPVqOojRp4tnU6EZUGkj8IUCAAIED
BWQ4HAhmcQIECBAgQIAAAQIECBAgQIDAJQj0EVao+Qz5emi1hsMlHKBjIECAAIEXFxBweHFyGyRA
gAABAgQIECBAgAABAgQInEYgazcM9RtuN5+Bhrt8hi5CENk1AgQIECBwjIAhlY5Rsw4BAgQIECBA
gAABAgQIECBAYOQCGVbIzIb8bwgxRHZDDT9ksWiNAAECBAgcKiDgcKiY5QkQIECAAAECBAgQIECA
AAECFyLQRP2G7LVNJtMo5DAtGXAQdKgqpgQIECDwWAFDKj1WynIECBAgQIAAAQIECBAgQIAAgQsW
uBtYaXeQpQs+YIdGgAABAk8uIODw5KS+kAABAgQIECBAgAABAgQIECBw3gK1lsOmYsNdhkMOrrQd
YOm8D8DeESBAgMBZCgg4nOVpsVMECBAgQIAAAQIECBAgQIAAgecXqDUbhi3lm6zdkH033eH5d8MW
CBAgQOBCBNRwuJAT6TAIECBAgAABAgQIECBAgAABAo8VGOozZJ2G6VX0Reli2s0WpUzn0WelmUzU
cHgspuUIECBA4FZAwOGWwgsCBAgQIECAAAECBAgQIECAwOsQyIBDH8Wh2+uflb5dlW69Kv38Temu
flLK/ItNlkNQKBz9On4PjpIAAQJPJSDg8FSSvocAAQIECBAgQIAAAQIECBAgcOYCGUCYRPZCtvbq
y/K///BPZb28Kd3yQ2Q1TMviq5+X+eK6fBlZD9lyeUGHgcIfAgQIEHiEgIDDI5AsQoAAAQIECBAg
QIAAAQIECBC4JIEMOkxm89K/+ToyG9ZlfbUaAgvX129LM58bUumSTrZjIUCAwAsKCDi8ILZNESBA
gAABAgQIECBAgAABAgROKVCzG+YRVMjXb97EMEpdV9q2HXYr30+n03J1dTVMZTic8mzZNgECBMYn
IOAwvnNmjwkQIECAAAECBAgQIECAAAECRwvUIEJOM/CQAYf6WQYbhuwHRaOP9rUiAQIEXrOAgMNr
PvuOnQABAgQIECBAgAABAgQIEHgVAhlQyJbBhL7vhwyGnObnOc2erWY+ZOAh59WMiGGmPwQIECBA
4AEBAYcHgMwmQIAAAQIECBAgQIAAAQIECFySQA0+5DHNZrMh2JBZDtlqoCGX2V1umOkPAQIECBB4
QKCJCPYmhP3AgmYTIECAAAECBAgQIECAAAECBAhchkANMNRpvT1UgwwZeMhW31/GUTsKAgQIEHhu
ARkOzy3s+wkQIECAAAECBAgQIECAAAECZyqwH1DYf3+mu223CBAgQOBMBWQ4nOmJsVsECBAgQIAA
AQIECBAgQIAAAQIECBAgQGBMApMx7ax9JUCAAAECBAgQIECAAAECBAgQIECAAAECBM5TQMDhPM+L
vSJAgAABAgQIECBAgAABAgQIvJhA1nCodRxebKM2RIAAAQIXJ6CGw8WdUgdEgAABAgQIECBAgAAB
AgQIEHiEQAQZyvJdKV0XCzdZIbqU2aKUSTyfOnHL6BGCFiFAgACBPQH/99gD8ZYAAQIECBAgQIAA
AQIECBAgcKkCNYthmN5EsOE//rmUm+9K07elzN+U7le/KWXxZWne/jyCDtOIQUQQQiNAgAABAo8U
EHB4JJTFCBAgQIAAAQIECBAgQIAAAQKXIjAModSuy/S735f++2/isNalWfykdDfvSzONLIcS2Q8a
AQIECBA4UEDA4UAwixMgQIAAAQIECBAgQIAAAQIExipQMxzW63UEGr4ts//8l9J889vSL9+X/ouv
S/f135TS/kUpX/xJaeZNmU6nw6HKdBjrGbffBAgQeFkBAYeX9bY1AgQIECBAgAABAgQIECBAgMBJ
BYbshqzf0Helex/DKX14V5rVH0sfQyj1kfVQsmddh1xGI0CAAAECBwgIOByAZVECBAgQIECAAAEC
BAgQIECAwBgFamZD27YRS+jKcrks/c1NmUdQIas0DPOjXsNytSol+iw/j+XqejIcxnjW7TMBAgRe
XmDy8pu0RQIECBAgQIAAAQIECBAgQIAAgVMKZNCh3wYUMqhQgw75eQYlaqChTk+5r7ZNgAABAuMR
kOEwnnNlTwkQIECAAAECBAgQIECAAAECnyVQAwqrbSZD30ZGQxdDKEXL4ELX9jGsUh9JDqsyncxv
azh81katTIAAAQKvRkCGw6s51Q6UAAECBAgQIECAAAECBAgQeM0Cu9kKQ4ZDlnHY/leGHIeIPWTQ
IbpGgAABAgSOEZDhcIyadQgQIECAAAECBAgQIECAAAECIxPYrcOQwyaVdWQxxDFkz9BDtvV2qKWs
4bAboBhm+kOAAAECBB4QkOHwAJDZBAgQIECAAAECBAgQIECAAIFLENgNIOy+3j22DDvIb9gV8ZoA
AQIEDhGQ4XCIlmUJECBAgAABAgQIECBAgAABAhcgMAQchiyGLBDdbopGx3FN4r9+6BdwkA6BAAEC
BF5cQIbDi5PbIAECBAgQIECAAAECBAgQIEDgPASa2I3s2XLIpZrhsDv80mauvwQIECBA4GEBGQ4P
G1mCAAECBAgQIECAAAECBAgQIHCZAl3Ucsi+bV2EH/rbEET91JQAAQIECDxOQMDhcU6WIkCAAAEC
BAgQIECAAAECBAhctkCkNwyZDZHpoJDDZZ9qR0eAAIHnEjCk0nPJ+l4CBAgQIECAAAECBAgQIECA
wJkKNFG/Ifu9lmMrTaebvh1nKQMQhle6p+QNAQIECHxCQIbDJ3DMIkCAAAECBAgQIECAAAECBAhc
msBQMHp7UPdf32U47MciLs3A8RAgQIDA8wgIODyPq28lQIAAAQIECBAgQIAAAQIECJytwKRktYbu
3v5lJkMfH2WfTCYyG+7peEOAAAECjxEwpNJjlCxDgAABAgQIECBAgAABAgQIELgkgUxh+FgaQ9Zv
yK4RIECAAIEjBGQ4HIFmFQIECBAgQIAAAQIECBAgQIDAGAWGIZQi0NCVNjIcsu+1SdRwyK4RIECA
AIEjBGQ4HIFmFQIECBAgQIAAAQIECBAgQIDAqAVkOIz69Nl5AgQInKuADIdzPTP2iwABAgQIECBA
gAABAgQIECDwDAKZ5TDbjpx0r2h0bCvrOOSQSjHgkkaAAAECBA4WkOFwMJkVCBAgQIAAAQIECBAg
QIAAAQJjF8iQwv2wwlA0evvpEHgY+yHafwIECBB4cQEZDi9OboMECBAgQIAAAQIECBAgQIAAgdMJ
ZN2Gdh31G7Lv70YT9RuyawQIECBA4AgBGQ5HoFmFAAECBAgQIECAAAECBAgQIDBagYwy1BoOuxGH
SHi4zXu4n/ww2kO14wQIECDwsgIyHF7W29YIECBAgAABAgQIECBAgAABAicXmDZ9lGq4H1XId9PZ
tPTRs46DYZVOfprsAAECBEYnIOAwulNmhwkQIECAAAECBAgQIECAAAECnymwTWXoposYQWkRAYbI
bphfR4ZDFowWbPhMXasTIEDg1Qr8P4urLf4vv+FQAAAAAElFTkSuQmCC

--_002_D216F95ED66FDkwatsenjunipernet_--


From nobody Thu Sep 10 06:49:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0721B668C for ; Thu, 10 Sep 2015 06:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R16qNwSAXV5p for ; Thu, 10 Sep 2015 06:49:21 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 7FE6F1ACF08 for ; Thu, 10 Sep 2015 06:49:21 -0700 (PDT)
Received: (qmail 3421 invoked by uid 0); 10 Sep 2015 13:49:18 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 10 Sep 2015 13:49:18 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id FRpC1r00G2SSUrH01RpFN9; Thu, 10 Sep 2015 07:49:18 -0600
X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=UFRUp7Pj39ziTgDdIlgA:9 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=ZRiEY/SHRJgtULL7QnBWYcpq+qwb51U+nBxU0LkZSwQ=;  b=yKmp/4ROXx1JOBxxbMJ2wH5y4oUD6lxxiXoCYbjBSpkXfbP3zLp3iZswpPEC9ukfH8VyCZ7fFpbHKQSRoVgdY5pzhCT8z+/YHHEaGoUZFwoQxOQetcmIiBUK9Fx2aC2t;
Received: from box313.bluehost.com ([69.89.31.113]:40583 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Za2Dv-0007NA-UG; Thu, 10 Sep 2015 07:49:12 -0600
To: "Einar Nilsen-Nygaard (einarnn)" 
References: <55F141E3.50002@cisco.com> <14fb7371e98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <607103E4-CFE1-4D43-88CE-ECACE0B5B039@cisco.com>
From: Lou Berger 
Message-ID: <55F18A51.9030703@labn.net>
Date: Thu, 10 Sep 2015 09:49:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <607103E4-CFE1-4D43-88CE-ECACE0B5B039@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 13:49:22 -0000

Einar,

On 9/10/2015 8:43 AM, Einar Nilsen-Nygaard (einarnn) wrote:
> Lou,
>
> Speaking as an embedded device developer, I think the point here is
> that up until today there are not very many systems that specifically
> show the applied config in exactly the same "syntax" as used for
> providing the intended config. Yes, the applied config can be implied
> from the output of show commands, but not in a way that is directly
> correlatable to the config the operator intended, by either operators
> themselves or by automation tools.
>
> I completely agree that providing a mechanism whereby management
> systems and operators can easily see the correlation is important, but
> we do have to realize that this will likely be a non-trivial exercise
> for embedded systems to support this in the way the "opstate" draft or
> any other draft intends for the distributed or asynchronous use cases,
> and I speak from experience based on some work we are currently
> undertaking on /similar/ ideas and applying them to existing embedded
> systems.
>

Agree 100%.  I responding to the point that no systems "allow for
observing the intended and applied state separately".  I think they do,
but you certainly are also correct that the format (and UI) is
completely different and there is a real cost in both development and
runtime for support this new capability .

Lou

> Cheers,
>
> Einar
>
> On 10 Sep 2015, at 13:25, Lou Berger  > wrote:
>
>> > 2. An informal round of conversations with some vendors as well as
>> some
>> > tooling vendors show that there are currently no widely known
>> platforms
>> > that allow for observing the intended and applied state separately. A
>> > common architecture includes a central configuration data store
>> that is
>> > being updated by the manageability framework and updates read by the
>> > subsystems affected by the change (e.g. the BGP service or the
>> interface
>> > manager). In this case, there is no other source of configuration
>> except
>> > for the content of the data store.
>>
>> While this narrow statement is true, every system I know about can
>> provide the equivalent of applied config state via show commands.
>>



From nobody Thu Sep 10 07:05:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689741B6875 for ; Thu, 10 Sep 2015 07:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.001
X-Spam-Level: 
X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4frzdoO1WTmt for ; Thu, 10 Sep 2015 07:05:55 -0700 (PDT)
Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 1BF141B6747 for ; Thu, 10 Sep 2015 07:05:54 -0700 (PDT)
Received: (qmail 23824 invoked by uid 0); 10 Sep 2015 14:05:53 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 10 Sep 2015 14:05:53 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id FRlo1r00g2SSUrH01Rlrmi; Thu, 10 Sep 2015 07:45:52 -0600
X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=T0ZuanxOAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=g8glt_vm5sGIaBsDi90A:9 a=U0yag9-1k4-sg18a:21 a=6biznwhQvrb0qiSm:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=aNBAxOREUwVdjM4x1mg6dUCj9RFTl5uaq9MdBstfdCc=;  b=TiphIzIZe1ZyiMH3TMAy5DPoo3/t6e2CgXVJS6gwApvEJ6QmFhwJk9ZI8cGT3HlLxssLJuQYijjQiHIMRIizRDzJ0qbKKLzJmWe/X+eo2akBWgTaViV0W8dHdKM3Lwbb;
Received: from box313.bluehost.com ([69.89.31.113]:38892 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Za2Ae-0006e8-W3; Thu, 10 Sep 2015 07:45:49 -0600
To: Nadeau Thomas 
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com> <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
From: Lou Berger 
X-Enigmail-Draft-Status: N1110
Message-ID: <55F18985.5040603@labn.net>
Date: Thu, 10 Sep 2015 09:45:41 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 14:05:57 -0000

Tom,


On 9/10/2015 8:52 AM, Nadeau Thomas wrote:
> 	The desire from the co-chairs and AD anyways, is that we do not start a requirements draft
> as a result of today’s meeting (and mailing list confirmation of the outcome). As Kent mentioned earlier 
> in this thread, to document this list of detailed requirements on the mailing list.  The motivation for this 
> versus a draft, is that waiting for a draft to completely is a drag on progress, and we don’t want to 
> gate or slow things down.  Putting them in a place different from the existing draft also helps with
> the perceptional issues that were raised earlier.
>
> 	—Tom

This works as long as we break this seemingly endless requirements
discussion cycle that keeps coming up when try to discuss solutions.

>From my perspective we already have documented operator requirements
that seem to have at least have 'rough' consensus. Namely:
draft-openconfig-netmod-opstate-01: Sections 3, 4, 5.
    (note, which doesn't require specific convention-based or
protocol-based solution)
draft-openconfig-netmod-model-structure-00: Section 1.1
    (note, which does *not* include a requirement for /device)

On 9/10/2015 8:21 AM, Kent Watsen wrote:
> Yes, we must have a list of requirements that everyone agrees to.   We
> will subsequently put it into an email to the WG for final on-list
> consensus.   

So should I/someone extract the mentioned section and send it to the
list now so that there's no ambiguity of what is being ased for folks to
agree to in the meeting?

Thanks,

Lou

PS The last time I tried to capture an issue on this list I was
basically told to write a requirements draft, now the answer is the
opposite...

>
>> On Sep 10, 2015:8:26 AM, at 8:26 AM, Lou Berger  wrote:
>>
>> I think another question is if the current *requirements* text good /close enough for a -00 wg document....
>>
>> Lou
>>
>>
>> On September 10, 2015 8:20:34 AM Nadeau Thomas  wrote:
>>
>>>> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder  wrote:
>>>>
>>>> Yes, in my view, section 4.5 goes a bit too far in making a certain
>>>> solution part of the requirement.
>>>>
>>>> The solutions that have been written up have different properties in
>>>> terms of data modeling impact, device implementation impact, NMS
>>>> implementation impact and backwards compatibility impact. Furthermore,
>>>> we need to acknowledge that not all devices are asynchronous. These
>>>> aspects need to be taken into account when selecting a solution.
>>>>
>>>> What is needed is clarity what the requirements are that we find
>>>> agreement on. I believe it is possible to tweak the text in section 4
>>>> to something people can agree on. But as it is written in -01, I do
>>>> not think we are there yet.
>>> 	Is it that you disagree with the specifics of what is written
>>> so that minor refinements would satisfy your need for clarity, or do you
>>> believe there are entire requirements that either do not exist, or should
>>> be removed from section 4.5?  If the case is the former, please be constructive
>>> and provide proposed changes to the text; if the latter, please specify
>>> that as well.
>>>
>>> 	—Tom
>>>
>>>
>>>> /js
>>>>
>>>> On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
>>>>> Juergen,
>>>>>
>>>>> It sounds like you are agreeing with the requirements but not the solution.
>>>>> I think this is a valuable distinction, i.e., that it's possible to agree
>>>>> with one but not the other.  I'd also like to point out that the first part
>>>>> of the discussion is limited to requirements only so we can focus on the
>>>>> former before delving in to the latter .
>>>>>
>>>>> Lou
>>>>>
>>>>>
>>>>> On September 9, 2015 6:01:20 PM Juergen Schoenwaelder
>>>>>  wrote:
>>>>>
>>>>>> On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
>>>>>>
>>>>>>> 2. The requirements.
>>>>>>> If there are still clarifications needed around the requirements in
>>>>>>> draft-openconfig-netmod-opstate-01 section 4, or around the requirement
>>>>>>> that the YANG models need some sort of hierarchy
>>>>>>> (draft-openconfig-netmod-model-structure), like for the routing models,
>>>>>>> ... tomorrow interim meeting is your chance, or between now and then on
>>>>>>> the mailing list.
>>>>>> For the record (since I won't be able to join the call): I disagree
>>>>>> with some of the details in the description of the requirement in
>>>>>> section 4.5. I agree with the part that says that it should be
>>>>>> possible to 'easily' locate the operational state corresponding to
>>>>>> configuration state (and I would add that 'easily' means both for
>>>>>> humans and machines). I would go even further to say that it should
>>>>>> not just be 'easy' but also be 'robust'. What I disagree with is the
>>>>>> part that suggests every 'selector' should be encoded in the schema
>>>>>> path. Note that I am talking about the schema used on a device, I am
>>>>>> not talking about the schema used within an NMS.
>>>>>>
>>>>>> /js
>>>>>>
>>>>>> --
>>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>>>> Fax:   +49 421 200 3103         
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>



From nobody Thu Sep 10 07:21:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8601B68C0 for ; Thu, 10 Sep 2015 07:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.012
X-Spam-Level: 
X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgZ22vAuOPBg for ; Thu, 10 Sep 2015 07:21:10 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 0893D1B4A6F for ; Thu, 10 Sep 2015 07:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441894795; bh=oO7vc5fjNFFOXraRiiPUwOPAHXPL3n4p9b4LFhlMu0c=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=RizCFUDJa2zH5Pekh3hYI6s0UpU4ccoKMYbNIB6FaKMhWLoMvuq9P8JA3rWORlfEk jzd3NR3jryamYX9mp5bxR92OiupNiTpABnJ/riy5TXd3v6raUKnJrF6Q488jmCUAYe iHfJPGF1IpybJnKdQU2IlhIqVeTyLswsT30OftiY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <55F18985.5040603@labn.net>
Date: Thu, 10 Sep 2015 10:20:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <36797CDD-F1CD-44AA-86E5-1EC6717C7BB8@lucidvision.com>
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com> <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <55F18985.5040603@labn.net>
To: Berger Lou 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=12 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1562, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 14:21:12 -0000

> On Sep 10, 2015:9:45 AM, at 9:45 AM, Lou Berger  =
wrote:
>=20
> Tom,
>=20
>=20
> On 9/10/2015 8:52 AM, Nadeau Thomas wrote:
>> 	The desire from the co-chairs and AD anyways, is that we do not =
start a requirements draft
>> as a result of today=E2=80=99s meeting (and mailing list confirmation =
of the outcome). As Kent mentioned earlier=20
>> in this thread, to document this list of detailed requirements on the =
mailing list.  The motivation for this=20
>> versus a draft, is that waiting for a draft to completely is a drag =
on progress, and we don=E2=80=99t want to=20
>> gate or slow things down.  Putting them in a place different from the =
existing draft also helps with
>> the perceptional issues that were raised earlier.
>>=20
>> 	=E2=80=94Tom
>=20
> This works as long as we break this seemingly endless requirements
> discussion cycle that keeps coming up when try to discuss solutions.
>=20
> =46rom my perspective we already have documented operator requirements
> that seem to have at least have 'rough' consensus. Namely:
> draft-openconfig-netmod-opstate-01: Sections 3, 4, 5.
>    (note, which doesn't require specific convention-based or
> protocol-based solution)
> draft-openconfig-netmod-model-structure-00: Section 1.1
>    (note, which does *not* include a requirement for /device)
>=20
> On 9/10/2015 8:21 AM, Kent Watsen wrote:
>> Yes, we must have a list of requirements that everyone agrees to.   =
We
>> will subsequently put it into an email to the WG for final on-list
>> consensus.  =20
>=20
> So should I/someone extract the mentioned section and send it to the
> list now so that there's no ambiguity of what is being ased for folks =
to
> agree to in the meeting?

	That would be very helpful.  However, Kent/I agreed to keep a =
list
that we will put together (we could use your thread as the start) and =
push
that to the list after the meeting to which we will bring a call for
consensus on immediately.  The plan is to close on the requirements =
officially
ASAP.

	=E2=80=94Tom



>=20
> Thanks,
>=20
> Lou
>=20
> PS The last time I tried to capture an issue on this list I was
> basically told to write a requirements draft, now the answer is the
> opposite...
>=20
>>=20
>>> On Sep 10, 2015:8:26 AM, at 8:26 AM, Lou Berger  =
wrote:
>>>=20
>>> I think another question is if the current *requirements* text good =
/close enough for a -00 wg document....
>>>=20
>>> Lou
>>>=20
>>>=20
>>> On September 10, 2015 8:20:34 AM Nadeau Thomas =
 wrote:
>>>=20
>>>>> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder =
 wrote:
>>>>>=20
>>>>> Yes, in my view, section 4.5 goes a bit too far in making a =
certain
>>>>> solution part of the requirement.
>>>>>=20
>>>>> The solutions that have been written up have different properties =
in
>>>>> terms of data modeling impact, device implementation impact, NMS
>>>>> implementation impact and backwards compatibility impact. =
Furthermore,
>>>>> we need to acknowledge that not all devices are asynchronous. =
These
>>>>> aspects need to be taken into account when selecting a solution.
>>>>>=20
>>>>> What is needed is clarity what the requirements are that we find
>>>>> agreement on. I believe it is possible to tweak the text in =
section 4
>>>>> to something people can agree on. But as it is written in -01, I =
do
>>>>> not think we are there yet.
>>>> 	Is it that you disagree with the specifics of what is written
>>>> so that minor refinements would satisfy your need for clarity, or =
do you
>>>> believe there are entire requirements that either do not exist, or =
should
>>>> be removed from section 4.5?  If the case is the former, please be =
constructive
>>>> and provide proposed changes to the text; if the latter, please =
specify
>>>> that as well.
>>>>=20
>>>> 	=E2=80=94Tom
>>>>=20
>>>>=20
>>>>> /js
>>>>>=20
>>>>> On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
>>>>>> Juergen,
>>>>>>=20
>>>>>> It sounds like you are agreeing with the requirements but not the =
solution.
>>>>>> I think this is a valuable distinction, i.e., that it's possible =
to agree
>>>>>> with one but not the other.  I'd also like to point out that the =
first part
>>>>>> of the discussion is limited to requirements only so we can focus =
on the
>>>>>> former before delving in to the latter .
>>>>>>=20
>>>>>> Lou
>>>>>>=20
>>>>>>=20
>>>>>> On September 9, 2015 6:01:20 PM Juergen Schoenwaelder
>>>>>>  wrote:
>>>>>>=20
>>>>>>> On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote:
>>>>>>>=20
>>>>>>>> 2. The requirements.
>>>>>>>> If there are still clarifications needed around the =
requirements in
>>>>>>>> draft-openconfig-netmod-opstate-01 section 4, or around the =
requirement
>>>>>>>> that the YANG models need some sort of hierarchy
>>>>>>>> (draft-openconfig-netmod-model-structure), like for the routing =
models,
>>>>>>>> ... tomorrow interim meeting is your chance, or between now and =
then on
>>>>>>>> the mailing list.
>>>>>>> For the record (since I won't be able to join the call): I =
disagree
>>>>>>> with some of the details in the description of the requirement =
in
>>>>>>> section 4.5. I agree with the part that says that it should be
>>>>>>> possible to 'easily' locate the operational state corresponding =
to
>>>>>>> configuration state (and I would add that 'easily' means both =
for
>>>>>>> humans and machines). I would go even further to say that it =
should
>>>>>>> not just be 'easy' but also be 'robust'. What I disagree with is =
the
>>>>>>> part that suggests every 'selector' should be encoded in the =
schema
>>>>>>> path. Note that I am talking about the schema used on a device, =
I am
>>>>>>> not talking about the schema used within an NMS.
>>>>>>>=20
>>>>>>> /js
>>>>>>>=20
>>>>>>> --
>>>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>>>>>> Fax:   +49 421 200 3103         =

>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>=20
>>>>>>=20
>>>>> --
>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>>>> Fax:   +49 421 200 3103         
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>=20
>>=20
>=20
>=20


From nobody Thu Sep 10 07:34:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C901B337D for ; Thu, 10 Sep 2015 07:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.511
X-Spam-Level: 
X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PG3m8AUJjRI for ; Thu, 10 Sep 2015 07:34:03 -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 A2CE31B2E7A for ; Thu, 10 Sep 2015 07:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1441895642; x=1443105242; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3dj2tW7CrUg8c+EaPGGqthGKhBy3n+a/ugYIz3rcfC4=; b=bW6XJ63W7/KOq6l6rVsCNk6rOWWVGAFXTtHZuVSzEcCleb+EI0Y7bV7O 2mhVx8uN4sQ5qwY/jtU1Q7RRWn5+4mqqG/jFiXudQb7LPnTIEz7uIu7tU 84TMuwJKS/Q6S1/UmPpWK0P4+FFso6ddbXIzC4iYF6NJiurqE1IaVu6ho s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQDTk/FV/xbLJq1diAa/LYJWAoIPAQEBAQEBgQuEJAEBBCMPAQU2CxALDgoCAgUhAgIPAkYGDQgBAReIE7dolCQBAQEBAQEBAQEBAQEBAQEBARuBIoVRhHuBPQGDTgeCaYFDAQSVVox6gUyEM4J8kX1jgh0lgT89iHwBAQE
X-IronPort-AV: E=Sophos;i="5.17,505,1437436800"; d="scan'208";a="605037634"
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; 10 Sep 2015 14:34:00 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8AEY04m024092; Thu, 10 Sep 2015 14:34:00 GMT
To: Lou Berger 
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com> <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <55F18985.5040603@labn.net>
From: Robert Wilton 
Message-ID: <55F194D8.70908@cisco.com>
Date: Thu, 10 Sep 2015 15:34:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55F18985.5040603@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 14:34:05 -0000

Hi Lou,

On 10/09/2015 14:45, Lou Berger wrote:
> Tom,
>
>
> On 9/10/2015 8:52 AM, Nadeau Thomas wrote:
>> 	The desire from the co-chairs and AD anyways, is that we do not start a requirements draft
>> as a result of today’s meeting (and mailing list confirmation of the outcome). As Kent mentioned earlier
>> in this thread, to document this list of detailed requirements on the mailing list.  The motivation for this
>> versus a draft, is that waiting for a draft to completely is a drag on progress, and we don’t want to
>> gate or slow things down.  Putting them in a place different from the existing draft also helps with
>> the perceptional issues that were raised earlier.
>>
>> 	—Tom
> This works as long as we break this seemingly endless requirements
> discussion cycle that keeps coming up when try to discuss solutions.
>
> >From my perspective we already have documented operator requirements
> that seem to have at least have 'rough' consensus. Namely:
> draft-openconfig-netmod-opstate-01: Sections 3, 4, 5.
I was only reading sections 3 and 4 as listing requirements, and section 
5 as the preamble to a proposed solution.

Can you please clarify?

Thanks,
Rob


From nobody Thu Sep 10 07:45:53 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19D1B68EB for ; Thu, 10 Sep 2015 07:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JedSAVEaWPXb for ; Thu, 10 Sep 2015 07:45:42 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E221B68E4 for ; Thu, 10 Sep 2015 07:45:38 -0700 (PDT)
Received: from [70.30.123.113] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Za36F-0001i9-MI; Thu, 10 Sep 2015 15:45:19 +0100
Date: Thu, 10 Sep 2015 10:45:33 -0400
From: Rob Shakir 
To: NETMOD Working Group , Benoit Claise 
Message-ID: 
In-Reply-To: <55F141E3.50002@cisco.com>
References: <55F141E3.50002@cisco.com>
X-Mailer: Airmail Beta (325)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 14:45:51 -0000

Benoit,

I want to pick up on this very specific point. I think Lou=E2=80=99s mail=
s imply a similar position, but I want to be clear.

On September 10, 2015 at 04:40:30, Benoit Claise (bclaise=40cisco.com) wr=
ote:
> > A common architecture includes a central configuration data =20
> store that is being updated by the manageability framework and =20
> updates read by the subsystems affected by the change (e.g. the =20
> BGP service or the interface manager). In this case, there is =20
> no other source of configuration except for the content of the =20
> data store.

The configuration file/=E2=80=98store=E2=80=99 of a system shows the inte=
nt of how that system should be configured. We can agree that all impleme=
ntations need to have this.

The applied configuration is the value of those configuration elements a =
daemon/software component/programmable memory is actually running, which =
can be compared to the intent. Essentially, this is *dynamic* information=
 which is the *state* of the running system. Implementations *do* store t=
his. I think the point that you are making here is not that it is not sup=
ported. The point is that it is dynamically built at query time, accordin=
g to a different schema.

This different schema is bad news, programmatically. How did I know that =
the static (IOS-alike configuration):

router bgp 65497
=C2=A0neighbor 192.0.2.1 remote-as 65500

Needs me to run:
=C2=A0
show bgp ipv4 unicast neighbor 192.0.2.1 =7C i remote AS

and then run a regexp that extracts the following AS number after the wor=
ds =E2=80=98remote AS=E2=80=99. Today - I probably need to write a mappin=
g table that tells me that.

The requirement is that we can determine, for a particular leaf - what th=
e intended value is, AND the value which is applied, PLUS be able to =E2=80=
=9Ceasily=E2=80=9D retrieve the state associated with that construct - in=
 a way that is deterministic, and does not require per-leaf mapping table=
s to be maintained like we might have to today.

The point about identical values is that *in cases where no such retrieva=
l of the actual applied config values is possible* a system can simply ma=
ke all the applied leaves pointers to the intent. This would be akin to t=
he =E2=80=98show=E2=80=99 command doing the equivalent of =E2=80=98show r=
unning-config =7C i 192.0.2.1.*remote-as=E2=80=99 and extracting the remo=
te-as from there A=46AICS.

Regards,
r.




From nobody Thu Sep 10 07:46:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D211B68F8 for ; Thu, 10 Sep 2015 07:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level: 
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI9xegofUNR3 for ; Thu, 10 Sep 2015 07:46:04 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245801B3A28 for ; Thu, 10 Sep 2015 07:46:04 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Thu, 10 Sep 2015 14:46:02 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Thu, 10 Sep 2015 14:46:02 +0000
From: Kent Watsen 
To: Nadeau Thomas , Berger Lou 
Thread-Topic: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
Thread-Index: AQHQ6zxjj8lNuSLDSUGefjLB3380wp40v24AgABGhQCAAEiZAIAAYQeAgAAB1QCAAAdAgIAADtaAgAAJ1wD//8P0gA==
Date: Thu, 10 Sep 2015 14:46:02 +0000
Message-ID: 
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com> <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <55F18985.5040603@labn.net> <36797CDD-F1CD-44AA-86E5-1EC6717C7BB8@lucidvision.com>
In-Reply-To: <36797CDD-F1CD-44AA-86E5-1EC6717C7BB8@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:7IuXYosHxNz5zAObxfdONgITir690TO0ffQUUQoPN1BgizH9DnxRDN6WOkbj7UbC0nkcWH8pWNoUuq/gXqp60aN3SbZ29Mhx5OGlsakvwGEVlmNvX5rN+DCFqsEri+y1QCsfCOgNE/CLEOoDuSmLIg==; 24:DqHSWVn2Z2lvaCbmMH6LDQW7ukfuoBastFQRY/C38Hv3SwMvZDVtUCbpqgBBmiBmsIzq3cEoJehOIt+LNKTxCsg+/zcQAhzdTC3884e1Pu4=; 20:ZFGJ7TlaMnNjD34rrE4Ms7J97f2cuwA1C7j+2Gg0Ra1XNrVEzm5a9obJ7firswXAENeQ89IoOJRno1Q4WLmKZg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(101416001)(105586002)(2950100001)(106356001)(5001860100001)(2900100001)(5001830100001)(122556002)(106116001)(93886004)(97736004)(66066001)(5001770100001)(46102003)(11100500001)(83506001)(10400500002)(5002640100001)(76176999)(50986999)(4001350100001)(54356999)(4001540100001)(40100003)(81156007)(77156002)(62966003)(64706001)(68736005)(189998001)(5004730100002)(102836002)(5001960100002)(87936001)(86362001)(92566002)(99286002)(36756003)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2015 14:46:02.6404 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 14:46:05 -0000

[As co-chair]

To facilitate the meeting, following is a straw man list of requirements
based on what I've read.  Let's focus on refining this list during the
meeting.


1. Ability to interact with both intended and applied configuration

   a. The ability to ask the operational components of a system
       (e.g., line cards) for the configuration that they are currently
       using. This is the "applied configuration".

   b. applied configuration is read-only

   c. The data model for the applied configuration is the same as
       the data model for the intended configuration (same leaves)

   d. For asynchronous systems, when fully synchronized, the data
       in the applied configuration is the same as the data for the
       intended configuration.


2. Applied configuration as part of operational state

    a. the ability to retrieve the applied configuration and
        derived state nodes in a single protocol operation.


3. Support for both transactional, synchronous management
   systems as well as distributed, asynchronous management
   systems

    a. For asynchronous systems, the ability to request a protocol
        operation to not return (i.e. block) until the intended
        configuration has been fully synchronized.

    b. The protocol operation's response would indicate the result
         of the operation (success, failure, partial, etc.)


4. Separation of configuration and operational state data; ability
   to retrieve them independently

    a. be able to retrieve only the derived aspects of operational state

    b. be able to retrieve only the non-derived aspects of operational
state


5. Ability to retrieve operational state corresponding only to
   derived values, statistics, etc.

    // this is a duplicate of # 3-a


6. Ability to relate configuration with its corresponding operational state

    a. ability to map intended config nodes to corresponding applied
config nodes
    b. ability to map intended config nodes to associated derived state
nodes
    c. The mappings needs to be programmatically consumable


7. Ability for distinct modules to leverage a common model-structure

  a. Scope is limited to IETF-defiend modules
  b. multiple domain-specific trees are okay
  c. multiple namespaces are okay




Thanks,
Kent




From nobody Thu Sep 10 07:57:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9213F1B6A2A for ; Thu, 10 Sep 2015 07:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level: 
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3ftCjYU1z5v for ; Thu, 10 Sep 2015 07:57:25 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11BF1B6A23 for ; Thu, 10 Sep 2015 07:57:18 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Thu, 10 Sep 2015 14:57:16 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Thu, 10 Sep 2015 14:57:16 +0000
From: Kent Watsen 
To: Kent Watsen , Nadeau Thomas , Berger Lou 
Thread-Topic: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
Thread-Index: AQHQ6zxjj8lNuSLDSUGefjLB3380wp40v24AgABGhQCAAEiZAIAAYQeAgAAB1QCAAAdAgIAADtaAgAAJ1wD//8P0gIAAAyOA
Date: Thu, 10 Sep 2015 14:57:16 +0000
Message-ID: 
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150909220033.GA35955@elstar.local> <14fb506f058.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20150910063248.GD36798@elstar.local> <8B781348-F3CC-47BA-AE8F-9128747AAB7C@lucidvision.com> <14fb738c478.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <55F18985.5040603@labn.net> <36797CDD-F1CD-44AA-86E5-1EC6717C7BB8@lucidvision.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:KQHBSDrhl5F/C+Hyx0oYd288VjOFhCyVQgTkb8MWbdwJ+Zkm9Bo4x2TBlNQBMGMJBsmLL3hgNkbZg5hsAOddadKAx7PbNf4B9NTjdJbChQJc4nj79nWH47p9aF6hWKSYCFrqvl4KsMCh3qwu3OuWpQ==; 24:2YguH65R3PlkDDMxkxdWXxp8VjBL/eFlba6boW5JUgDwLBnuFoZFdoDA8SXkiHhYQMp2lNFCLrXcimMfUwBr7U7VsdK8Fm/7UHVSME3vaLk=; 20:JUiABJLycaySZfYv8O9f06y0D7vvlaJEoK51tcE6Y+rvFxOWUDpnX/0c4Ac243Yco/0jznFdziedaLUFNwixEg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(479174004)(199003)(164054003)(24454002)(86362001)(19580395003)(76176999)(50986999)(64706001)(10400500002)(66066001)(189998001)(5002640100001)(1941001)(46102003)(11100500001)(5007970100001)(5004730100002)(101416001)(19580405001)(62966003)(92566002)(5001830100001)(5001860100001)(4001540100001)(99286002)(106356001)(83506001)(15975445007)(106116001)(87936001)(102836002)(77156002)(5001960100002)(93886004)(4001350100001)(54356999)(36756003)(68736005)(81156007)(40100003)(105586002)(2950100001)(97736004)(5001770100001)(2900100001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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)
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2015 14:57:16.4702 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 14:57:27 -0000

Typo:

- this is a duplicate of # 3-a
+ this is a duplicate of # 4-a

Kent


On 9/10/15, 10:46 AM, "Kent Watsen"  wrote:

>[As co-chair]
>
>To facilitate the meeting, following is a straw man list of requirements
>based on what I've read.  Let's focus on refining this list during the
>meeting.
>
>
>1. Ability to interact with both intended and applied configuration
>
>   a. The ability to ask the operational components of a system
>       (e.g., line cards) for the configuration that they are currently
>       using. This is the "applied configuration".
>
>   b. applied configuration is read-only
>
>   c. The data model for the applied configuration is the same as
>       the data model for the intended configuration (same leaves)
>
>   d. For asynchronous systems, when fully synchronized, the data
>       in the applied configuration is the same as the data for the
>       intended configuration.
>
>
>2. Applied configuration as part of operational state
>
>    a. the ability to retrieve the applied configuration and
>        derived state nodes in a single protocol operation.
>
>
>3. Support for both transactional, synchronous management
>   systems as well as distributed, asynchronous management
>   systems
>
>    a. For asynchronous systems, the ability to request a protocol
>        operation to not return (i.e. block) until the intended
>        configuration has been fully synchronized.
>
>    b. The protocol operation's response would indicate the result
>         of the operation (success, failure, partial, etc.)
>
>
>4. Separation of configuration and operational state data; ability
>   to retrieve them independently
>
>    a. be able to retrieve only the derived aspects of operational state
>
>    b. be able to retrieve only the non-derived aspects of operational
>state
>
>
>5. Ability to retrieve operational state corresponding only to
>   derived values, statistics, etc.
>
>    // this is a duplicate of # 3-a
>
>
>6. Ability to relate configuration with its corresponding operational
>state
>
>    a. ability to map intended config nodes to corresponding applied
>config nodes
>    b. ability to map intended config nodes to associated derived state
>nodes
>    c. The mappings needs to be programmatically consumable
>
>
>7. Ability for distinct modules to leverage a common model-structure
>
>  a. Scope is limited to IETF-defiend modules
>  b. multiple domain-specific trees are okay
>  c. multiple namespaces are okay
>
>
>
>
>Thanks,
>Kent
>
>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 10 08:01:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2E21B3654 for ; Thu, 10 Sep 2015 08:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwh0iwsTGp1v for ; Thu, 10 Sep 2015 08:01:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE921B3660 for ; Thu, 10 Sep 2015 08:01:35 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id C59CF1AE097A; Thu, 10 Sep 2015 17:01:33 +0200 (CEST)
Date: Thu, 10 Sep 2015 17:01:32 +0200 (CEST)
Message-Id: <20150910.170132.2025125829660081879.mbj@tail-f.com>
To: tnadeau@lucidvision.com
From: Martin Bjorklund 
In-Reply-To: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 15:01:56 -0000

Hi,

I got this, but there is no url to the webex there.  Can you send the
url?



/martin


Nadeau Thomas  wrote:
> >>> NETMOD Working Group invites you to join this WebEx meeting.
> >>>  
> >>> NETMOD Interm meeting on OpenConfig
> >>> Thursday, September 10, 2015 
> >>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr 
> >>>  
> >>> Join WebEx meeting
> >>> Meeting number:	645 732 277 
> >>> Meeting password:	1234
> >>>  
> >>> Join by phone
> >>> 1-877-668-4493 Call-in toll free number (US/Canada)
> >>> 1-650-479-3208 Call-in toll number (US/Canada)
> >>> Access code: 645 732 277
> 
> 	
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
`


From nobody Thu Sep 10 08:06:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955281B6AA2 for ; Thu, 10 Sep 2015 08:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NMC6SnXyJ07 for ; Thu, 10 Sep 2015 08:06:18 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id EF8341B6AA0 for ; Thu, 10 Sep 2015 08:06:17 -0700 (PDT)
Received: (qmail 5674 invoked by uid 0); 10 Sep 2015 15:06:17 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 10 Sep 2015 15:06:17 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id FT671r00s2SSUrH01T6AhR; Thu, 10 Sep 2015 09:06:15 -0600
X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=NojvYFcnAAAA:8 a=T0ZuanxOAAAA:8 a=48vgC7mUAAAA:8 a=2H-oxA38NqmQfQ9F8tsA:9 a=Fm8MfV051TR8gdzY:21 a=R0mryoyIDFtkDBWq:21 a=pILNOxqGKmIA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=9uUzcS5Nrb8A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=Ra0iBSJHo7MJ27yZFrbtSuA8d4aN592i07N1QXNhDOs=;  b=Sb4EAvh1HqvFAhvwothns4bSE3mILObFHySTvH+iN2fc4lNVb4TkW+6derdEZc9AWUBg0e0bz0+mEcXwmOtvezmswDz7IAu4ggYFizn0JIUInWZLZk2MUF21pWURKRVN;
Received: from box313.bluehost.com ([69.89.31.113]:55964 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Za3QP-0006eM-CW; Thu, 10 Sep 2015 09:06:09 -0600
To: Martin Bjorklund , tnadeau@lucidvision.com
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com> <20150910.170132.2025125829660081879.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <55F19C5A.5050407@labn.net>
Date: Thu, 10 Sep 2015 11:06:02 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150910.170132.2025125829660081879.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 15:06:19 -0000

https://ietf.webex.com/ietf/j.php?MTID=m54c7bcbed84a08dc78fba128d500f8c0

On 9/10/2015 11:01 AM, Martin Bjorklund wrote:
> Hi,
>
> I got this, but there is no url to the webex there.  Can you send the
> url?
>
>
>
> /martin
>
>
> Nadeau Thomas  wrote:
>>>>> NETMOD Working Group invites you to join this WebEx meeting.
>>>>>  
>>>>> NETMOD Interm meeting on OpenConfig
>>>>> Thursday, September 10, 2015 
>>>>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr 
>>>>>  
>>>>> Join WebEx meeting
>>>>> Meeting number:	645 732 277 
>>>>> Meeting password:	1234
>>>>>  
>>>>> Join by phone
>>>>> 1-877-668-4493 Call-in toll free number (US/Canada)
>>>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>>>> Access code: 645 732 277
>> 	
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> `
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From nobody Thu Sep 10 08:26:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA351ACE0E for ; Thu, 10 Sep 2015 08:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zRZa18pviMZ for ; Thu, 10 Sep 2015 08:26:18 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 B25531B4730 for ; Thu, 10 Sep 2015 08:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441898700; bh=+TDZnxWY08JJUBllW7qJIe/uSGsAmQmO3HtyKeyeXkQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=wZqm7rqv7NSaTWiWpWuHIruQoVhSKjuq2bIwveXOXbNrwBbOJkX00neu+PaHuVbM/ j6ByvUkeerDXbKNARREfy7R8GykoGxbl/4/JRU8KSX6QaSAC2x7eIGhxso/KOvQwJX xyZdI/JymdqcrylxlYyGdDOtbcDdooafZ65WQ41o=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <20150910.170132.2025125829660081879.mbj@tail-f.com>
Date: Thu, 10 Sep 2015 11:26:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <861BC101-6333-4FDC-92BB-BD9D2A7C52BC@lucidvision.com> <20150910.170132.2025125829660081879.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=19 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1569, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Tomorrow's Interim Meeting Details
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 15:26:20 -0000

https://ietf.webex.com/ietf/j.php?MTID=3Dm66838a52ebff4cf2879dff9b01f30f44=



> On Sep 10, 2015:11:01 AM, at 11:01 AM, Martin Bjorklund =
 wrote:
>=20
> Hi,
>=20
> I got this, but there is no url to the webex there.  Can you send the
> url?
>=20
>=20
>=20
> /martin
>=20
>=20
> Nadeau Thomas  wrote:
>>>>> NETMOD Working Group invites you to join this WebEx meeting.
>>>>>=20
>>>>> NETMOD Interm meeting on OpenConfig
>>>>> Thursday, September 10, 2015=20
>>>>> 11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr=20=

>>>>>=20
>>>>> Join WebEx meeting
>>>>> Meeting number:	645 732 277=20
>>>>> Meeting password:	1234
>>>>>=20
>>>>> Join by phone
>>>>> 1-877-668-4493 Call-in toll free number (US/Canada)
>>>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>>>> Access code: 645 732 277
>>=20
>> =09
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> `


From nobody Thu Sep 10 09:51:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC441B6B56 for ; Thu, 10 Sep 2015 09:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySVmGesjm4lH for ; Thu, 10 Sep 2015 09:51:19 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.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 22C381B6A40 for ; Thu, 10 Sep 2015 09:51:19 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Thu, 10 Sep 2015 16:51:17 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Thu, 10 Sep 2015 16:51:17 +0000
From: Kent Watsen 
To: Anees Shaikh 
Thread-Topic: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
Thread-Index: AQHQ6zxjj8lNuSLDSUGefjLB3380wp41YeCAgAANuoCAAEitAA==
Date: Thu, 10 Sep 2015 16:51:17 +0000
Message-ID: 
References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <55F09386.4030509@cisco.com> <20150910.094159.1542287559946591076.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:/P4i5i0DVSXChmIpvy8otklgmvYN6fcHuZLUKrhjas0SWTo74QnO+6d+hcQTzddJTSnzwrYkBdTlYWV8CaCURWBrTN7UXx2m2Uqmkhqo+/HOblWafF9/FLlXqVj5kEn66tGRrpcxKKWi5XQtOrfnvQ==; 24:vCj2+TInAfGFuQULjO7mamVU3iRtl8c0SxyROv45fMtgdERB+98QxGCr5q4MkBeS6XaipN2vjaQlIWlirOXoav2WsGA+ZoOqPRpZ/tfo6YU=; 20:/xXR7NHkpz/WzU2oeeAtbZzPH16kyB2/1inkxt0/zJdXRhn62zxdvJ5YCWlt1ha79VH5KZOHtlDM5Nec9DjuwQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(189002)(199003)(164054003)(101416001)(5001830100001)(105586002)(106356001)(2950100001)(2900100001)(5001860100001)(122556002)(106116001)(93886004)(66066001)(97736004)(46102003)(11100500001)(83506001)(5002640100001)(10400500002)(76176999)(50986999)(4001540100001)(54356999)(4001350100001)(40100003)(81156007)(77156002)(16236675004)(62966003)(68736005)(189998001)(5004730100002)(102836002)(5001960100002)(110136002)(92566002)(86362001)(87936001)(99286002)(36756003)(5007970100001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2172BD2D69C9kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2015 16:51:17.0519 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 16:51:21 -0000

--_000_D2172BD2D69C9kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Anees,

I was hoping this was going to come up on the call, but since it didn't...

> hi -- some additional comments inline.  I think that the revisit on some =
of the operator requirements is primarily due to some proposed solution's i=
nability to address them.

Can you elaborate on this?   Is it an "inability" to address them, or just =
that they don't address them currently?

Thanks,
Kent



--_000_D2172BD2D69C9kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Anees,







I was hoping this was going to come up on the call, but since it didn'=
t...






>
 hi -- some additional comments inline.  I think that the revisit on s=
ome of the operator requirements is primarily due to some proposed solution=
's inability to address them.






Can you elaborate on this?   Is it an "inability" to ad=
dress them, or just that they don't address them currently?







Thanks,


Kent












--_000_D2172BD2D69C9kwatsenjunipernet_--


From nobody Thu Sep 10 12:44:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F491B2FC4 for ; Thu, 10 Sep 2015 12:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKY0x8yjd52p for ; Thu, 10 Sep 2015 12:44:04 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256261A8AE9 for ; Thu, 10 Sep 2015 12:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11890; q=dns/txt; s=iport; t=1441914244; x=1443123844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=REtYTWT1Q9kFpB8d7m4dVuJ7pKlgybNuzyXFZ/vqC/k=; b=ZH/TBYoMNAHrP54hHWOAO1fhUrjTRFsUsfi3VkEVIslm5hvggpZo8646 ZgjY1LKb25gyEaQV3OPj6KyLY8vG+e31vuMD3fR44QNzq5Q0LuPawuy71 PE/RPSkQlv3bAfumVd8x67z9BdcqziLa/jvZU/6W+9mPV9PcVx4KbG+K4 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAgAR3fFV/4YNJK1dgyNUaQaDILoFAQ2BbQyFLUoCHIE1OBQBAQEBAQEBgQqEIwEBAQMBAQEBIBExBwIEBwULAgEIEgYCAiYCAgIlCxUCDgIEDgUJEogLCA24IZQGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EihVGCD4JsgmaBTg0YMweCaS+BFAWHM44jAYd2hQOBTIQzgx+RWh8BAUKEAHEBhwFCgQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,506,1437436800"; d="scan'208";a="25996730"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 10 Sep 2015 19:43:58 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t8AJhwX5028017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 19:43:58 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Sep 2015 14:43:57 -0500
Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 10 Sep 2015 14:43:57 -0500
Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 14:43:57 -0500
From: "Carl Moberg (camoberg)" 
To: Ladislav Lhotka 
Thread-Topic: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Thread-Index: AQHQ66RTXRbM5ItEF0C+fJOvsujdtZ4116wAgACm9oA=
Date: Thu, 10 Sep 2015 19:43:56 +0000
Message-ID: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com>
References: <55F141E3.50002@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.102.25]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6D6BBF4FC2934A41BE6060AF29409DB8@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 19:44:06 -0000

DQogSW5saW5lOg0KDQo+IE9uIFNlcCAxMCwgMjAxNSwgYXQgMTE6NDYgQU0sIExhZGlzbGF2IExo
b3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IGNvbW1lbnRzIGlu
bGluZS4NCj4gDQo+IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3cml0ZXM6DQo+
IA0KPj4gRGVhciBhbGwsDQo+PiANCj4+IFRoZSBZQU5HIGNvb3JkaW5hdGlvbiB0ZWFtIA0KPj4g
PGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS95YW5nLW1vZGVsLWNvb3JkaW5h
dGlvbi1ncm91cC5odG1sPiBoYXMgDQo+PiBzcGVudCBzb21lIHRpbWUgcmVhZGluZyBhbmQgZ2F0
aGVyaW5nIGlucHV0IG9uIHRoZSByZXF1aXJlbWVudHMgYW5kIA0KPj4gcHJvcG9zZWQgc29sdXRp
b25zIGluIGRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGUuIFRoaXMgbm90ZSBpcyB0byAN
Cj4+IGNvbGxlY3Qgc29tZSBvYnNlcnZhdGlvbnMgdGhhdCB3aWxsIGhvcGVmdWxseSBjb250cmli
dXRlIHRvIHByb2dyZXNzIGluIA0KPj4gdGhlIHdvcmtpbmcgZ3JvdXAuDQo+PiANCj4+IFdlIGJl
bGlldmUgaXQgaXMgdXNlZnVsIHRvIGNvbnNpZGVyIHRoYXQgWUFORyB3YXMgaW5pdGlhbGx5IGRl
c2lnbmVkIHRvIA0KPj4gYmUgYSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIGZvciB0aGUgTkVUQ09O
RiBwcm90b2NvbC4gSUVURiBpcyBhbHNvIA0KPj4gd29ya2luZyBvbiBSRVNUQ09ORiB3aGljaCBp
cyBhbiBIVFRQLWJhc2VkIHByb3RvY29sIHRvIGFjY2VzcyBkYXRhIA0KPj4gZGVmaW5lZCBpbiBZ
QU5HLCB1c2luZyB0aGUgZGF0YXN0b3JlcyBkZWZpbmVkIGluIE5FVENPTkYuDQo+PiANCj4+IFlB
TkcgaXMgZnVsZmlsbGluZyBpdHMgaW50ZW5kZWQgcm9sZSB3aXRoIE5FVENPTkYgYW5kIFJFU1RD
T05GIGFuZCBoYXMgDQo+PiBnYWluZWQgc29tZSBzaWduaWZpY2FudCB0cmFjdGlvbiBpbiB0aGlz
IGNhcGFjaXR5LiBUaGVyZSBhcmUgc29tZSANCj4+IGNoYW5nZXMgd29ya2VkIG9uIGluIFlBTkcg
MS4xLCBidXQgdGhleSBhcmUgbW9zdGx5IGluY3JlbWVudGFsLg0KPj4gDQo+PiBUaGVyZSBpcyBp
bnRlcmVzdCBpbiB1c2luZyBvdGhlciBwcm90b2NvbHMgb3V0c2lkZSBvZiBORVRDT05GIGFuZCAN
Cj4+IFJFU1RDT05GIHRvIG1hbmlwdWxhdGUgZGF0YSBkZXNjcmliZWQgYnkgWUFORy4gVGhlIHBy
b3Bvc2FscyBpbiB0aGUgDQo+PiBkcmFmdCBpcyBiYXNlZCBvbiB0aGUgYXNzZXJ0aW9uIHRoYXQg
WUFORyBtb2RlbHMgc2hvdWxkIGJlIHVzYWJsZSBmb3IgDQo+PiBwcm90b2NvbHMgYmV5b25kIFJF
U1RDT05GIGFuZCBORVRDT05GLiBTbyB0aGVzZSBhcmUgbmV3IHJlcXVpcmVtZW50cyBvbiANCj4+
IFlBTkcgZnJvbSwgb3IgaW4gcHJlcGFyYXRpb24gZm9yLCBuZXcgcHJvdG9jb2wgYmluZGluZ3Mu
DQo+PiANCj4+IFdlIGhhdmUgZm9jdXNlZCBvbiB0d28gbWFpbiBhc3BlY3RzIG9mIHRoZSBkcmFm
dC4NCj4+IA0KPj4gRklSU1RMWTogVGhlIHByb3Bvc2VkIHNwbGl0IGJldHdlZW4gaW50ZW5kZWQg
YW5kIGFwcGxpZWQgY29uZmlndXJhdGlvbiANCj4+IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9ucyA0
LjEgKHJlcXVpcmVtZW50cykgYW5kIDUuMSAoaW1wbGljYXRpb25zKQ0KPj4gDQo+PiBUaGVyZSBh
cmUgdHdvIG9ic2VydmF0aW9ucyBoZXJlOg0KPj4gMS4gVGhlIGltcGxpY2F0aW9uIGlzIHRoYXQg
YWxsIGNvbmZpZ3VyYWJsZSBkYXRhIG5vZGVzICgiaW50ZW5kZWQgDQo+PiBjb25maWd1cmF0aW9u
Iikgc2hhbGwgYmUgcmVwZWF0ZWQgaW4gYW4gb3BlcmF0aW9uYWwgdmVyc2lvbiAoImFwcGxpZWQg
DQo+PiBjb25maWd1cmF0aW9uIikgaW4gYWxsIG1vZGVscyBmb3IgYWxsIGFwcGxpY2F0aW9ucyBn
b2luZyBmb3J3YXJkLiBUaGlzIA0KPj4gd291bGQgYXBwbHkgaW5kZXBlbmRlbnQgb2YgaWYgdGhl
IHN5c3RlbSBpcyBzeW5jaHJvbm91cyBvciBhc3luY2hyb25vdXMgDQo+PiBpbiBuYXR1cmUuIFN5
bmNocm9ub3VzIHN5c3RlbXMgd291bGQgc2ltcGx5IGhhcmQtd2lyZSB0aGUgYXBwbGllZCANCj4+
IGNvbmZpZ3VyYXRpb24gdG8gYmUgdGhlIHNhbWUgYXMgaW50ZW5kZWQgY29uZmlndXJhdGlvbiBh
dCBhbGwgdGltZXMuDQo+PiAyLiBBbiBpbmZvcm1hbCByb3VuZCBvZiBjb252ZXJzYXRpb25zIHdp
dGggc29tZSB2ZW5kb3JzIGFzIHdlbGwgYXMgc29tZSANCj4+IHRvb2xpbmcgdmVuZG9ycyBzaG93
IHRoYXQgdGhlcmUgYXJlIGN1cnJlbnRseSBubyB3aWRlbHkga25vd24gcGxhdGZvcm1zIA0KPj4g
dGhhdCBhbGxvdyBmb3Igb2JzZXJ2aW5nIHRoZSBpbnRlbmRlZCBhbmQgYXBwbGllZCBzdGF0ZSBz
ZXBhcmF0ZWx5LiBBIA0KPj4gY29tbW9uIGFyY2hpdGVjdHVyZSBpbmNsdWRlcyBhIGNlbnRyYWwg
Y29uZmlndXJhdGlvbiBkYXRhIHN0b3JlIHRoYXQgaXMgDQo+PiBiZWluZyB1cGRhdGVkIGJ5IHRo
ZSBtYW5hZ2VhYmlsaXR5IGZyYW1ld29yayBhbmQgdXBkYXRlcyByZWFkIGJ5IHRoZSANCj4+IHN1
YnN5c3RlbXMgYWZmZWN0ZWQgYnkgdGhlIGNoYW5nZSAoZS5nLiB0aGUgQkdQIHNlcnZpY2Ugb3Ig
dGhlIGludGVyZmFjZSANCj4+IG1hbmFnZXIpLiBJbiB0aGlzIGNhc2UsIHRoZXJlIGlzIG5vIG90
aGVyIHNvdXJjZSBvZiBjb25maWd1cmF0aW9uIGV4Y2VwdCANCj4+IGZvciB0aGUgY29udGVudCBv
ZiB0aGUgZGF0YSBzdG9yZS4NCj4gDQo+IEl0IG1heSBiZSBiZWNhdXNlIHZlbmRvcnMgdGVuZCB0
byBsaW1pdCB1c2VyIGFjY2VzcyB0byB0aGUgZGV2aWNlDQo+IGNvbmZpZ3VyYXRpb24gdG8gYSBm
ZXcgb2ZmaWNpYWwgaW50ZXJmYWNlcy4NCg0KIEFncmVlZCwgYSBzdHJvbmcgcmVxdWlyZW1lbnQg
Zm9yIG1vc3Qgb2YgdGhlc2Ugc3lzdGVtcyBpcyB0byBwcm92aWRlIGNvaGVyZW50IHZpZXdzIG9m
IGNvbmZpZ3VyYXRpb24gYW5kIHN0YXRlIHRocm91Z2ggYSBzZXQgb2YgcHJvdG9jb2xzIChub3Jt
YWxseSBDTEksIFNOTVAgYW5kIE5FVENPTkYpLiBBbmQgc2luY2UgdGhlIGFwcGxpY2F0aW9uLWxl
dmVsIGVudmlyb25tZW50IGluIHRoZXNlcyBzeXN0ZW1zIGFyZSB1c3VhbGx5IHZlcnkgaGV0ZXJv
Z2Vub3VzICh2YXJpb3VzIHVzZXJsYW5kIGFuZCBrZXJuZWwgc3Vic3lzdGVtcywgc29tZSBiYXNl
ZCBvbiBvcGVuIHNvdXJjZSwgc29tZSBwcm9wcmlldGFyeSksIGl0IGlzIGhhcmQgdG8gYXZvaWQg
YSByZWdpc3RyeS1zdHlsZSBhcHByb2FjaCB3aXRoIGludGVncmF0aW9uIGludGVyZmFjZXMgZm9y
IHZhcmlvdXMgdHlwZXMgb2YgYXBwbGljYXRpb25zLg0KDQo+IEluIGNvbnRyYXN0LCBjb25zaWRl
ciBmb3IgZXhhbXBsZSBhIHR5cGljYWwgTGludXggc3lzdGVtLiBObyBtYXR0ZXIgd2hhdA0KPiAi
b2ZmaWNpYWwiIGNvbmZpZ3VyYXRpb24gc3lzdGVtIGlzIHVzZWQgKGluaXQgc2NyaXB0cywgTmV0
d29ya01hbmFnZXIsDQo+IFVDSSBpbiBPcGVuV1JULCBldmVuIE5FVENPTkYpLCB0aGVyZSBpcyBh
bHdheXMgYSB3YXkgdG8gY2hhbmdlIHRoZQ0KPiBydW4tdGltZSBjb25maWd1cmF0aW9uIHdpdGhv
dXQgdGhlIG9mZmljaWFsIGNvbmZpZ3VyYXRpb24gc3lzdGVtIGJlaW5nDQo+IG5vdGlmaWVkLiBG
b3IgaW5zdGFuY2UsIG9uZSBjYW4gZ28gdG8gdGhlIC9wcm9jIGZpbGVzeXN0ZW0gYW5kIGNoYW5n
ZQ0KPiBtYW55IGtlcm5lbCBwYXJhbWV0ZXJzIG9uIHRoZSBmbHksIHN1Y2ggYXMgSVAgYWRkcmVz
c2VzIGFzc2lnbmVkIHRvDQo+IGludGVyZmFjZXMuDQo+IA0KPiBTaW5jZSBJIGFtIG1haW5seSBp
bnRlcmVzdGVkIGluIHN1Y2ggb3BlbiBzeXN0ZW1zLCBJIGRvIHNlZSBhIHVzZSBjYXNlDQo+IGZv
ciBtYWtpbmcgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gaW50ZW5kZWQgYW5kIGFwcGxpZWQNCj4g
Y29uZmlndXJhdGlvbi4gQW5kIGJ5IHRoZSB3YXksIGl0IG1pZ2h0IGhlbHAgc29sdmUgdGhlIE5F
VENPTkYvSTJSUw0KPiBkaWxlbW1hOiBORVRDT05GL1JFU1RDT05GIHdvdWxkIG9ubHkgYmUgYWxs
b3dlZCB0byBtb2RpZnkgaW50ZW5kZWQNCj4gY29uZmlndXJhdGlvbiB3aGVyZWFzIEkyUlMgd291
bGQgb3BlcmF0ZSBleGNsdXNpdmVseSBvbiBhcHBsaWVkDQo+IGNvbmZpZ3VyYXRpb24uDQoNCiBJ
IHRoaW5rIHRoZSBpc3N1ZSBhdCBoYW5kIGhlcmUgaXMgdGhhdCB0aGUgc3VnZ2VzdGVkIGNoYW5n
ZXMgcmVxdWlyZSB0aGF0IGFsbCAoaW50ZW5kZWQpIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBh
bHdheXMgaGF2ZSBjb3JyZXNwb25kaW5nIChhcHBsaWVkKSB2YWx1ZXMuDQoNCiBUaGlzIHdpbGwg
YWN0dWFsbHkgbWFrZSBhIGxpdHRsZSBpbnRlcmVzdGluZyBmb3Igb3BlbiAob3IgcGVyaGFwcyBt
b3JlIGxvb3NlbHkgY291cGxlZCkgc3lzdGVtcyBsaWtlIHRoZSBvbmUgeW91IG1lbnRpb24gYWJv
dmUuIEZvciBldmVyeSAoaW50ZW5kZWQpIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIHlvdSBtb2Rl
bCwgeW91IG5lZWQgdG8gY29tZSB1cCB3aXRoIGEgd2F5IHRvIHJlYWQgYmFjayB0aGUgYXBwbGll
ZCBjb25maWd1cmF0aW9uLg0KDQogTm93LCB0aGluayBhYm91dCBjb25maWd1cmF0aW9uIHBhcmFt
ZXRlcnMgdGhhdCBoYXZlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBsb2NhdGVkIGluIG1vcmUgdGhh
biBvbmUgcGxhY2UuIExldOKAmXMgc2F5IHlvdSBjaGFuZ2UgdGhlIElQIGFkZHJlc3Mgb2YgYW4g
aW50ZXJmYWNlLCBpdCBpcyBsaWtlbHkgdGhhdCB0aGlzIGNvbmZpZ3VyYXRpb24gd2lsbCBiZSBw
YXNzZWQgYXJvdW5kIGFzIGlucHV0IHRvIGEgaGFuZGZ1bCBvZiBzdWJzeXN0ZW1zIChlLmcuIHRo
ZSBESENQIHNlcnZlciwgc29tZSByb3V0aW5nIGRhZW1vbnMgdGhhdCBtYXkgYmluZCB0byBzcGVj
aWZpYyBJUCBhZGRyZXNzZXMpLiBJcyB0aGUgaW50ZW5kZWQgYW5kIGFwcGxpZWQgaW4gc3luYyB3
aGVuIGEgc3BlY2lmaWMgc3Vic2V0IG9mIHRob3NlIGNvbmZpZ3VyYXRpb25zIGFyZSB1cGRhdGVk
LiBXaGF0IGhhcHBlbnMgaWYgdGhlcmXigJlzIGEgcGFydGlhbCBmYWlsdXJlPw0KDQo+IEZpbmFs
bHksIG1vc3QgZXhpc3RpbmcgTkVUTU9EIG1vZGVscyBpbiBmYWN0IGFscmVhZHkgaGF2ZSBpbnRl
bmRlZCBhbmQNCj4gYXBwbGllZCBjb25maWd1cmF0aW9uIGV2ZW4gaWYgdGhleSBhcmVuJ3QgY2Fs
bGVkIHNvOiB0aGUgYXBwbGllZCBvbmUgaXMNCj4gcmVwcmVzZW50ZWQgYnkgbm9kZXMgaW4gKi1z
dGF0ZSB0cmVlcyB0aGF0IGFyZSBkdXBsaWNhdGVzIG9mDQo+IGNvbmZpZ3VyYXRpb24gZW50cmll
cy4NCg0KIFllcywgYnV0IGRvIHdlIHdhbnQgdG8gZW5mb3JjZSB0aGlzIGZvciBhbGwgbW9kZWxz
IGZvciBhbGwgYXBwbGljYXRpb25zPw0KDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyB3
YXMgbm90IGFuIGV4aGF1c3RpdmUgY29sbGVjdGlvbiBvZiBkYXRhLCBidXQgDQo+PiBzaG91bGQg
Z2l2ZSBzb21lIGRpcmVjdGlvbmFsIGluZm9ybWF0aW9uLg0KPj4gDQo+PiBUaGUgKmltcGxpY2F0
aW9uKiB3ZSB3b3VsZCBsaWtlIHRvIG1ha2UgaGVyZSBpcyB0aGF0IGJ5IG1ha2luZyB0aGlzIA0K
Pj4gZmVhdHVyZSBtYW5kYXRvcnkgcGFydCBvZiB0aGUgWUFORyBsYW5ndWFnZSBpdHNlbGYgKGFz
IG9wcG9zZWQgdG8gYW4gDQo+PiBvcHRpb25hbCBjYXBhYmlsaXR5KSB3ZSByaXNrIGludHJvZHVj
aW5nIGEgZmFrZSBwZXJjZXB0aW9uIHRoYXQgdGhlIA0KPj4gY3VycmVudCBORVRDT05GIHNlcnZl
ciBzdXBwb3J0cyBhIGNhcGFiaWxpdHkgaXQgY2FuJ3Qgc3VwcG9ydC4gSW5kZWVkLCANCj4+IHBv
bGxpbmcgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiB3b3VsZCBhbHdheXMgcmV0dXJuIHRoZSBp
bnRlbmRlZCANCj4+IGNvbmZpZ3VyYXRpb24uDQo+PiANCj4+IEEgKnF1ZXN0aW9uKiB3b3VsZCBi
ZSBpZiBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gY29uc2lkZXIgYSBkaXJlY3Rpb24gDQo+PiB3aGVy
ZSB3ZSBtYWtlIGFuIGF0dGVtcHQgdG8gc2VwYXJhdGUgb3V0IHJlcXVpcmVtZW50cyB0aGF0IGFy
ZSB0aWVkIHRvIA0KPj4gc3BlY2lmaWMgcHJvdG9jb2xzIGFuZCBzb2x2ZSB0aGVtIGluIHRoZSBw
cm90b2NvbCBzZW1hbnRpY3MgcmF0aGVyIHRoYW4gDQo+PiBpbiB0aGUgbGFuZ3VhZ2UgdG8gdGhl
IGV4dGVudCB3ZSBjYW4uIFdpdGhvdXQga25vd2luZyBtb3JlIGFib3V0IHRoZSANCj4+IGludGVu
ZGVkIHByb3RvY29sIGluIHRoZSBjYXNlIG9mIHRoaXMgZHJhZnQsIGl0IGlzIGhhcmQgdG8gbWFr
ZSBtb3JlIA0KPj4gcHJvZ3Jlc3MuDQo+PiANCj4+IEEgKnN1Z2dlc3Rpb24qIGlzIHRvIGFzayB0
aGUgZHJhZnQgYXV0aG9ycyB0byBkb2N1bWVudCB0aGUgcHJvdG9jb2wgDQo+PiBiaW5kaW5ncyBp
biBvcmRlciB0byBxdWFsaWZ5IHRoZSByZXF1aXJlbWVudHMgZ29pbmcgZm9yd2FyZC4NCj4+IA0K
Pj4gU0VDT05ETFk6IFRoZSBwcm9wb3NlZCBzY2hlbWEgbG9jYXRpb25zIGZvciBjb25maWd1cmF0
aW9uIGFuZCANCj4+IGNvcnJlc3BvbmRpbmcgb3BlcmF0aW9uYWwgc3RhdGUgaW4gc2VjdGlvbnMg
NC41IChyZXF1aXJlbWVudHMpIGFuZCA1LjQgDQo+PiAoaW1wbGljYXRpb25zKQ0KPj4gDQo+PiBU
aGUgb2JzZXJ2YXRpb24gdG8gYmUgbWFkZSBoZXJlIGlzIHdlbGwgY2FwdHVyZWQgaW4gdGhlIGRy
YWZ0IGl0c2VsZiBhcyANCj4+IGJ1bGxldCAzIHVuZGVyIHNlY3Rpb24gNzoNCj4+IA0KPj4gICAg
ICJUaGUgcHJvcG9zYWwgZG9lcyBub3QgYWxsb3cgaXRlbXMgdGhhdCBhcmUgbm90IGNvbmZpZ3Vy
ZWQsIA0KPj4gY29uZmlndXJlZCBidXQgbm90IHByZXNlbnQsIG9yIHN5c3RlbSBjb25maWd1cmVk
LiINCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgZ2VuZXJhbCBub3RlIHRoYXQg
d291bGQgYXBwbHkgdG8gdGhlIGxhbmd1YWdlIA0KPj4gaXRzZWxmLiBNZWFuaW5nIHRoYXQgWUFO
RyB3aWxsIG5vIGxvbmdlciBiZSBhYmxlIHRvIGRlc2NyaWJlIHNpdHVhdGlvbnMgDQo+PiBsaWtl
IHRoZSBhYm92ZSBmb3IgYW55IHR5cGUgb2YgYXBwbGljYXRpb24gaW4gYW55IGNvbnRleHQuDQo+
PiANCj4+IEV4YW1wbGVzIGJleW9uZCB3aGF0J3MgYWxyZWFkeSBtZW50aW9uZWQgaW4gdGhlIGJ1
bGxldCBvZiB0aGlzIGNvdWxkIA0KPj4gaW5jbHVkZToNCj4+IC0gUmVtb3ZhYmxlIHBoeXNpY2Fs
IGFzc2V0cyAobGluZSBjYXJkcywgbWV6emFuaW5lIGNhcmRzKSBpbiBzeXN0ZW1zIA0KPj4gdGhh
dCBhbGxvdyBwcmUtcHJvdmlzaW9uaW5nIG9mIGNvbmZpZ3VyYXRpb24NCj4+IC0gUGh5c2ljYWwg
YXNzZXRzIHRoYXQgYXJyaXZlIGluIHRoZSBzeXN0ZW0gd2l0aCByZWFkYWJsZSBkZWZhdWx0DQo+
PiBzdGF0ZQ0KPiANCj4gSSBhZ3JlZSwgZXhpc3RpbmcgTkVUTU9EIG1vZHVsZXMgYWxyZWFkeSBz
dXBwb3J0IHByZS1wcm92aXNpb25pbmcgYW5kDQo+IHN5c3RlbS1jb250cm9sbGVkIGNvbXBvbmVu
dHMuDQo+IA0KPiBMYWRhDQo+IA0KPj4gDQo+PiBJbmRlcGVuZGVudCBvZiB0aGUgZGlyZWN0aW9u
IHdlIHdpbGwgYmUgdGFraW5nIGdvaW5nIGZvcndhcmQsIHRoZSANCj4+IGltcGxpY2F0aW9uIHdl
IG1ha2UgaXMgdGhhdCBpdCBpcyBhIHByZXR0eSBzaWduaWZpY2FudCBpbXBhY3Qgb24gdGhlIA0K
Pj4gZXhwcmVzc2l2aXR5IG9mIHRoZSBsYW5ndWFnZSBpdHNlbGYgYW5kIGhvdyB1c2VmdWwgaXQg
aXMgaW4gdGVybXMgb2YgDQo+PiBtb2RlbGluZyBhcHBsaWNhdGlvbiBkYXRhIHNldHMgdGhhdCBt
YXkgbm90IGFsaWduIHdpdGggdGhlIHJlcXVpcmVtZW50cy4NCj4+IA0KPj4gVGhlIHF1ZXN0aW9u
IHdlIHdvdWxkIGFzayBpcyBpZiBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byByZWJhbGFuY2UgdGhl
IA0KPj4gaW1wbGljYXRpb24gYW5kIG1ha2UgaXQgYSBsaXR0bGUgbW9yZSBtb2R1bGFyIGFuZCBv
cHRpb25hbCBpbiB0aGUgDQo+PiBsYW5ndWFnZS4gV2UgYXJlIGF3YXJlIG9mIHN1Z2dlc3Rpb25z
IHRvIHVzZSB0aGUgZXh0ZW5zaWJpbGl0eSBvZiB0aGUgDQo+PiBsYW5ndWFnZSBpdHNlbGYgKGUu
Zy4gaW4gZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZSkgdG8gZXhwcmVzcyANCj4+IHJlbGF0
aW9ucyBhY3Jvc3MgZGF0YSBzZXRzLiBVbmRlcnN0YW5kaW5nIHRoYXQgdGhpcyBzdWdnZXN0ZWQg
YXBwcm9hY2ggDQo+PiBkb2VzIG5vdCBub3JtYWxpemUgdGhlIHBhdGhzIGFjY29yZGluZyB0byB0
aGUgd2lzaCBvZiB0aGUgYXV0aG9ycywgYnV0IA0KPj4gaXQgY2FuIHBlcmhhcHMgYmUgYSBiYWxh
bmNlZCBhcHByb2FjaCB0aGF0IGltcGFjdHMgdGhlIGV4cHJlc3Npdml0eSBsZXNzLg0KPj4gDQo+
PiAgICAgICAgICAgICAgICAgICAgICAgICBSZWdhcmRzLCB0aGUgWUFORyBjb29yZGluYXRpb24g
dGVhbQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IC0tIA0KPiBMYWRpc2xh
diBMaG90a2EsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0KPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFp
bGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Thu Sep 10 13:44:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201E81B6C07 for ; Thu, 10 Sep 2015 13:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7-HLVc84v0k for ; Thu, 10 Sep 2015 13:44:35 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 7B92F1B640A for ; Thu, 10 Sep 2015 13:44:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441917800; bh=6/dOjwOs1mNcryuwzrYcU3LF/rVEEFTxVlSDt1A+7C0=; h=From:Subject:Date:Cc:To; b=sQU9WDEIiTd0ZZEIucP2uc2X3uQf8vW6YdjsGTLNzxu98r0G6iuiyPxzYgfE6UomC j34pCBcbWhQetn27Bi+80cjorSvU8TX+PELKCGYB6NDcjvRWV9kc/rudFkju/oAG61 MftC9Kf8RlGUvqkXBVrFR6R+vq4O9PBnMmYKnNvM=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Sep 2015 16:44:29 -0400
Message-Id: <25E74703-B15C-4CE1-8FE3-A35EE875507B@lucidvision.com>
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=32 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1582, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] Consensus Call Note for Requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 20:44:37 -0000

	This is an official NETMOD working group call for consensus =
around the requirements referenced=20
below and discussed in detail at the interim meeting held Thursday, =
September 10, 2015. At that meeting, the
chairs went over each requirement in detail and called for any =
objections to each requirement (and sub-requirement). The question that =
was asked was =E2=80=9CAre there any objections to requirement X in =
general meaning as it is currently written or with minor/editorial =
changes to how its written?=E2=80=9D There were no objections to any of =
the requirements, as is detailed in the meeting minutes.  However, to =
confirm these statements the co-chairs are opening this question to the =
WG for period starting today, Thursday, September 10, 2015 at 5PM EST.  =
This period will close on Monday, September 14, 2015 at 5PM EST.  If you =
commented on the list previously, or at the meeting, there is no need to =
repeat yourself; we have your position on=20

	We will make a call of consensus shortly thereafter.=20

	For your reference, the requirements can be found at this URL:

http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements

	but I will paste them into this message explicitly to be =
complete.

	=E2=80=94Tom (as co-chair)



Terminology

From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01

  In order to understand the way in which a network operator or network
  management system may need to interact with a device, it is key to
  understand the different types of data that network elements may
  store or master:

  o  intended configuration - this data represents the state that the
     network operator intends the system to be in.  This data is
     colloquially referred to as the 'configuration' of the system.

  o  applied configuration - this data represents the state that the
     network element is actually in, i.e., that which is currently
     being run by particular software modules (e.g., the BGP daemon),
     or other systems within the device (e.g., a secondary control-
     plane, or line card).

  o  derived state - this data represents information which is
     generated as part of the system's own interactions.  For example,
     derived state may consist of the results of protocol interactions
     (the negotiated duplex state of an Ethernet link), statistics
     (such as message queue depth), or counters (such as packet input
     or output bytes).



1. Ability to interact with both intended and applied configuration

  a. The ability to ask the operational components of a system
      (e.g., line cards) for the configuration that they are currently
      using. This is the "applied configuration".

  b. applied configuration is read-only

  c. The data model for the applied configuration is the same as
      the data model for the intended configuration (same leaves)

  d. For asynchronous systems, when fully synchronized, the data
      in the applied configuration is the same as the data in the
      intended configuration.

2. Applied configuration as part of operational state

   a. the ability to retrieve the applied configuration and
       derived state nodes in a single protocol operation.


3. Support for both transactional, synchronous management
  systems as well as distributed, asynchronous management
  systems

   a. For asynchronous systems, the ability to request a protocol
       operation to not return (i.e. block) until the intended
       configuration has been fully synchronized.

   b. The protocol operation's response would indicate the result
        of the operation (success, failure, partial, etc.)


4. Separation of configuration and operational state data; ability
  to retrieve them independently

   a. be able to retrieve only the derived state aspects of operational =
state

   b. be able to retrieve only the non-derived state aspects of =
operational
       state


5. Ability to retrieve operational state corresponding only to
  derived values, statistics, etc.

   // this is a duplicate of # 4-a


6. Ability to relate configuration with its corresponding operational =
state

   a. ability to map intended config nodes to corresponding applied =
config nodes
   b. ability to map intended config nodes to associated derived state =
nodes
   c. The mappings needs to be programmatically consumable


7. Ability for distinct modules to leverage a common model-structure

 a. Scope is limited to IETF-defiend modules
 b. multiple domain-specific trees are okay
 c. multiple namespaces are okay



From nobody Thu Sep 10 13:57:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BED1A6FC3 for ; Thu, 10 Sep 2015 13:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level: 
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztPmNTmpAG-v for ; Thu, 10 Sep 2015 13:57:16 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 ED8871A6FD1 for ; Thu, 10 Sep 2015 13:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441918561; bh=PYXAHcPcExRCnC2vMj9z/oE3AxgNToz/WFGrCDd/CT0=; h=From:Subject:Date:To; b=EzkHG5uf4hkhIuSuO4BpmMRCDHCUJdWvAmjtbx1HNbYRhK375qsy/9oRxS0RiO9qx wxpoyXdk1F7JErqJzo9c+Ecu0ayTHYi0VARrRkyTJfD8+BHCLWunAVe6rzJX6LWd0F J56pB8axTd2DCswW8CMd/z5kK+UdD5GWPglA+2nQ=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: multipart/alternative; boundary="Apple-Mail=_45F43AED-BFD2-4BC4-B22B-14A0D79C77CC"
Message-Id: <80DE07EF-5EE5-4615-8AEE-E488E8D13209@lucidvision.com>
Date: Thu, 10 Sep 2015 16:57:12 -0400
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=35 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 118, in=1585, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Subject: [netmod] Preliminary Meeting Minutes from Interim Meeting 9/10/2015
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 20:57:19 -0000

--Apple-Mail=_45F43AED-BFD2-4BC4-B22B-14A0D79C77CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


	These are the preliminary/draft meeting minutes from today=E2=80=99=
s meeting.=20
They will be neatened up once we are sure what they contain is accurate. =
Please=20
comment ASAP if you feel there are any inaccuracies contained therein.

	Thanks to Mahesh Jethanandani (mjethanandani@gmail.com) for =
taking notes!

	If you were in attendance, and are not listed in the screen =
capture from WebEx
below, please contact me privately so I make sure you are added. There =
were others that
came/went that did not make it on my initial screen capture nor were =
listed on the etherpad.

	=E2=80=94Tom


>> Requirements Discussion have been captured in the e-mail send to the =
mailing list.
>> Tom: Question - do you agree/disagree with requirements posted on =
list
>>=20
>> Discussing the following requirements:=20
>> 	=E2=80=A2    =20
>> 	=E2=80=A2 1. Ability to interact with both intended and applied =
configuration
>>=20
>> 	=E2=80=A2    a. The ability to ask the operational components of =
a system
>> 	=E2=80=A2        (e.g., line cards) for the configuration that =
they are currently
>> 	=E2=80=A2        using. This is the "applied configuration".
>>=20
>> 	=E2=80=A2    b. applied configuration is read-only
>>=20
>> 	=E2=80=A2    c. The data model for the applied configuration is =
the same as
>> 	=E2=80=A2        the data model for the intended configuration =
(same leaves)
>>=20
>> 	=E2=80=A2    d. For asynchronous systems, when fully =
synchronized, the data
>> 	=E2=80=A2        in the applied configuration is the same as the =
data for the
>> 	=E2=80=A2        intended configuration.
>>=20
>> Tom: who disagrees with #1
>> Lada: Who is requirement 1.b. for. NETCONF client ? The example of =
being able to change the /proc entry in the Linux kernel.
>> Rob: That is not a good example. Take the example of a flash light. =
Asking to turn on the light through some other means is not changing =
applied configuration.
>>=20
>>    =20
>>    =20
>> Carl: we need a concrete example
>> Lou: applied config =3D show on the CLI
>> Carl: Lou's example is not the correct interpretation of applied =
configuration.
>> Carl: A concrete example would help here.
>> Kent: 1.d Is the applied configuraiton =3D intended configuration. On =
a sysnchronous system, if during transiition from applied to intended, =
the system simplified the configuration, would that be acceptable, or =
does it have to be a carbon copy? Rob confirms - yes.
>> Martin: In the draft, for 1.d, the applied configuration may not be =
the same as intended configuration.=20
>> Rob: For hardware that is synchronized. If the hardware is not =
present then it is not synchronous.
>> Martin: Will interfaces show up in applied configuration that have =
not been intended?
>> Call-in User 13: It will show up in applied configuration. Not =
everything that is applied is intended.
>> Martin: Maybe it is the schema that is the same between intended and =
applied configuration.
>> Rob: We are at the same point we were in June.=20
>> Tom: Do we agree with the requirements or are they minor edits?
>> Lada: The requirements are related to definitions. If the definitions =
are not clear, the requirements are not clear.
>> Tom: What have we been doing for the last three months? Can we move =
forward on agreeing on the requirements.
>> Kent: We have consensus on 1 a, b, and c. But not on d.
>> Rob: How can we say we do not have agreement on d.
>> Tom: Is the general sense that d is a requirement is clear. Are the =
requirements 1 a, b, c, d clear. No negative responses. No disagreement =
on the requirements.
>>=20
>> Tom: Moving to 2. Does anyone disagree with the requirement?=20
>> Alex: Will the applied data indistinguishable from dervied state?
>> Rob: In the draft we say that applied data would be retrieved from =
derived state.
>> Lada: IP address on a interface can be both applied or dervied state.=20=

>> Rob: The BGP example of hold time has both intended and applied =
configuration.
>> Christian: The draft says that we can get both in a single operation.=20=

>> ??: Need more examples for each of the requirements.
>> Tom: No objections. But do need examples.
>>=20
>> Tom: Moving to 3. No objections
>> Tom: 3a no objections
>> Tom: 3b no objections
>>=20
>> Tom: Moving to 4. No objections to 4, 4a and 4b.
>> Kent: Will add the word state to derived.
>>=20
>> Tom: Does anyone disagree that 5 is a duplicate of 3a. No objections.
>>=20
>> Tom: Disagree on 6a, b or c. No objections
>>=20
>> Tom: Disagree on 7 a, b, c. No objections
>>=20
>> Tom: Will be taken to the list where comments will be welcomed within =
48 hours.
>> Christian: Can we make a call.
>> Tom: Not here. On the mailing list.
>>=20
>> Tom: Moving to solution discussion.
>> Lou: Can the chairs share the slides they have prepared.
>> Kent: Is that there are no questions?
>> Tom: No. It would help to see the comparisons.
>> Kent: Sharing slides.
>>=20
>> [Kent to paste his comparison e-mail here]
>>=20
>> Christian: Are both the kwatsen and wilton implemented using RPC.
>> Kent: Yes.
>> Christian: Would like to hear from OpenConfig folks on the two =
suggested solutions.
>> Rob: Would be interested in implementations that do not support a =
particular datastore=20
>> Andy: Instead of changing the schema, add attributes. Client asks for =
particular attributes. Would be happy with tha solution.
>> Aneesh: In the extreme case, the reply could carry all the extra =
attributes?
>> Andy: But the schema would have to maintain the extra leaves.
>> Aneesh: Do not want to debate the solution.
>> Andy: Most platforms do not need this. So keeing it as attributes =
makes it part of the protocol instead of the schema.
>> Aneesh: So is the solution is for the server returning attributes?
>> Aneesh: Like the idea.
>> Benoit: The two suggested solutions. They are based on =
NETCONF/RESTCONF. Are they using it for other protocols?
>> Aneesh: We are using other protocols. Will share primitives.
>> Benoit: If the solution is for NETCONF/RESTCONF, will it work for =
other protocols.
>> Rob: If the solution is mappable for NETCONF/RESTCONF, would it be =
mappable for another protocol.
>> Benoit: YANG is currently not protocol agnostic. Currently, it is =
tied to NETCONF/RESTCONF.
>> Benoit: If the solution is for NETCONF/RESTCONF, is that acceptable?
>> Rob: No. The solution has to be more general.
>> Christian: Is the intersection of NETCONF/RESTCONF good enough for =
the other protocols.
>> Andy: YANG cannot be decoupled from NETCONF/RESTCONF without making =
it Information Modelling Language.
>>=20
>> Tom: Need another meeting. Call for consensus on the mailing list.




--Apple-Mail=_45F43AED-BFD2-4BC4-B22B-14A0D79C77CC
Content-Type: multipart/related;
	type="text/html";
	boundary="Apple-Mail=_833A36A7-75F0-443B-8B1A-41AF5906B08C"


--Apple-Mail=_833A36A7-75F0-443B-8B1A-41AF5906B08C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



	These are =
the preliminary/draft meeting minutes from today=E2=80=99s =
meeting. 
They will be neatened up once we are =
sure what they contain is accurate. Please 
comment ASAP if you feel there are any inaccuracies contained =
therein.

	Thanks to =
Mahesh Jethanandani (mjethanandani@gmail.com) for taking notes!

	If you =
were in attendance, and are not listed in the screen capture from =
WebEx
below, please contact me privately so I make =
sure you are added. There were others that
came/went =
that did not make it on my initial screen capture nor were listed on the =
etherpad.

	=
=E2=80=94Tom


Requirements Discussion have been captured in the e-mail send =
to the mailing list.
Tom: Question - do you agree/disagree with requirements =
posted on list

Discussing the following =
requirements: 
	=E2=80=A2 =
    
	=E2=80=A2 =
1. Ability to interact with both intended and applied configuration

	=E2=80=A2 =
   a. The ability to ask the operational components of a =
system
	=E2=80=A2       =
 (e.g., line cards) for the configuration that they are =
currently
	=E2=80=A2 =
       using. This is the "applied =
configuration".

	=E2=80=A2 =
   b. applied configuration is read-only
	=E2=80=A2    c. The =
data model for the applied configuration is the same as
	=E2=80=A2       =
 the data model for the intended configuration (same leaves)

	=E2=80=A2 =
   d. For asynchronous systems, when fully synchronized, the =
data
	=E2=80=A2       =
 in the applied configuration is the same as the data for the
	=E2=80=A2       =
 intended configuration.

Tom: =
who disagrees with #1
Lada: Who is =
requirement 1.b. for. NETCONF client ? The example of being =
able to change the /proc entry in the Linux kernel.
Rob: =
That is not a good example. Take the example of a flash light. Asking to =
turn on the light through some other means is not changing =
applied configuration.

  =
  
    
Carl: we =
need a concrete example
Lou: applied config =3D show on =
the CLI
Carl: Lou's example is not the correct =
interpretation of applied configuration.
Carl: A concrete =
example would help here.
Kent: 1.d Is the applied =
configuraiton =3D intended configuration. On a sysnchronous system, if =
during transiition from applied to intended, the system simplified =
the configuration, would that be acceptable, or does it have to be a =
carbon copy? Rob confirms - yes.
Martin: In the draft, for =
1.d, the applied configuration may not be the same as intended =
configuration. 
Rob: For hardware that is =
synchronized. If the hardware is not present then it is not =
synchronous.
Martin: Will interfaces show up in applied =
configuration that have not been intended?
Call-in User =
13: It will show up in applied configuration. Not everything that is =
applied is intended.
Martin: Maybe it is the schema that =
is the same between intended and applied configuration.
Rob:=
 We are at the same point we were in June. 
Tom: Do =
we agree with the requirements or are they minor edits?
Lada: The requirements are related to definitions. If the =
definitions are not clear, the requirements are not clear.
Tom: What have we been doing for the last three months? Can =
we move forward on agreeing on the requirements.
Kent: We =
have consensus on 1 a, b, and c. But not on d.
Rob: How =
can we say we do not have agreement on d.
Tom: Is the =
general sense that d is a requirement is clear. Are the requirements 1 =
a, b, c, d clear. No negative responses. No disagreement on =
the requirements.

Tom: Moving to 2. =
Does anyone disagree with the requirement? 
Alex: =
Will the applied data indistinguishable from dervied state?
Rob: In the draft we say that applied data would be retrieved =
from derived state.
Lada: IP address on a interface can be =
both applied or dervied state. 
Rob: The BGP example =
of hold time has both intended and applied configuration.
Christian: The draft says that we can get both in a single =
operation. 
??: Need more examples for each of the =
requirements.
Tom: No objections. But do need examples.

Tom: Moving to 3. No objections
Tom: 3a no objections
Tom: 3b no objections

Tom: Moving to 4. No objections to 4, 4a and =
4b.
Kent: Will add the word state to derived.

Tom: Does anyone disagree that 5 is a =
duplicate of 3a. No objections.

Tom: =
Disagree on 6a, b or c. No objections

Tom: =
Disagree on 7 a, b, c. No objections

Tom: =
Will be taken to the list where comments will be welcomed within 48 =
hours.
Christian: Can we make a call.
Tom: =
Not here. On the mailing list.

Tom: Moving =
to solution discussion.
Lou: Can the chairs share the =
slides they have prepared.
Kent: Is that there are no =
questions?
Tom: No. It would help to see the =
comparisons.
Kent: Sharing slides.

[Kent to paste his comparison e-mail here]

Christian: Are both the kwatsen and wilton implemented using =
RPC.
Kent: Yes.
Christian: Would like to =
hear from OpenConfig folks on the two suggested solutions.
Rob: Would be interested in implementations that do not =
support a particular datastore 
Andy: Instead of =
changing the schema, add attributes. Client asks for particular =
attributes. Would be happy with tha solution.
Aneesh: In =
the extreme case, the reply could carry all the extra attributes?
Andy: But the schema would have to maintain the extra =
leaves.
Aneesh: Do not want to debate the solution.
Andy: Most platforms do not need this. So keeing it as =
attributes makes it part of the protocol instead of the schema.
Aneesh: So is the solution is for the server returning =
attributes?
Aneesh: Like the idea.
Benoit: =
The two suggested solutions. They are based on NETCONF/RESTCONF. Are =
they using it for other protocols?
Aneesh: We are using =
other protocols. Will share primitives.
Benoit: If the =
solution is for NETCONF/RESTCONF, will it work for other protocols.
Rob: If the solution is mappable for NETCONF/RESTCONF, would =
it be mappable for another protocol.
Benoit: YANG is =
currently not protocol agnostic. Currently, it is tied to =
NETCONF/RESTCONF.
Benoit: If the solution is for =
NETCONF/RESTCONF, is that acceptable?
Rob: No. The =
solution has to be more general.
Christian: Is the =
intersection of NETCONF/RESTCONF good enough for the other protocols.
Andy: YANG cannot be decoupled from NETCONF/RESTCONF without =
making it Information Modelling Language.

Tom: Need another meeting. Call for consensus on the mailing =
list.



=

--Apple-Mail=_833A36A7-75F0-443B-8B1A-41AF5906B08C
Content-Transfer-Encoding: base64
Content-Disposition: inline;
	filename="Screen Shot 2015-09-10 at 11.08.11 AM.png"
Content-Type: image/png;
	x-mac-hide-extension=yes;
	x-unix-mode=0644;
	name="Screen Shot 2015-09-10 at 11.08.11 AM.png"
Content-Id: 

iVBORw0KGgoAAAANSUhEUgAAAY0AAAOoCAYAAAAtWah9AAAKqmlDQ1BJQ0MgUHJvZmlsZQAASImV
lgdUU2kWx7/30hstEDqE3qRLFwidANK7jZAECCXGQACxISKO4IgiIgLKiA5VwbEAMhYEFNsgoIJ9
QAYRdRwsiIrKPmAJu3t2zp6959y837m5777/9733nfMHgHyXJRAkw1IApPDThMFervTIqGg67ncA
AxVAADpAi8VOFbgEBvqBv42PAwCavd4xnp31933/NaQ53FQ2AFAgwrGcVHYKwmeQbGMLhGkAoARI
XSsjTTDLxQjLChGBCNfOcvw8n5/l2HnunesJDXZD+A8A8GQWSxgPAGkCqdPT2fHIHDKyWmDG5/D4
CDMQdmInsDgIZyO8JCVl7SwfR1g/9l/mxP/bzFjxTBYrXszza5kLvDsvVZDMWv9/bsf/jpRk0cIz
NJEkJwi9g5GrDLJntUlrfcXMj/UPWGAeZ65/jhNE3mELzE51i15gDsvdd4FFSWEuC8wSLt7LS2OG
LrBwbbB4PjfVI0Q8n8v0E2tI9hdzHM+TucBZCaERC5zOC/df4NSkEN/FHjdxXSgKFmuOE3qK15iS
uqiNzVrUkJYQ6r2oLVKsgcN19xDX+WHifkGaq3imIDlQ3M9N9hLXU9NDxPemIR/YAieyfAIX5wSK
9we4AR7gAy5IASxAB97AHYA0bmbarGC3tYL1Ql58QhrdBTkxXDqTzzZZQrcwM7cCYPb8zb/e9/fn
zhVEwy/WspIAYFwDAPZYrEUg33F9HQA0lcWa9lfkGBQC0HaTLRKmz9fQsz8YQASSQBYoAjWgBfSB
MbAA1sABMIAH8AEBIBREgdWADRIQ3UKQATaCrSAPFIA9YD8oA5XgKKgFJ8Ap0ALOg8vgKrgJesE9
8AgMgVHwCkyAj2AagiAcRIGokCKkDulARpAFZAs5QR6QHxQMRUExUDzEh0TQRmgbVAAVQWXQEagO
+gU6B12GrkN90ANoGBqH3kFfYBRMhmVhVVgXNoVtYRfYFw6FV8Hx8Do4C86Fd8OlcBV8HG6GL8M3
4XvwEPwKnkQBFAlFQ2mgjFG2KDdUACoaFYcSojaj8lElqCpUI6oN1Y26gxpCvUZ9RmPRVDQdbYx2
QHujw9Bs9Dr0ZvQudBm6Ft2M7kLfQQ+jJ9DfMRSMCsYIY49hYiIx8ZgMTB6mBFONOYu5grmHGcV8
xGKxNKwe1gbrjY3CJmI3YHdhD2GbsO3YPuwIdhKHwynijHCOuAAcC5eGy8MdxB3HXcL140Zxn/Ak
vDreAu+Jj8bz8Tn4Enw9/iK+Hz+GnyZIEXQI9oQAAoewnlBIOEZoI9wmjBKmidJEPaIjMZSYSNxK
LCU2Eq8QHxPfk0gkTZIdKYjEI2WTSkknSddIw6TPZBmyIdmNvJIsIu8m15DbyQ/I7ykUii6FQYmm
pFF2U+oonZSnlE8SVAkTCaYER2KLRLlEs0S/xBtJgqSOpIvkasksyRLJ05K3JV9LEaR0pdykWFKb
pcqlzkkNSk1KU6XNpQOkU6R3SddLX5d+IYOT0ZXxkOHI5MoclemUGaGiqFpUNyqbuo16jHqFOiqL
ldWTZcomyhbInpDtkZ2Qk5FbKhculylXLndBboiGounSmLRkWiHtFG2A9kVeVd5Fniu/U75Rvl9+
SkFZgaHAVchXaFK4p/BFka7ooZikuFexRfGJElrJUClIKUPpsNIVpdfKssoOymzlfOVTyg9VYBVD
lWCVDSpHVW6pTKqqqXqpClQPqnaqvlajqTHUEtWK1S6qjatT1Z3UeerF6pfUX9Ll6C70ZHopvYs+
oaGi4a0h0jii0aMxramnGaaZo9mk+USLqGWrFadVrNWhNaGtrr1ce6N2g/ZDHYKOrU6CzgGdbp0p
XT3dCN0dui26L/QU9Jh6WXoNeo/1KfrO+uv0q/TvGmANbA2SDA4Z9BrChlaGCYblhreNYCNrI57R
IaO+JZgldkv4S6qWDBqTjV2M040bjIdNaCZ+JjkmLSZvTLVNo033mnabfjezMks2O2b2yFzG3Mc8
x7zN/J2FoQXbotziriXF0tNyi2Wr5dulRku5Sw8vvW9FtVputcOqw+qbtY210LrRetxG2ybGpsJm
0FbWNtB2l+01O4ydq90Wu/N2n+2t7dPsT9n/5WDskORQ7/Bimd4y7rJjy0YcNR1Zjkcch5zoTjFO
PzkNOWs4s5yrnJ8xtBgcRjVjzMXAJdHluMsbVzNXoetZ1yk3e7dNbu3uKHcv93z3Hg8ZjzCPMo+n
npqe8Z4NnhNeVl4bvNq9Md6+3nu9B5mqTDazjjnhY+OzyafLl+wb4lvm+8zP0E/o17YcXu6zfN/y
x/46/nz/lgAQwAzYF/AkUC9wXeCvQdigwKDyoOfB5sEbg7tDqCFrQupDPoa6hhaGPgrTDxOFdYRL
hq8MrwufinCPKIoYijSN3BR5M0opihfVGo2LDo+ujp5c4bFi/4rRlVYr81YOrNJblbnq+mql1cmr
L6yRXMNaczoGExMRUx/zlRXAqmJNxjJjK2In2G7sA+xXHAanmDPOdeQWccfiHOOK4l7EO8bvix9P
cE4oSXjNc+OV8d4meidWJk4lBSTVJM0kRyQ3peBTYlLO8WX4SfyutWprM9f2CYwEeYKhdfbr9q+b
EPoKq1Oh1FWprWmyiNG5JdIXbRcNpzull6d/ygjPOJ0pncnPvLXecP3O9WNZnlk/b0BvYG/o2Kix
cevG4U0um45shjbHbu7YorUld8totld27Vbi1qStv+WY5RTlfNgWsa0tVzU3O3dku9f2hjyJPGHe
4A6HHZU/oH/g/dCz03LnwZ3f8zn5NwrMCkoKvu5i77rxo/mPpT/O7I7b3VNoXXh4D3YPf8/AXue9
tUXSRVlFI/uW72suphfnF3/Yv2b/9ZKlJZUHiAdEB4ZK/UpbD2of3HPwa1lC2b1y1/KmCpWKnRVT
hziH+g8zDjdWqlYWVH75iffT/SNeR5qrdKtKjmKPph99fiz8WPfPtj/XVStVF1R/q+HXDNUG13bV
2dTV1avUFzbADaKG8eMrj/eecD/R2mjceKSJ1lRwEpwUnXz5S8wvA6d8T3Wctj3deEbnTMVZ6tn8
Zqh5ffNES0LLUGtUa985n3MdbQ5tZ381+bXmvMb58gtyFwovEi/mXpy5lHVpsl3Q/vpy/OWRjjUd
jzojO+92BXX1XPG9cu2q59XObpfuS9ccr52/bn/93A3bGy03rW8237K6dfY3q9/O9lj3NN+2ud3a
a9fb1res72K/c//lO+53rt5l3r15z/9e30DYwP3BlYND9zn3XzxIfvD2YfrD6UfZjzGP859IPSl5
qvK06neD35uGrIcuDLsP33oW8uzRCHvk1R+pf3wdzX1OeV4ypj5W98Lixflxz/Helytejr4SvJp+
nfen9J8Vb/TfnPmL8deticiJ0bfCtzPvdr1XfF/zYemHjsnAyacfUz5OT+V/UvxU+9n2c/eXiC9j
0xlfcV9Lvxl8a/vu+/3xTMrMjIAlZM1ZARSScFwcAO9qAKBEAUBFfDNRYt4fzwU07+nnCPwdz3vo
ubAG4Gg74kWQ9EGyIhsAHSSpyF+BDABCGQC2tBTnPyM1ztJifhapBbEmJTMz7xFfiDMA4NvgzMx0
y8zMt2pE7EMA2j/O+/LZwCL+vUgDBpjuTjAD/jP+AREFBJCldVMzAAABnWlUWHRYTUw6Y29tLmFk
b2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i
WE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3Jn
LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjph
Ym91dD0iIgogICAgICAgICAgICB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYv
MS4wLyI+CiAgICAgICAgIDxleGlmOlBpeGVsWERpbWVuc2lvbj4zOTc8L2V4aWY6UGl4ZWxYRGlt
ZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+OTM2PC9leGlmOlBpeGVsWURp
bWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1l
dGE+Ck5kImsAAEAASURBVHgB7H0JQJTXtf8PGFZBVERAUUGIigENRoNGMSEhVqu+iP4TY3zELLVZ
fdXXlpr6Uk1bmzybVvqM2YxprC+1JnF5VZ8+JZpIjBrXCHEFl4gCIiAwwAAD/M+533dnvhlmhl0Q
58I3313OOffcc5dz98/l9OnT9a6urmBTV1eHS+cv4Or5bMRP/REO7dmH73d8hV5hoZgx/zn8QGH7
P9oInc4FLvUuoH+4uBGuhweuXs/DjZuFuCs2BolJU3FX1FDoy8rwccoyJL36CvqHDcA7Kb+DsVSP
+LkzMfL+OPzf2k8RNjwKQ0cOx8ZVHyH/1AUY62rx5OsL0bNXANYs+A2IOTz15q+Jt1ps+I8/wc/b
B64ubnBzdaGH3i70Jh6IG9TBFW71OsKpR3298hCnFFIP8oCLC/FKPNfX1YOT7ELwdfRXX0d2SowL
0XIlmnWogQvRdyG0uvpaehN9cpMNtbVGgjeiRg0zutTBSHhXC/KRf6MAkZT+h2dMwWBOf2kZ0j76
FNMXPIfvj32Hr//6OVFwQaG+hH7rEeDbA5N/MQ+hA/vjg1//Aa76KoqvHs/86TW4e7iLPNH+pH2y
CYPvuwcD7hqk9Rb2i6fP44ezWXhg+mR8s2sPMrbuRY+wfpj18xdw4fQ57F/zOclJRykmaVB66yg9
9To3XMm/huvFRRg8MtqC7w9//gfMXPyikm+/+D1q9BWIT56OkePuw46POd+GIory7fN3PsaN05dR
Q3J5Ysl8yrdeWL1wmZDrM//5KyXflqyCj6c7dK7uQr6ulA+cfyLX6t2oDFESSI6EpOQVS0nklQuM
tbWEQ1yTXDgPUUdhBF9HechOAhT5RtmKamMtdITn4kYuCucc5jJNIAKGfTjvXXSc+ZT+WiozHE5/
DMvlWbUKfC5zRobnPCY+qmuorNQbYaitRvJvX4Z/D39cufQDhRlRXlaO0ye+x+H/24/e3Xtg9I/j
kfDoRHy5cw++2bhXlJ9X/vhLuFJZ/dP838PD3RPevXzxszd+gR+yL2Hdm6vxb39eBB3l0Z//7Q94
8lfPINxGPmefycaBnV/jXxfMxcmjJ7H1g00goigtuylk17NbL0SMjMTjzz+BjKMZ+GLtThEXy7yO
5OhOj4urDiR10A+ljWRBhuXJZZzfbFwIjtOv5JLwUuQtBCTdFEpkpFy5riqypHAuZELOqp1ym2IR
9F05Q9ibMUnotSTbOs5/ylCu/zU1NTBUV+GV38+Dr68vFr3wH3jzvd/jxo1C+Pt3R0FBAfZs+xJz
X0rG9ydP45P/+gyDhg7Ao8lTERDYi3hyhdFopPLuhiUv/QGPzZuOmHvvxtpVn+DC91RWqZyUlZXA
28cHnh7eWLoyBcU3b+LP//EeXnz1KfSn+rgs5S1UlFTh0bkTcd/9o/HZx1tw8tvTmPXTRxF9zzD8
9b/+jotnfsBjP/kXxIwcho+J9sXvc4h/I372+jz0onqw5KX/xMC7QzDr6ZmirHCaDZUG/PMfO3Hi
YCb+8P5/4NrVXKz63V+F3H7xxovEkzfe+uW7cNd5MriQSx3JZ9KTD2DkfSOwbcsO/OPjz0lU9ejm
2w0ffLKS2lk9fv/zv2DQkFD89OdzcT2/AH95fTU83BQaM5/7MfEcha9278fhPd+TvzvJhh7KPM5f
zgbO73rKF1e1XnJOch3hNlG8uX2k9sKV4tVtWkuJP3UetVQZCBNuVGiiRo3A9evXUVpSgoqqKnhX
Vgr3dcqsMkOFyAwXKhRcviLiRiD2Rw+gOP8G/vlfa5D7/XmsOvYH/PIvb4iMKzWU43rBdbh7eZDA
KmGsqcZNyqDc3FwUFBWi9nwW/EMC4eLtAT3BciUuJWVzs7QUNysrRAHIy8sjIdVReIVotHVUGF1c
dFQm+c0FlxOv/LlRwmqpMVBaAHqTUX4peWzh8upSK9LKhVStIxSm4pAMWE4Cjgs+I7EHF25Os0Dg
xgQwkkIZSIUxJnE8ivMKKP0f4VrmObxDCoLTX2OsQVZ2lkirgdJdVsGyc8UDs/4Fnt5e2Ltuk5Cr
m4cOFaRMqVUSjdOly5dIMevwwbI/KVETM+7u1OhW1sKNGhp3X2/8zyef4vKZ88QXZSIpGHdSbDFx
o0RcxUXF0FPh9KioFO58zstyvWiwuaJyUjnfRkxU+N7yl4+QQ3yvPHwCi95+U/B9s7xM8Kajxr68
vBzGyircLCkW9G7Qm/OtB+Wbq7c7SjlfqLKXllGelZagpEJPHLtC5lsZuaur3SktriI/3SjfuFC6
ueuEoFmBCsMypfx3pU6JbFhYzgRJEKQ8KBuE+EW+EBYXZPLjMkBNHsmCgbkccJPIeVurerGL85cf
guPKQg/nJ2cvN2eMypVGocfxkMKqqxHx1RNP/NTUkvLgRs1Yjfz8fFRQ+fzL0j+itOgmkXSDt4cX
dWq6odxgQBEpYi7jNykvDNXVzA0uXryIgIAAGOmvxmBEr+6BAiaLZFlC8mZ5cUPH9uysbHhRPm/8
78+QRfWTJaSjcqKr01E83gKvylhFdaJS4Ex6cio1OF7YvnYbSigfOO4bRTcob8qho/hFJ4jk70EK
g2lxh0soDbXRYE8j8SgVtGgsyFPIlmTDhiXLkqzlTFBlrqgcVgckPwHF8mQ5EiR33iiAGyIuH2xE
Z1OEs7wpkP45W4zc/lC9ZdnUkqyrqd1hGeup3FZQh+XIkSMYMGAANe7F2Lfna5Tqy0QaC6ht0VeV
ImF6PKqqDfjP375FyjITv/rdzxEYGEjlvgQXLmSjd99ecPemekby8vH1wdxnZ+Py+Rx8nXZQyP0m
tXXlssyTnLnMG6rMbVUxlfmKSj0KCgtEvKWkdJi3rPPn0TukJzyoHlQY9KglhcT1oITqgaG6HIX5
Rfj1wiXw7d4NEx4eh5GjYxE7Phr79x4w8W8gvllm3OZ6eHpQO1FGSqNSyJiFWkeyKbxxQ8DXkjLs
3SOIyptS7zmfy/XlKK+kuleitKs3CgrJTXXOtQrde/nBr4cPcq/l4sg3x1FWWkFtiSe4neS843Ir
8lzkDtdPziQX0bZyZ4Q7Ye7uXtTZoE6sUO6Ut1/t/bL+WFo6+g4Ox4wnZyk5z4hkTL07ShD/C8M5
bG24ptkzDC/DJa50M4423JqGTXhroI50q7LQpseancbSJ3FlWhlf+jWHVmOwWvoS1l48HK7lW+Jq
4Tnp9rLdHryM97Z/a8s0J0YpBxYisZCVUFmiIbWXdK5rSkOt1DtptwWvhbUOtxmmsGcN2qndQpZq
+bJOkyO3zTBt+2WVai28pZ0BzXkiXJo8MpGxyHSTr7A4omcZphCRRUZWHy01GcZ+2nDpr6WnxdPa
Gc9eldXCWZe9ZT97G14e3YRyYQI6/549kPDYNKHleFjYIHLBIUHK2LQcm2LShJv81MLPbnPKlFDp
ZpdIiSSuBItfbTxaeIGjgetwK+eEDf6JLyFLyZ81jEyf9Jduu/AcwIWLjMRRXMqvtRxtubXwbLdF
h7xNfMtwyZt0M641ffYjY8JlhxZeBPJPVzCaPBdZouaLNmnatKvyYyjrCskoLDM2MszaLQLVHxmm
hZfhdsNssCdxOutbkZXCnUyXVj7SzhAcrnVbpIkIscq2Fe6IrpIllni24rHlJ3nit614uRpreVL4
4NGZwrlaHESTK7NOhim0FTj+lf72+JCQpjikRzPe1TVV8HL3ZraJJxqFvP7ThegRGID8q9cwbv9u
QUqJQKGqpIOSSBiVNL3E6xQVNM1STUNeD1rL8KF5QT8/P3h5ewsEhjclVCFhrhSNuNVg8bJohily
S5oWoVq0jrFb8WfJq8KSVqbsI1Mg/aVbJkD6S7c23DrMRE/lwwRrxZcmVoWsVbg13zIeSc+eW/Jo
4kP1kPBmf0lJi3E72mnqhWRnTlfDNMhwaxitvxbLVuNiD1bi2QpnCTNn2jCu6Lej0aaB+de6tXbr
MFtptYZXYBRpacO0dq4vjt0KFUsYy9ibFqbkjxnWnGO28lNbj9ViKCI141vyoLjMNG2FOvKro2lZ
LlUuYm6YRhoRQSG09lALj4Agh0WL1zcKCwvF3Lqnp6dQFryAVUVzj3q9XszV+vv7i7iti2hz3bYS
YKZhttmCu/V+zA8JVBOx1i69bflxWHP9HeHYCjPTN9vMsTrmW4vhmDaHNjSW+JauhtC3l49SBbl5
tp0uxVeqYSVtWkjLkIZpl7BaOOknoWWY2V+xmd0S8vZ7cxosSyenQaa4OenRSkPia/20dlt0rcOl
m2lJu8SzRZ/DpL+Es8az9LcOZXdDWTCONaSk0/DddMiGuMp6npEW0D1oZOMKnQ8t3tXreJHKOmFm
ZB5hsMLw8vISC7QyhBft5MPhPPLwVkccEqbt3q1JdttxYZuSkq22wzrStzGZyXD7ed8y7iXdlmEz
Vl1FLvYeOGVJoGcYRt0dDn9PufxqGWzLVV9TjoKb9egd6EsLf7W48sWXMI6egPDuDXenKfhNgZEx
NZZOq/D6ahQVlMI3sDc8RJBG7mQ1j6clfW2zYEWLQBr6mPG6go3Tp5FQG6S4aRJrGK8tadqiZcuP
cW372/a1FVdDClIuTEParTGbQ98aV+um7SS0GM9PHe1WpcVy3qXC20xdaVeFPVNGU1Ji9w7t6GHD
wyD5sJt3+nA4wzXPNJYsDpdP8yjfeujm8ClhG3vbSwXjsdG+bdFSoBr/lbi2IGWYfEsY6bb1ljAt
f/NuOcAXw8fGIz6envFxGOx5CUfO5oudOk2lXF99AxknC1VwVwSMikUQ7aKxb5oCYx/bcUg1jmd8
B4NFLWf5mRWGIs32kalj3jpnqLUkrLmU4Vp/6dfSN9PS4lq7tWGtsWt5bq5dxuuIt+bStAsv6iLt
HKUdW7w1mnav8t5s3mrFm+VtG17D4CkpNlplIaF5PpYVB8M1bji5WqN1y9qk9dPC3g52W7y3NF22
aEkZyDD5lv6teWtpMc9at6Rry0+GtfXbGz60FVvplXsgNGwwzh2spvEClcOKQpzPOIGrtFMZ6Ilh
o6MR0t0D5bnZuOHWHcaLJ3HdfwBcr/4gmNp7qBpjRg9C+fVc1Pfzh4+7G6r1+ThzKBMFDBFIo5ih
NIrxqIdewrgZcP7EWVT76JB3laF8EXlPDAYG+AiaFYVXkHHiHBQWBmBUdITAz6fzTEZfD5w5lSXg
Bg0fi/AA4PzeQ8J9mN7DxoxCsIcBP5zLRFYeU+iJwbT/v3+Al4Bx/tiWgL3SZ8/fNpXm+bYn7eZx
0jHQYgQsVtzZRmfcPHS0/58OQ/FBD3uGF715GsqR4XCGs2+Yvv04FLymwNiPofOG3C7pYkXRUgXX
HtLnjRcVMNC5h4ryIlw4ew4I9qLjBTXIOXACCB+Lhx9+GGNjfHDqcC75kqkrR1bGSSAsFiMjwhEz
PIw8wzAmNgw+NKtVVZQHA50DQE0JjpPC8I6Jw4MJExDrfwNH0q8IGiYYkkVlcTHy3IIQ/+CDGBfb
F1knDuB6FcmotgQHSGGEj5tAPExAjM8POKJoMBjLfsCZXGDshAcRHzcUF06eIcXig4FjY0jt+CJm
TCz6+Lih/BopjNoBiH/oYYILwbkTp1CqHGfglDiNUwKdQgK82M4HDPlgLK9v0Ekf2iFA81Q8V2XP
8FoFL3o7UhwcznD2DTdGUmlo7fYxbs+Q2zVtnZFvPTJPZ1Azqxjf3kMxZkAfcRCqf/w4OsBYQbv+
CnAj/yp11IeKw0qgE7kIG4WIIGVTRp2PUia96AAkHTEzFanaqpvUkEdiZB9fPuOGXgNHI75vPaxX
OowU+6hBQbQIyED9cc+Ac7h8owJ9aLQSP24MKitu4mp+KfFBg5XBSh2iM4GIvDtUjGag60FjCJpS
I/F6ePkQfXcxeuJD6+6+fUAn93D8VAUG9OmJsfEjQLrEaZwS6FQS4LUMRWEoXUo68KecAnegM8RO
Kd4l5UZTUGJroGafl9wqyMf2fbp1I70gFQOlWwNn4c/Kg9uozmo0STCxKNJCAdZhDdKhgRFh/KPx
MxEkSwNcTaB1PBzkCF6D2sBqi5YE4nSJPNMA2c23VvAg42vWuyfiRo+Er3V/pt6Ai+n7caPfIAyi
U+kDPaqRd4HXQBQR+dJpV2mEyKTWkZ6mN59MVw2dHjdW0zUkfH0Li0I+bJWioTcNzOlkOPW4qgqQ
vv8k+kUOQ0jvYLhXX8JFhQWVIDuID60s1RD58gwIw4T4ELquogQ3rp/HKRog3TP+PgR4ygglZCve
WlItLT+tiN6JevtLoJauZeDBOd9qIK4aUTSIsjpuL3l8DoMP/rFiYMOKQj7sZv8aehjO0mhLrGVI
27vaqEY4YtlWmPDjhpdSJB9T4lSebOEJGDs824U3EW47i6lF1JK8lQxo421oV7eGWwbUVeMG+UQO
CkOgvzcq9UUi3KLNlhgsYn01qsRec+lJ1yd48LrEOVwr4SlVWse4dhoHDuZqxiIKrA5lyLpyA7Uk
kpqK6zhyARgQ6IM62pUFhGHQwBD4e7mAZs9oDGGTA4UQ/4oFxWJU0nUxzFbhmT3Yd7kcfoFBiIiK
QT8a+5RWKXXMjOS0OSXQsRIQTYSrWrZpsK7je024ANNyuF3OeBst35lTWFRk2kXF95XwlBQ/rFA4
vMF2W257BHFbjRAHsFHDbIFwsBUYe1kYEU4/Nhs/gpT4FkiNO+RBGTmSMvHJJNXeozmscXoCQvbq
Tb1Pe4lW6RHvvPBkiofBW5geyWGTeJfx2JQpM6DhW2OVcYi35LOF4cpFenzBog3j5o2wfr44kb5H
BAb2CybFQApAH4ze5OOuQXLz6YUBvgdx4MtyxD14t6DHJd3FI5DWQsJw4Eg6qQ42gbRTa4CYnmJ0
c21wQU1hFr7M/k5ABQ+mBWxaHHGpDiC63yJ9zyXy90Vwv54ozs5Caf8RKs9EhdOufdy60eWUvji5
fx8Gj3kQoRGj0G/fEey9Ikij58BoDLK1FdiRDJsTZg1rlZWtLVtKKpy/XU0CdK2dUuPV8uKybNZP
RfUurSzHkvUfOExvJS1I8rZacSKcpqvEiXCakuIRhlAY1oWQqcmG0pqyqeFUA2w2UGqYPRqSpqNw
kToJ2NibgCUfkj+tW2tnUiY3O7h5Zy9NzbSmwWBaI8OFn8RzwAPDNSs9KkJzeBK8cDwaPqSfICcZ
UPmVbGthpN0ejaaEy2gkrI0338LKU0DUf6Eba8lOmzEcsWODBCHWiQv4XAWuVZrr9Di29xyGPBiL
brTVkHapi7gEHTVtvEDI8QpFQ6MZvsVWG247Tst4lHTwDkY73NvxVgqczRhUHuhlhcudBosyqqIL
f2tgB6SdQXeOBH71k9/TbcN0KSPdwOxOSxQ60aOiOQB5JbIjUbBiaDCaUBHastA11htuWPDNNaMx
XEfpEzWMGwNhiKaZbKNoXIGbCm5BrEFD0SIqFiQdOqziayhLh9iaQI2cVN/GZN8wLnNaG8PVRGyy
8vkiaVyo4W6R4U0g9lBJoRTTH18Qzjd+qupARMOpFzfkEjLzzm6TwiC7CBeQrH8VWcnGWrg0jbdM
h5CPg1JkTcca1DpcjFI1QDJcxKMtB8RQyy+ZUBPpfHVZCYjyyjunqJ7wJdE6/qYAL3CInmULky0K
oT1cbeG0B2Plb25KrAJUZ4NwjYfGahu5Kb5WPDtMH9MzKRrbxGVllaGy8TCNVGRAk96chW2SStGY
2aVkJYOmsGaXlooswrXsaxA01qZEdWtg3HzpYOEE0JEOYawbW9kom/KzFVzZL2NagbUiAgeoMh0O
QJxBd7AEuClwox4SX99O+0VIaQhh8NcK6pGVleVYNJqGRNsQmis82VSHdQUTDasGv0FDaytM+nGj
LO3MoSO3bMAlvEhgUytew3gsME00BVEzTzJO5k3CSD61fhJOwqhkpMwY1GHaZLgFgsCy82PFpyAv
I1VQRHZJftRwi0bQlqy1sWlwTXkq/WzhyjCmoQ23JxttXO1uJ9lo+bOKT1umtXYGc+TmMDZSrtZu
Ecg/FlnDDqqk9NconkrAmq4tnhhUjCrMlVbBtohbJeh8OSUgJECDCm7aaZ84Fxvdwz+bi92pH4mC
FDN8uCIkUYDoR1YgazdDyUquYCi/El4Emwu7CNQ2EOyhdWvtAtjqxzq8MbcWnWGFsa4lWiBp16RZ
esk3k7FHwhQHw2iApL/WT9LjtwzX+gk70dCQMQVLeEnPOmnWbkZkHAkv3SaCqkUTbquhkY2WgNbS
09qtabLbOtzKbR2XBQmZFgvP9nZYysqaP61baxdcOUgbw7KRcmyAK0LVHwbV5L0jWEdhTM1WuC0/
EXOHyFvE7Pzp5BKgD1PSuh8pCyN1YdxoxMEFuZYORBkttiS2vgRpyn3rRKJWuMaIcGVoV0MJshlH
U+K1xZpDPFsI7Zo6u8RbnI8O02eOzqZMzcG32GY/tTb51GaTRvE2xrR2/YDp2qTdGJFGwiVN+Zbg
UnGx2yLMftIlqvN9h0qAi7ko6vQlRv4CpO7tlCUI69OXVvHMhUiWH1morN0sO+lnIUeuAKoHh0t8
9tK6Ja4Ml24VtQGe8Fdpm2Ct4pKVwUSzGZVYxstvia/1YzvHy491uIkfBmJjxZfqyd4WpgGeKVTE
4jAeyYNCw3znv223Jc8247XiWdJnlgQ3KvMSV4ZLt2Rd+ku3FtealnTLUZDElflIXBOIdQyScvu9
JR8yBkduUdqt8lXi8dsRrqmiqAgWsHZoWsBoI7JFQxPuCE8bplVmGnSn9Q6XANdCvmZK+UwzjTgi
g/qLesuV1bqKNua2JUstjtbOsI25JT1rOHv+tuDMjY7E4rctSG24tLMM7NRYFaQplGzB2PKTsSpv
LYQjPrRhCo51zjV0O04Tx28Zu33OrGG1kFoa0t/az9ptgmuhkpf4bfVWZGcpL3ZJvmWItVsbv3WY
4uZfpVOl2BQMc17ZoqysaWhpt53dHHPb0XRS6pISoALLt07zdSJcE3Qe9BF1ca9UR1da0ZvVVqdm
il925dV0cA+KqTXfaLFkRXZERcJLWOm2xtGGs90enMRzFO4oTOJr302Bl/xp8aztTMcKrtF8kziS
B0t82dOVyt7kto76lroteZUuZkFrt3RbhzSEZR8JJd/mZFn7SDe9NSJjX3YyJVZBSjmXXR2Jo1A1
w5pjcdqcEmiuBPguW67mtNGWCl49dDRNRXtv6VAUezTLaAuoRJbFtKmErOElHS2+Nh6tvy1YCleV
hxnLbNNiN82u5a8xOs0Jbwy2ady1LVRTebKG43yQecFhbLeG0bq1doZUcKWSV0ItYdo2nc2h1vF8
MAfK+ERRFMy95MqkOFQZmlWSOY0S1uzjtDkl0DwJ8AeYhKE3lyedmxvdwEanWvlakIZGKbJmf+m2
Lopat9ZuxjTbrBsVCa8yZqoSZgzbNonHoRLXGlILYx3WVHdb0GhqXLcjnLV8rN2NpUmBby5WY1S7
UrgtZSDT5yhMwjjfTgm0RgI8eWOqn3S6j+4DpVun+ANMJl9JXnrIt7W/dDf3bU1P4tvzl+GO3q3B
dUTXGeaUgFMCTgnc2RJQRrTm7onYcstzVvTR1ztbMs7UOyXglIBTAk4J2JCAsn7Gn8/gh5c0yMZz
VdreutZug4bTyykBpwScEnBK4M6QACkJoR/44imy63Qu9PE+2krlysMNp3FKwCkBpwScEnBKQCOB
errhmQcW/O0lNsqny2ilQ2511MA6rU4JOCXglIBTAne4BMTOWh5t8O4pcuiU8YVyg2FzZVNbchlf
7T2A7IIyBVXnhyGjxmNcTKj47nJz6TUd3oDjW7cgL+xhTI4JbIBWkLEDOy8F47FpsfBqENq+HkaD
ETovnVUkdE0L3d+io7voW2uM9E0TioBoNaRkNFIYpdg6zFBSiBtllXD39qOPZfnTh+E1hhgzfSuO
mfQifE2wtVV8vZHv1NcE2Eozw7VFejXRtJvVoCf53KyEt18P+Pv7WqSt3SJtCmFDIXJKPBEaZPd7
tU2h0mQYQ0k+ShCAIH9t7jYZ3QnYVSVAgwodX1aoc6VNU2JNQxly1Jump5o4TVWTh62f7iKFAQwb
MwGJCeMQ4VeJswd3YNfZknYXX8XNMuQVV9iMp6qiBIabtsNsIrSVpz4DL0+dhOR3DllQ1J9ei0mT
nkGGnrwJ5vnERCQ2eJKw/9A7NvxV2KQ10Av6UzHpmTUotIiBPrmbs43ioLCX19FHQ1VjyMG6V5Mw
deYsPP3005gzayYmJS7A3ksSQo91L08iPPWZSvjE16vvbEO+SZNIYvwuwdrHJuGZNRkmTxEvpXnB
5ixLP6K51zYRE5ylRY81FPc7GQ3Ljj5jDcklCcck25aILXcZ87Hh9WRMna7IZ9bM6ZT+ZGzIsJZu
y6NoOaYeG+bNwlvf3MDpdc8jkfLfUjIUnpyIJE1etCSu/Ixd2HYsX6Aaf9iGOTNXNihbLaHrxOk6
EuCRhvhGOL15Rkr5niZ/AI1PiFsshjtOtOHaOZC+wPDJMxEXSmc9yIRH9kPV6k+Rk3EBNUNixacz
RUATfmpqaulTsuqHC5oAzyD2+kOhcU9gXlxDIrX0WVqKpP1GQcSQN0WbvWkxNiRswawo2UP0MDOj
Mh2/YAVeGd0TlcSSYtzRu7cXPv74X2hEAHy3ej6WH5qAle89CT/Bdw/46i4qoLnrse/SHCSFmcdR
J/9vgySkvguxZt7TWJ87GotXLsDYuwJgLLmEzW/9Est+8iLcN6zD+AACZd2amIKP540AKitRfOk4
1ixNxZxN5/Fx2kKEWlD1R/QEP6z/8hT0z8XQR06BnBP7BUTmVxkwJEWKkV2e8EvEsCB7OWRB1OTw
oE/MV5lcZovXgAeQsiAaEVKc5qBW2PTY/Is5WJ0ZjZQVb2BCVDDJJwe7V7+GVQtnoc8nO5HQTP5b
wUwD1JKMv2F1bjw+SQpD0TrOJI8G5baafFsrkqL05UitWoGpI4PgGzMH80Km4q1dj+GNiZY534BB
p8cdI4F60ho8lOCpKb65gT7CRE76CKz4EFMLxGCsqSQsRWkA/ogdEwGUUu0nk3d8B3acrUJoNwMu
5SlTWIERY/DIQzHoJiAI5tQ+7N5/FjyxAl0wJkx9BEMClcaw4OwhfPHNSZSpvd7AIeMwacKwhlNO
1KPevW03cowD8ehjD6H25FZsuxyC2dNH4eaRrThYEYqQkhM4macQCo2djMmj1EpRU4D9O7/AKZW/
0CERKLlcjvFPTKMGMw87/rEVxqjJmCbhVb7tvSrhh9GjgdXz38a4tEVWja6CxU3AoKFRCLDRKIWG
+gug/v360Ls3+gdRZVbQoAgJiAgBNm3+DkkLVc1ovISt63MllHjnf72aFIYfFm94AwmsHNgERCL5
jQ9RljQLS9/ehZ1L7hfeIYEhCA0IEvbQ0DCkbghE0qyl+OzQU1gYJ5FFMIY+8Aiw/QCuGGYhyoum
CdMOI4QSnHv4K5w3JCHGy4hT+w+TIlqKIGL40IZUvLk6DZz7IaNn49eLnkMUJdGQtRmLPtHj0Xtv
YFnqGSzf8idwIyhN4bENWJDyD4xd+h6eDb2A/03LwuDEOHjmbMbP1uRiUuQVrFpP8YDyeekbeG68
kp/5hzbgN2+uRjZFGJE4A+EXv8OQX/4JSZEmKYooDFnbsSoTWPDhW5gYpiq3gDAkLXob+rxXcPp8
HimNUGRtfhOf6Onb3Rc2YG3Wg9i4bg7OOEjTz94G/pSapOSZ4TRen/cpHl+9BOF527Ao9TzuHXwd
azcx335InPcafjFrpI3OjwF73t6EiHnvkQyBIsGxdSdJR2qEBq5qGBcOe7IGjag2r3wDq7ZTgslE
T1mA1xZORfHm1zF/E/ssRNL1l7HujSRMWjgFq1M+Q+HEhTRR5TRtJQFlPoepmW0NaVvuYW0Y3jE+
rDLEmjevh5PSEAvh/OHw5hqvoEHg1YRTaRvw18+3Yv+RDFzMK0JAzEOYPC5SqBFjRTmMZQW4VN4H
idOmI3FUGAqyD+LT3WdFdEWndmArKYzesRMwbXIChvjlYd+WLbhMGqQm7xC27DsJr8HjMG36dCTE
hqLg7H58y4HSeHpSXbmIz9ftwKWyYDwy/SH0osFKVdlNGGnqigdQxqpywjuCUxiMidOmYUxET+Qc
342zpUykHPs3biGFAcQmkmJIjMWNs9koM5TzIXnGBi8TVAk7uxs3FeiDJ3/xR8QjDa+uOWYTwYd8
v961E4cOfY2vv+ZnL77OyDGvLQgsVi0NTQWi8cTzs5G7fT2yVGVacnIz0pGIl2dHA9cVnOtnv6d2
aQZGN6j5AUiYQYr9xBVKvR0TcA9mkGLad/RaAwD/iHupucvEyRyK3HgRO6kdevbl5yj2THx7npuw
POylNnFKQhSyNizCYlIYcS8vxYrlKQg4vB7zn35HTH8Ya/TITF9LCuMYpsx9AgPVQZOntyfN4K3D
rJTVCJj3W7w0PgjGyivIzDyAIo6S8LIPb8Kqb/tj2cqVWDAFWL/0LWRRPhlzdmHO4tWomLAA7723
HCMubkJadjaKKhtm4MUDe4jXGYiXCoPzmtd3jN2QnLqO4lWUUI3+ItLXpmLttUjMe/Z+5DpKU2UR
sjNlE8+iMyIr9wQqme/KYkrDdqzd7YWlK9/DMhoKp61OwbJdOQxoaQznsTMbuG9YsOpPJabsFPYd
OqSWl69x6Os0HKB+glSFjmR9ev1vSGGARpzvYeXSucjcnopf03RiYOwkzKAig+gZ+LfHYkRnzH9Y
Iqnh7TjZGWboLKXSKV2sAsQdYI38KsrCkcLg5DUW3kEiIGVRT9ttmTtWa2oXS65jKN5NYs0rFNPn
PYmLGZk4k30Rp44fpIcxdRgyYSomDAkkO9UWUi3TqPcfzDNPwY9gWu0WbD1+nBTDQOQcpQrTczjG
RQ+kq0yAex8Yg7NbDuLk+SKEDuyHMWMCMDAmEt1o8dctoBcR4ArGDYAbdDS4MZz6Ev84WYYyXQRm
PfMQulOIMBwXwYiX8AjDjGnjaBxEJnAMvs/egavF5RhC9M6JHuk0jArvRoGhmJFQjL/vJS3Cxj0U
0+bNU+xN/qXG3j8SP18+A9NTUrDtR2mYJAdiKg2ewsrclIrFopenekbMw5b3Z5kaAfvRVSL4nh9R
I70eW48W0kjAH+l/246QeSsw1GONCU3nwQ3NVTHdIxsWGVh6lVok3/Ea+cgQ81tMqJFObmD8h+IR
GkgeOJOHmbojyCZOhodSJyGeetjfXsFzfa/gMKmVZUN1+OrNTITMXoFFSTGCzFsfVmPST1Lxv6ef
QpJK+OX3VtMogDWGHh7E6K5P/hPb0tMR/fJKpCZFqVCCG9N4lnvpy/70EuI4Yf0XYs32FSilonZ+
70bymIJU6kWzroxcvgy7Zy5WaVi/KJ9C/Ewy0Gd8gOkLzRnCfK+jKTjFTMEn7y+kXn8J1iQ5SJNa
myxjspR+yntLQHoQiFqEpRfTsHTdXugnJjfI9wpKY/QAicsl5jCWL+YRiqUh9U+mBF/9wz5fo6q5
A1KBm9RRGj3mMXzy3j0o8wuGf1AkJt4bgt3VCUgYGSko8Q93ak5fK6ERqqgxJv87yaI038rvnZRu
W2mlZQwyypbbetc66HiBgxc6WIcoD9sbN4aSPORX+iA8Jk483JiXF+Xg0J5dOLtvJwYOTKYKSRP2
XuEIMLfe6BHIjf9lWkO5iSIeNBhOYsO6kxYRlheXwW1YDxgLjmDD6r0WYRYOIykM9jAWoZC6zd25
3W9giAedD0ztX10tcyW0paE4n9SaHwaHmhG79elHoXnKEk8DWk3zqKF0+Y78KVLiN2H5/HUY+gel
0ZPYlWSZvWILnouRjYIMacq7AkZS2P9vdgheWH8UL47ojTXU23/xtRh4pzFlxRi5ofDrLnsF0lu8
fWg6CvpqoX4tAkyOclyjXuxAX26srI0/xpDW2HT0BI4Wf03TUMmigb5rQjzKPjqCjEFXCeERDPUs
wHrKnLH3hZsI6IIjwI1ctZEUv44noxJxv1AYCgjruVxSGGwKz+ZR3kTZ4J/xiL4UHfUepBWUZr8Z
D5inVfzDEEfQVUzQ2ojIruIm+TO+b/gsGp1MpM1jNdj7u/nYpcKzHP1mJIppIhgKkOEwTdaRaN3M
92gMZm2mmrvGJwKH2N+W8YWPqd4UUl7OxZbNWuVCmxiSpyt8NsJX1Jw3MC/nd1i1+AWs4qgiErHs
tQVgNVHJ0Vdx5041xhqxzGWqL9K/i77lZZBdNHltlCxSEPTPFxeSuqAT4Yoa0RAXGkTjtm3NP7oV
u7buQQHVf8W4oVuvgXho/DDhZOJircNwXVRM4aSfilLeA0Jdb9ce6MUdzNAJmEe9eeVJRuKYMRg7
oi9yDv4TR7KNSHg8WQl7drKyluGm1CQq29CFJdCUwTT0RDHSth6SU/4yqkbfXj16E0wZLlwjjaOa
khxSaMRfC2bsJAn1rcPEny9HRNlavPDr1eTH/TfFcL/PRmuohjb+qqE6Hjk1mYYr7+Ld1Pep1zgb
91NjVCl6lAp++P0TKWmb8M/TPGWkMTTPvobWP0KmxiojLxGk0wAA+V9vpAkK4IG4UAt/6YgYMxVI
p5HS2mwamSmjgaDhD8Mvdy1+sywNEbPj4e/lh4GEcOUyN8uqqSqUs2eKh1+gaW2LPaqvA/GLP8bG
lXORm7YMHxyjxtKm8TSNELTB3PSV7T5unucvuYRD5GerAbwrbhqFpOGfh9Q4fAMQGRmJ0FA/8EDM
pmksTaLtrTIpY+ONyyDdqxruOJxBvrmoQUwhkq+pCklQQUePEpvaTgJp3o3wVULrdXELViEtbRuN
MpbRWCwNi+d/YpaTVkCkhLmkNjVqDRdOaxeVAC1jKBNn1CjyUgZtvGUPpYlvTpr7xowi8AJs+fsO
nLqch5KSEuRdPI7Pt54if9rpI6ZkuDHKw5Yth5BXUoqCi0ew/SBN/QQOQV86DxAxuCfNOO3DnozL
KC0vQdaR3Ug7eBB51PtR1hToXVmF0qLL2Ld5h1AKVTQKkUbnSZG4BWNy4hBqLU5i5xF1WkkCNPb2
D0UEsXh21w5kUBpyso7gn/tzzFi0SL77H3/FjubSlRR8R+K3ixNZLwnDIxw2XCmzTn6PS5eykJWl
PKdPX4JeNBYCxPEPwwXdj7khZdielo34F39k7m2rmL5RSZgXDayd/yI2HyPaNMVXmHMMK+bNp9WH
CCykBVhpcnPOIOvSJWSdzsCuda9jzlKapol+GY+EsVZvaPwHx4oRA3VZMeZutescECWmrTip4+/n
0UUQ7p/hh8Opr2Lb6XzoC7OwZslSEkU8HuaVcDbmrBRO7vQG9qazElGzsTieFvtTlLUKEUg/Un7S
bf1WFOV6/GnzMRQWXsK6JYutozCh6MISaSRIcSyehXVfZwn5lOSTQl3wNDWplEeWg0MVz3GadN48
ZtmEnRn5MJRkYe3vUpmSZlqtDIvf3IAcPeXF6W34DSvvGfdplLcaDSmBUOL87DUrha8GN3w55it7
83z8ZOYyZORXIYCmEu/qa0mhLOMEsgrNG3q5UzO87507NWUpHadLDCxIcfB6Bt87pRNdNt5BRf+K
MVmkh823e2AsHk+sxY6049ivXczzC0Xi5IkIpAGBsrSrQ0/DKTrToU5B9YzAtCnKdtzguKkYV74N
+w/SeY+DSjRhoyYiLtAdtR5jEXh2L/Zt/VQE+AWHIdjrEi4d3IaLd80Wfu7qqKNb+DhMCCPFQru1
Tt31FLrzggfrKwWK7CaH9IGbwO2Gh/51OnT/sw0Hd20VYcFhtGfqUomqRqtQQlu3Kita3u8KSngF
8/4njbZ2esNbZYMnfQ6vXkyPiFL9CaEdROswktsdNjx9Iu2Kj9WvLyY+m4i1yy5i2v2hahjjyNbO
F7Pe+gQeb9EiaMpPlGkJhgqhqYlPFpji8Qggv/RVeEGZFWIAJM5djBeTE+xH7xuB8RG0tRjjMdjE
YwDGTI3ApvXetD6keMb99D3MK/gFUufPATefpImw+MOfI4zkIJpDP+Fp+mHOlX66Dgk/X4H/SV+I
1z86hncTGIQaX5mNVniSgG9UMj5cXIafLEvhJNFurURSa6wCbBkvTFyyEXhnCZYvfQFrVRA/2uH1
8uwM7FQVGkfpq+mJO0oTIqdgQfw/aE2FtvISXsjoaBKSnDJklRhNE3Lb8PR0JeP94ufhreQYNWbN
SxeKhNHAxlO0RhQTBXcuCzaM1tsRX2HPrkDisYVYOEdmMueDsn7WN3Yi/NbTaPgn1di4+Tna2ZJO
o6PRCHbqDBsSvzO9eDJKXCFCQw4+z+fyVvKC+ppaI26Wl+LNzbLqNE84BsKtpjG2h3c3eLm7mZBz
9q/DjguD8XQyzSxTT7eWNJSXlxiCmGCEhc4hGIiAG40+NOgUVEto1L+kb34IurUER06bNCwpNs1V
W4Lj+7+DT9R9pm2+JWd34NN9N2iqPhnhtjvaTaPdiaCMBj3Ky0nx6brRiedbnyiO32DUwde3feM2
XNqLj74AnnpOVXj5e5E4ZxnmvUdnZqy23FpkD/FXSPLReZJ8msijozQZ9HoY6dS+r+ZmAP3pNZj+
aw9so3UJHcuDJlu14Rb8kMNweh2mzr+KT9IWKesp1gB23JKvbpQO6+5fDcVb5TAfjNi2YBI23LuS
1kuUaUc70XQZ7862ptEZN92+NOtX6NG9Fzw9POiOQtqExF1qVx528MRVC41Xt+7KeoMVfi0pIxiq
xP77bqwQrMJNTjpw50VPQ8NKxqyEhPLQOBvCN9PHTYeKy2dx5OxZ/DAsFj1rc3GcFmARPAYD2rd9
ayajrQPXefnSGoNpSNA6Yi3A5vhvRew6b3fsXr8Um7b9D6ZM6Int29Opcz8PUxwpDE4P8RdgSz4O
qgRPRdlLk5efjZDaUhpeeaKKaHo5wJXi9RqWhLndpyP1y3/FGwlyJClD7b8d8eVO8TaoZZolTMOl
rUjNDMGKN+8MhWFfis4QSwnwUIMWMXjIQZcWurw1Z0G9sZ5HGmV4Y/PHlrCtdJXQGsZ3hQEYOyq8
YWFtJe02Q6fKfPb4CZzLuY5y6oX1jRiB+2LDbSrBNovTSajzS8CBwuj8zDeTQ43iaCbmbQ/uHGk0
noWvPLkI/t16woNGGi70hVe6RoTERlNLivC49LRdbfEPH4UJ4Y0z1aEQbt3pksUJ9HQoF87IO5UE
2rYedKqk2WDmzkqtDQE4vRxKgBfCxboGrX2LxfA62qZUR4c1avnAhtM4JeCUwB0ogTt4qHEH5naz
k0yf6xP3TtHQgo8i6G7yVR904E1Pl9UppqMLUNuNdJotnHZF6Gi52kscy1v2NZvCo4TX0uuqeaZN
o9PulMAdKgEeZpC6UD/cB92Pf/Ecqqurcf36dZqZ6iSVvylt1+2Uf0KsnUS2NuUmeZNvm0AaTztw
XSTfOBl2UqiRgdPqlMAdIgE+y0eVQlxcSElu/cHndpFbF2l9hGy6Uloay+w7Ka2NycIZ7pRAV5IA
rWtQT4o/wiSPS3Wl1DnT4pSAUwJOCTgl0EYSoCUNMrQEXquuaTz7q7/T0IMu8aspx6OPPqpGc4sG
5zIa6qBazIyJOTQZ2EYp7zAy1onrMEbaP+Iukm+8k5C/G3CnGN4d0xkPld0K+Su7Rm9FTE2Lo1Pm
g7pHSlnToC/3PTNtECmMGro7qpQO0nWSE21dpPFRikn7Kw3tpZMd2th1kXxzKo2mNXBdAcqpNJqS
i9yJolGGG7dlpDTi7rsHNdVVuF5Q0BRsJ8xtKAHKarFB6g7qPLd5LmkVc5sTv8UEO7RjcYvT6oyu
9RKgY3ziG+EutKDhQndP6Tw8eHThSp/O7iSjjNan8Y6mIBu3Bg3DnTPb0ur8d4qq1SLsUALl5eV0
y3Eh3ZTNzZ1j05KRBl92GhAQgG7dzN/h0cbSnPi1eGxvyvRUY/Fb02ytm9c0+OFZKjeao9LtPpxF
n9CsQWHRDcya1VryjePLXq+ApNrprKCNy6w5EA2UhURmwTuFLaXh8O0UlUPxdOpAbrD5+ICfnx96
9OhBF1w73uvTXKXBxxP4MxAcR58+fRooDhm/j4+PiN+TP0ndDNOY0jDQxa+O4m9GVE0GVT7Sp5zm
YnnpAv296bvIOtTXND7SaIvKJNqtVjRedXRh1nVDPbxJ8/l7iWX9Jie+KwOyspCjDOt0tlbm1vSc
bqcEOqsEeITRvXt3MRJoDx75/qXevXsL0hyX9WiD/VhhsEKx24FrBWO87syKiJWWrfhbQdouqlBk
ovEnlcFrGvcM7qcc7uvuWCMzxVa09XYZam4AD5EO5hlRQAfYH4/Uwd/TqThk4ZTv5srUCX+nS6Az
1Oy2yQOekmKl0Z6G6xmPZPR0Bb61kfG3Z11k2v7+/sjNzbWOvl3cPLqgLinR5jed08i/cZ6UBk1P
FRe1S4TNIWrqKYtdOKSkbKzcupFfNzcXbLxWjbv8XTGhL13rToszTtPeEmiLcWZ78+ik75QAfazZ
5mcW2lYyjqadHIVZc/HZZ5/hiy/oIzBkeJ3kxRdeRP/+/VFRUYE///nPyMnJoW/Xv2eNJkYbDTzb
yUNtjoXCEEqjuCSfpjWMKK/UfMu5kcjLq2pxvsiAokr6XgaZXvRJuoieXvDTfvuiERraYNbYLJxr
166hku7AYsbc3T0QGBiIsLAwoVWlAmE9EhfihsxiHfbkGDGyjyu6ezCG07SXBFhdiI4G9zQ4A5zG
KYE7XAKO6oErXR/eFKNVGAzP002sIJYtWwYO4zYxNNT2t1Qcxd+UuJsDw1W+jus+Hwfn3VOD+t+L
GmM1vHSNb7nlYcrGjBKkXynH+esVqKdvGbNxranEyGB3jO13EZOixhHdpgmNcXlRZ+/evbh48aIQ
mtFoFB+EYu3GQ8CBAwdi/PjxGDBggKnB6u7hirHBOrx11EDTVPWkNJiS07SXBFhNCMWhvp1qo70k
3VF0naPIjpC8HGFo42bFwSOMc+fOCYXx7//+79rgDrHzNlt++FOvQml4ePAXq93o+8uOF8J5AfrN
fXnYf7kCtToP9PLVYXBgLd2QC2Tm6nAqfzcuXt2EM3kjsSBhSZMUR1lZGdLT07F//36xuBQbGytG
FW6kqfmw4YULF3D06FExdzhz5kzTAhRLrhdtSiitqacPJzUuR6PRQEBelp8KJ+VkIFwv9ZOcrKwa
GPaicB3DkrXhqo8AEHQVfHKTHC3hCNdA2pk96ccizEifGS28icoad/j1DqKF/QYcNMuDeVBYlrGQ
mxPJ8QoGiJxIt5HcVvJoYkxG2r3h0kLcJkbhEKykMB9ltJ7l1yOAPs0q0+kQ5RYG0iHZogr49PLv
vB8da6Y0aspLUEHfKPTv1pafzGwmE20A/u677+K7775rQIk7wlrj7e2NFStWmLx4mujq1au46667
TH7tbdEqDF5U72hjrK2jcxokJ15QJr2hq6MrRJSHfeybDRlF+PKCHl40FTRnhB9mDvWnnr8Cb6DF
p//aexZHc27gm4t7MKBnBP5f7FP2iVEILxidOHEC33zzDQYPHowxY8aIuTzONP70bEVFJYYNGyZg
Dh06BH4SExNNc3l6I+2gorUNL3ocGT19a3n6/LUE4oeUjz/DxFCloTm9/mXMX5uN2Svo+9G6zSpM
Q0qzV2zEfd+mYOH67IaB7BMyF3//NfCkiIPcEXOx5f1k9VOgBmx7dQpSjyg8Mq3nYvwFndPbVuDX
qdtRJlzKz+gZi7H4JfX71tDTd5qnY63VWldIRDye/eUCJEQqdEzoxiy8NukFHKZ0Lv7kMyQE6VBy
7APMTNlESZ+BDZtfQgABH/vgGaRsyqWvoL6H1FmRJvTGLDwclrIMmb0C656LsUQxZCB5ygLk+j2J
jZufgxV3lrAtcOnp+9/LFi7DYY3AQkbPxRtLkhHaSmXbAnZsohRlbMfGg73w5NMD8Y+Pd2HQ5GSM
0zBnuLwH63bp8OS8CbC9w98mWQvP2vIcHM8sxeBRw9D9FrTjtTe+w6e7qjBr3iNo3+Vli2S2ucOW
wrAVCU+PS3PlyhWsXbvW7rqChGvrN09J8QijMygMTpsYYJC2kOqV1pDdyJMf+1NKuaXV2Ha2RBzw
eDYuEE/e7QdPnQs8qMHmp7uHDj19elKPuopXr/HFma0oKMt3KEve77xv3z7q+Brx0EMPISYmxrSv
mReyeHcAK5OEhAQEBwfj22+/RVGRslhfRRdnnSioRWQPF/Ru8jboMiz/3XqUmLjiERYb7QEgP0RE
RyNafSJCImi9xg3eQeEIiSD/iBAFhX6FOzoC0XcHmfyEJXsTDudzf5+M/jy2Hlas2t9L217HfFVh
RMdPwZTE0dTUA4c3LUPyiq/FaIHhPdROhoyLYXKz07HshZnYnGW1c0MXhoTRDFGGE+cLGR3ZBw+I
N8oO4LTwKsHxA4oWeiAuVAlrwi8XFrkYxuA2+z66npgxYwpmPBGNJmdJE+IWIPl7kfwTRWH4RYzG
lBmJiKCk5h5ei6cXbSD12glMbR72HCzA8GljhULgb3Erh8s0nRr6Jj2b1rT1dcUXcPzkIRRb9PE0
cYgY2u7Ha+BYDPe6hD3UabyTzJ49e8TaAq8r3ErT2RQGp5078dxpdCMVwXalFFOAoZInYGybry7q
cYPmgYJ7emByBPUhrcsotSq19CEnXgCqp2FMkaEQ+y98gekjnrRNkHxZaeTl5Yl5O3uLPYzMOwrC
w8PFFJbc4nacFMY3ebX4l3DecmvNjN0oqRVdi3d3JWDRRDsNZsQTeD91VkMCkYuwbip5G09jwaT5
yEQEUv6Sihi1h8s9cLMpw65vLiEhKRKF36ejwfiERgSpqekCfMrST7BwvKJ05v/rLjz29HKUbV+K
rUnbkBQmKWrjKsG2119BanouVv1xOx55f5Y6omFYHYYl3EOaJx3HDl8CxnvhoKogqHnF4awSjO+W
jW+FzohHLPeADTnY/O4q/G3fYZSVkcKMn4oFC55DFGWxIWsbfvbLNDz0b49Cv+u/sL7yCfz9ecmT
UmwOrXkdH32bBe+hz+LNF8NRdOUyriCalJ4Bu1aQzC73xIMx3fHltu3EgR/iZyzC4uQ4UeiM+cfw
1m9WIC07FyGjp2BiZCl2feuJX/9lEaIsRg40WktdJkZkfvEp+GzJRKXQPvsoXp06H4cz9+CcfhZG
6rKw4mev43L4RDwQeAGr1hdjxZZUhN/Yi7dTP8KhTEq4XwjiZjyPV5LHk9xUHs8Em+LMotHf62vO
IOmPb2FG/3yi90ec8e6Fvt5F2Efp9AsZjReXLCJeeRxlWe4KTu5HsW4IJgfTAluNC2oIws1Nqk8F
1p06WlpTevk49uw7ggIxe9oTseMfwahwpg3kZezB7oPZyrSoXyjiJyZiYPV3+O8dZ0X4ro//G7HT
HsOoYCksS9piFYoU2Y7PDiP47j7IPHiSaOkQOjwOYbUXsP9UHtHxwpBxkxAfpZw7KM05jl27j6CY
ZzT9wvDgjx9CeHd3RI8Pw8m0oyiNub1HG0JwTfiRawpNAG1TEG4HZ9EJ684ywjAnTpzUUKaoaLxh
Gl54Oris8IeSari4e6I/neX46oqe1jHkQEUhazBW4oY+l+bJ3cUBs3rXOmTfOGOO04GNe2M8b2ja
bmsFyycg5ZCRYfmztGdv1mKgnwvup8V3Nx47NcOkLf8dMqhS0OashiZ7G96k+Uye01yx4k28/uY6
XNLqUl4fUE2N2Sq9TO/Dm74Svd+TO3eTHzXGITwCUIzh0lFSOmT8puBJUhjcg+fHLfR+JEUoMEVl
NGLTGHNc/kicw9qLTEUhLKGA4BFjxYgl99g5FJZk4zuhIBTwY0ezUZLzvaLE4sciVKfHhp89jVXb
SWH4jsZoijs7fT3mz1wB7lsZa4qRXZaJ1bSTYz3PCRVWK4To19u3EhmbX8Xi9aQUr9Ma1osJ8DKW
4dvDmTh8IJ/Gbkbkn8lEbmY61q/fjoCBRJzXr9Yuxk4h0HysfCFFKAz5uAYtAABAAElEQVQa2iEg
ZzvWEq3c7ItQN+SZ4gKlUu4GnzrjfkXhGPQoqeqLRRs2YMOGP2CwaDcrcYYUUGbaWlIYrJQrUVP4
NV6kEUoaKYw+o+PRpywXaWuX4sU1xyhc5VETZ03xGeSWZdOuQB59Mr1sZGceRjqNFuOjQ1CWexjL
ie8MMbThOmB+ivKKoYsYSKMMxY9HGlfOZSAr6wzOnqUn6zxOZdNwT8fh1MkqycCGXdRA9xiGxMmJ
GNajDMfTPkVGEZXxouPYSgojeEwipk+jkXZlDvZuPIAav4G4J6InYbsgLPZeDPLjWOwZqhc1VSgp
y8ORg+cQnTgZ44b4IYeU2/4LXkicNhmjwoCz+7/AZSrjtSWnsGHHEZpeHYPJkxMwEJeQtmGPGJl3
Cx1M6uUSckrtxdW1/HlN4VYbqTDeeeedWx114/FRka3nnVOkLlhhuBbmX0JxwWVUVdnfcmug9QMX
GkXoqKd0IrcSuy+XopqmiISh16nckziZc5SG3W7Ci0YwtGZiMX5WYDW/PNzhxdni4mKxGC4VgwZE
fLucF8KzsrLE8IjhXWgaLba3DnMGe6K3dzMUxuh5WPZyPJHPxvKVe1EqNgBoY2M7NSrbt2O7eNKQ
nrYJRVrlYBqXkdKxRiW3X3QiEqN53uRL6tkfw750amwjpmLmxKEmaGOlOpni21tMY7CsxEPVclC4
Mv2Vk6uZuCdMbVxeocOoL08m9ztcU0lJ4rqgYYgTYUexb89XQkFMWbAYM4hs7ncHkX7glABNnDAM
yPkSq3kYRMrr43Vv4I3312GeILwd/0c75MxmNJZ/sg1p65JN01KZq2mNZxW1pCGE+9lChHGjTbIR
E340d8WlQOrkGcs20sjqfSxNVNKWTwrRmH8K+ziJIbTW8n4qUtd9jCmqXtWmVfBgKKDGlm0hGNLX
V3id/igZvDFiJvXKuGf2t9MKv3LCccbSD7Ez7X1471tHOUpZMHs53n9jCd7fsJSokCzW/w2nqaGU
PJrjlBRENEp6SNortryPJal/xYJ4ZpJGaxe18mFYA27kqfVBQRXKrSz7CO0M3CemYffRDsGDpwpI
Tkodyc38niBDMWPaOISHhmPctBnkAk5kkspmnUXGUFENN1IUiY/PxMTJNO3XLRDDh/WlED9ExQ5D
r8YWp5WoEJbwKGLDQzFs7GgqZUDsFBpBBIciNu5ectWImpqbeZTsoRh/31DacDIQcQ/GkvsSbWzh
MZNSBvOKy4W9q//wtHh7G+4oS8MKY+7cuWCFYasdlHAd9RZT03QSXKxgkNbQ+foHoLqqhnYSWVcE
M4t9/XSovazH1WIPRIV44kQe9WCqShAf2gPdXEvwf2c20bW5BM/1hhrBmiojgny5cNs3vG7BR+15
zvDAgQOIi4trMCyro1HFV199Jbbi8vZbPkLPA4vhvdXaYJ98wxCakh2R9Aqm/C2dlMIy/E5tpCwA
qRH78O2n0NNIDZsIoOkvpZ2yALPnKEM4Jv4Y1LNNo3WHFAE2etIDGOQiWj2Fop+6BpJ7AXSwHZEm
RVSOs99zE0dVN6SHeNv6MeScUkYqIbQNuQFvVOmpcU5Ly8SqVTye8cM91FC4Z/phEynAVMGGH+KG
BcNwPV+Qj5gxSTRWoAmbe8dGY3Um45lNxOwnMTJIdOXNntKWexnXqR0JVWZUpK/mHYF7acMEm4B+
AfSrpM9w/YKYbop4MF4szgM90JvTYqkrGY1mUIIxLIJm3WgUcZKn2AL80fPepzCDaJ3bvQmZhOOp
QCq/IbMxZ3yYaLRVNYb77lMbgYBRmEq0VmdXakY0pChMeaAlpNojxuIu5q1eh+h7afqPdvt9++0P
tKEhxhKYlaanmRMuP0MmJmPCQLPsanL24eMdqkaopcY4eJBmw4A/BpHW4DLhFjgcE2NvYM/xfdh4
ch9R4mmkR6j3T4qECVNDz+iNL44o02SeFsNqLwT6qfXHu5tQIkxRkVUOtpIC15qqKhph0u4Zjs6R
mLQ4t7udF6F5TePTTz9tl6TIg3tMnBXGSy+9ZFIYykRQu0TbYqJihxkpC74enZpfuHrSWQtPb1+a
fzX3t6ypDw/2ho/OFddKqMCT2vGh3tIPZS74NCMHK3Z/iC8yvqBekQgSCyU+tIJ7dwj3VOwbvqmx
b9++YlqKhcgKwtqwH5/j4DevbbRqro96bUZqoub9dq6IhmZLGhofP/QmLeFPcXF8AdRANauiVHog
Im6i6M1K4gkTqAGrrpROeIXdg3jhSsfbGzNM/vmHPsd60ab6YVAfc0PD03bV9PC75uZ5rFn+gcDx
uzvU5g6cqPEjTTSBe3BXgC/uGkmNnTR+EzCMdlbpKM/ZZH990rSQfOVioQKldC4Vu41fv+gpmB3P
ffZMpLy5jfrZ9o2PDf3u22eQmEbLpqmrLG4E9RdptGqPhhfChyqjlE0ffQ7eYxAal4SXfvpjBNtC
8fEwtaVGVe45l28okMYcnMiWSLWg5pBMJi5zS02m8KqafuFSf2j6SsVG0Q/XhOfQaNkh4iqkGiJR
WVUlXaKRNQ0ZVF+aXTUZYc27CnPf3YD8PA6uQy1tc/UcFI9n5s1D8qzpGDPEm6aRaEu7VtA25Goi
brJwL46NJmJy0fJjA1NbS2XUbzjt7JqHp59+Fs8+/TgSxkxAdFA3Uk50CzZhKFJqgNolPR566CEs
XrxY7Ohs6wTKHVlahSEX3G/FKKe56VEOEnJZp4dniMrK81FNt9yWV9qoMCr1+/r7YnyYHruyy7Hv
fBlGh3nCpeo0jpzaiHNXv6ZtuJ7o3qOOeny0EE44cQMfxL0Dxjrkjaea+OAeL4aHh4eLg3yMwGc3
6qh2+fr6kSJzEyMQPvgXFhYG3o7bGsN1xT9mNlLiN2E5Tx1ZG1oon5641sI3eu5KpCZHmfzMzb/J
y2yp0MPTf5jamyVv2uoaF6AD3XiiMaF4LiUR6cvTkLl6IZL2RGOodyEt6CqtZggtFvN2WbPJRsr0
RLOTbC4ufvi3Z+JtKrSAqNGktLZDNG+j7kUQZYjLMM6LdLF2EhJ/P8RYJ/JBTMFqbM9ejf94xwOJ
fieRmsY8ROO+wTQ6uGIRpYWjz73T8FzyNGQkvoDMw6l49+vRWDjKAkRtkC39TK6g4XjED9hUloYX
JqWZvG1bdBj/7CuI2L4Y2dnrMWfSlxgdH4oztNBgIwctSIQ/MAlYvwrpqa9hDZKB/e/SlmQyo2di
uK8/algZ0QhmTepKlN9bitUi/RYkyJGG+a8GIjnqOv62KVsE3t1PDq1ko+yFINJg56xRrd2ahj5o
0CBaUDiFPYcG4KERIbhOC/pnqVUeFtEHNTcOYeuubNrYMB33hfdAcG+K76yaWqF5jCi6VoS+ob3g
XleAfdv3wy1qAq1Z9LKOscnuvjwlc/YkvsnohweHBSH31DfYezAHCYOGoBfxzf2Ifj1Jgdym5p57
7hHb922zzw2ikpcMJw1f57Fw4UJxTkP6tfbNCoO3/7LC4BHN+fPnBUlu2zjuxx97vLVRtD0+i0eV
D791hUUX6ES4ETdL7U9PMcozIwOQed2A61R2s/MPorZsNcrqCtGvny9NTdHWWzqlzeseQd36Ys7o
nzKKQ8M7rXhrK98YyVNVvLbBCoTXMLh1u//+cUKwDz/8sLiYi2+T5Bsmm29UnADZA9Vh4oLX8L/p
KWKaR/G1T7fSon+lU+e5rZWXOQ6eSnjwiURaQE7D6CcmiumHayrTkoPQiYvwoXsgXlu2nhZ/afFY
hNPuonmL8KtZcQ6TGEE7jZ575SXEWSgWDUpAFB6ktpBHLaPHR8OdMzx4MFjtpJH9wQeHqsBBmP/J
MpT+YjHSN61Sprz8orHgD68jhgYhcrnEm7ZTm42aTtGDj8Gri6dgzjJaA1r6HqZtmWEGI5vNJSP2
F+MAf/z045Xwe/dTnKIF5D73PgDPo3/DJpoZsznI8Y/DX4jX1N+8KRbPD9PuMV7jmDL7buxbn6bS
tIheOHwjk/Dh4iIsJDmvT10u/Phsx+/UHVgjkpIRsn05Ldhvp2k5PzH64aZZ5pOk6HtmPVZ9qzQq
Uxa8ZzrrI8P5HTI0DMa0bJROGCjOM3DPnDs9DYwqTq/QcZg8qgI7juzF308qUKGxtFg9kBvm+zEu
ogj7927Bqb1KWNioiRhAA1A32v4d6nUWR3ZtRBlPf/WtEB9Qq+xVZkNp6GiEQFsl1a2+DXhRPWjm
Ae7BcTQlVoRdB3fg44NKQMSYaYgkdsov8i6uQDrgZ49C5/d/4YUXbDKpHO4zKw1rIJ7daMuDfTwV
LxUG0x4xYgR69epFxxUMIp7OOD1FB/kUnUHTU9Q0w+V/d3xGtjoU3CjEU8kvWsvMwn21tBZrj2Xg
TM4fUW64QMpCmdKqozlPT3dvDO87Ck/f9wqC/ftZ4Dly8DmNjIwM8D30N2/exM6dO8UUV3LyUxg1
ahT1qoWac0Sik4exlO2lwQg9Tb9V0dX03ehcino4/Zanx6AnHmrd6GyMMmXVYga4RIlZz0Yo0EHA
56cuRHZIPJa/9SsM153Ca7NSSHlGY+W2VKstt5a0mNfyKjRTXgaSMyF5doNvAyHz9wmqKMgsf25I
XKoysYB4zIyYh220tbmGyiYNIwnfkh+zqwBbVm9ByPSnERdof6rXDK/aaHHCUFMLN/oImru1jlHD
3GktzzJIW54MOP75Oty490k8Em6vVed8MRvrOsVTn6bGqgE/tUT/I2SGTEbyuFAzkU5q41mJcJq5
aKoRSoPrpyi7TcVS4GzFZctPS5UPDFpPtcstvnzvlCkftEh27I3FZQet2d4vz/4Vuvv2gKcnrym7
gVYqaEpJLHJoC6Jtuv3oCOqvHojBubwU7Dm/A5eLsgTgwF6ReOiuyRgcHA03ItocwwWYF8RZefCb
p6fqaQ2D7V3f6MAbEVrZVLdaTF40VWO3LWw1dRsEvGKwgHayzV+VjpQ56SaAKSkLHCoMBhS8Nltg
XiRneyn0ImVpI8xINz9zhNf1Ymtzd1Lqjk0gJowKxMadxzCSzqI0WW1Qx8vL3nqizTCrelpzA8W9
RuF+mwrDUlk45l8NtYqzpuA4jhR7YeKjnV9hNCl9HQzEU17S8KiD1zJYkbDhq06GDhkqDjtLmE7x
5u229PBaGG940vFHNYSWbWL5YqUQFTJCPG2RIB7C9+tnHpkEBdHZBVIafn7du8Aooy0k1DVpRCUt
wbaH8pFz7TqdiPBGn/5htONOOxXWwen2HYa3N3wCo66bmGJsSvXoFfsIJvrdEOs5TVYazUqmlcJg
XPdQamSsG/SmcNvEiD2CMXF6FAa2T4KayETzwMTIye7ovnm07EFzHPZMU+Pn9Q2t4bWOk9+dbJLS
cBS/lmZb2blzz7uneJ5Kx1tYxeDURnlsqwibQ4evD1GGip2EoeYw74RtlgS8/IMQSU/nNDQCCbAx
AnHIbDcM5EWADjP2G7KWsuTuHyq2+rYUvyPwamhjT8vWP5vOLa9B2DNVtIuOjwc0Zmx9J6Op01OO
4m8s3maHC2XBE8+sOOj7RYqVl8L4cRqnBJwSaNK6TIeISenpWUYt/VqjMLpOB41nLnibfnNMS1Jf
Wlpqc6NDS+JvDq8S1l78MrzN36Qe6l15BYiuEakw3EQZXUmhryxu83icBJ0ScEqgPSTQFopCy1dr
FI6WTsfbeZGZN9UUFBTQLRdVNGnRdmljWtzDz8/PFye3OS5rw358qpu/4c2wtzp+a37axM1aVd05
xdLUudV7oY4+wuTh1uzVxTbhx0mk80qAC4jNXhhXRBtzxnbhO28SnZx1MQnw1nw2/DEjecGpoySK
nXJUlpvTuPNogr8qKuPS0pd+HD8rr+aapkxPOYq/ufE1HZ5aAq7gVPdp9xSzSfu5dZ5Nx3dCtpkE
TB0hyhObDXSbxeQk1HQJONVf02XV+SC54ZaNd2PctWbLrT3azYnfmkZTlIY1Tru764krrhJqC6Xr
0XuAuKa8Wr2LqN0ZcEZw20jArhKzMcrgRNmFv21S7GTUKQGnBBpIgBQGHeUjw5qDLq4tK7pOH4uh
e43oA0o8B9gpjOh+d5UmiARtp5HtFLJuSya6SL7JKQutaJozfaHF64x2h4f7OiPD7chTe4w0WsNu
Zxxp8NE7/kY4G27KdIeOnRQH63g1/l/pet5OYbpI46PI0qk0OkWZagYT3J+6U/Q8i4UVYmdsrJqR
ZS0GFUpDjJE51zvetGc+8OI8H2lQzlzY7pTLDoW2k8SQ7Obzc/V0/ZOOv7vNX9Fjgk7jlIBTAiwB
oTaconBKwCkBkgCpCvHHnwS3+NyrUzpOCTgl4JSAUwJ3lgR4e/APP/xgOtvSo0cPDBgwwOJwohh9
0KKGMkWl+Ub4nSUqZ2rbRwK2h7ztE5eTqlMCbSWBzjE11VapaSod/o7RqVOnxPKExOHbxvn+v6io
KNP3i3i1wIVuMldG4LTl9sPFy+mb3/Sd7moDHn+84+9yV5qdrtT4UFp4PlDmShd+t+d8bBcWmzNp
Tgl0iAT4okS+KNbasB+HDRkyRAnSrnlRc6brGxBEu6foiu7K8lZumeSGXjaNXanRtxZpS9zO5rQl
UnPiOCXglED7ScDRdSsWYTzUUP6JGRppdPPyoW9sGMXKuMJeaxr8luGK3Rt30naV9isHTspOCTgl
4JRAkyRg6xPbEtEiTLbN4k1rGnzNrbGObqMS+3Bb1ujLiFry5l1bZ8+eFSc4+Vp07TXpLaHnxHFK
wCkBpwScEmhDCZBa4MGGuNaWFIcrXVxIhu5eaeXkVEtZvHbtmvha37Zt28AfJXEapwQ6XgK3vvPU
sWm+09LbsdK+3WJXznWQ4qBzGnX06VddHekPsqJeDkFucYr4FDpfLFZUVCQOndzi6J3ROSXQQALc
hN4pU6YinR3UYWwgeKdHp5SAONhHOkKeeKXzGnQ/uljlEEOOW860p6enqYLyrZAWc2ltyY3xEl6n
g4yJSSuQ35Z0G6Wlx7qkRCStybABqcc7xNOKY827/58J6TPeQWLiGuhtUHV6tV4CvHVBVBbe+daF
H55lcJr2k4A8fS1PWrdfTO1HuZ5GF0JnUBS8iuHqIi6iEl9jar9YHVD28fERIwyumLym0V6m5Oj/
QnyNumw7dp2+xU0t3Tpv++J5LyQsTkHiwOZ/7c3L23krcXuVFUmXFUdX+lMUhHWKZGqd7+ZIoClK
QMLITod0NyeezgDrypqC/vnT4Kw/XPmb4Ww66rt9PXv2hK+vL63I6xAfH99OU1QG7PloE0LmLkVK
IrD202+g3Z2cf2wzFtBogK9USUx+FbuyzD3/wtPbTGFJz6/AsUKJacChDW8iiXHoWfDOLpixFJk2
/mtA9qG9uFxMn440ZuHN51/Hrr0bkKzSfH7FNhNNY2EGVixIVnl8Heu/ygL8ZAz2ecna/CYWrFhD
uAqfya+uw6GvN+N5ybcmDknN+e6aEuCqrlb3rpnAW5wqVgL2HlussPK4XY2LqxvpCPqQBi+E03Ui
VJJIg/AUVQeY7t27ix1TzEyfPn3aR2kUHsGqbGDWxPGYMGU2kL4OJ9XBhjFnF+akrEJh3MtY+eFK
vBx5BstfSEEGt+P5ezFrfiowNQUrVy7DI9iOlFkrxfRW1ubXsXj1IcxYvAIrls7D5U3LkbLO1hSU
Y6HmHzqMHyprAUMlLmanY/mybZi6lGguno3s7an4pxgVFeKDnyzE9suRWLryPSyb4Ym16w8DfTwE
cUe81OgvInP7epSOXYaVy+YBh9di8dK/YfzSlRTHDApLxecZzVd3jlPlDHVKoGtLQI4e5JtTK+0N
lcPtraq5babE0RQVTUvRUINXwclD/HdILvOaRlxcHNzd3cXuKb48sa3N6bR1RHIKRtPsl9dd9yMa
ufjsy0simvN7N9I7EW8tSkJUWBSSlryHl2ePh45uiT+/6yMR9sqsCejffwTm/PJlcm/Hl1nX8dXf
DiNi7mtIGhuO8FGP4rfzIpC9Nh2FgmoLfnQKTuLSVMwaH4OYhDmYSyOJMmMtjDlHsakMWLByMcZH
RSIuaRGWzwgBxB2TJY55qa4A4hdjyaw4RMU9iqmE5jf7D0geH0VxPIvZFAcl1WmcErgjJcCTdW0x
/mqoKMxKpONa1zbKUlIYdXT3VC29OZ06oUVIborw2iiSZpIZNmwYYmJicPToUURERCA2NtbmR9ub
SVYFz8HO1TTMQDbmJG43k9jwBQqnPgdwozplIsyrKUFIei5ZwJ0GfwM4DS9MTzPjkU1flIVvqRHP
XpuC6WstgnCZRjABthcwLAFtuIgTBPrLtQojpPo0FF+hkGgMDVY1C7mGTZwIbCII/Q8OeXEnWL/A
3vTLRqHpa5qcM4LHKk6lIYTj/LlDJcBqw57iMM+/mG13npiUq/Pl9JSOhx3K0ljHicLb2xsJCQng
MxtffPGF2EHFfjdv3kRISIiYvvLy8mrR1JX+9F4aG/jRvP4fEe3NzaYONVe+wPxl67Evaw4iOdn7
vod+4UhlsZp2Wa157R+IXvAL+FTTuCFiHja+PwueBsYsxNF959Fv2N1iPaHvix9jycRgUBCMhedx
+JQRw+wqDHOD71jSNFVlZXR+vcgnE3k0ixTJeoxMXsZR4iGGVtgH4D4aLdjj5bwCbvdXKia7AM4A
pwTuYAkoCoUFYLZpxaGokq6tUOQZPl7K4JkqVz6fwUnu6GT3798fkyZNEoph165d4MN+8mE3377Y
fGPEN5+upU76U5gUE4mwyEhERoYhKmE6TVYBq7YewYDYB2kOaC3e3nWaGn89Dq1Pxfr/z963wFdV
3Pl/k1xCEhIChKeAgGD/YMFWtwhVtIuCZQtuRbuiS5G2SNG19APbllapFGxTXXQbtpTWLoKl1CJ9
SB/StfxRFHzW4tpCxf4JL0EeQoRAQl43yf/3m3N+58w5d869597cPIA7cDMzv/f8Zs5vzpk5jzf2
oaA4gks/MYUuJ1ZiNeEQiWL31iewcOlivNdYjJHXFWHb0kfx0n76eHztUWx8aC5KV78daOKRQ++g
fP9+lJeXq9+uXftRJXvqgVwWIm/waFxLxcXfXov9lbXgzfkHVuy09zSSt8XezkmgNYPOeCDjgUQe
4KnEOumO/Rs00SSS2eHw9uRgfVWDQmEzb4TzLVTc+nZM2fRFqMsvv1zdRcVPhnNw5Vf37t69G3v3
7sXw4cPRowefcSeRanfj13Sf7eTS6+gqQU8luGn2SGxc+SscvudRlM48RJPBXGxeyjRFmEmbxKPy
qDhsGsru3Yf5hNuocMAtCx7DmGLCzV2Ome/PxeK7bmUmYhuN0sc+DWbzp1y+Oti2AneTLW7qh6W/
+ZG2PBRBASFzIzkOSS5dtVhLRwPwlccW4PDdS3HXrTQJUho6ki4vKizSMXFs8bab5JOS3rkuNLM8
Zfkw8zfjgXR7wAqp7RxY09AonjOyKD5n0aWGmhofmvnvzY30KtzK6jNY+jRv/LZv4o0W/ijIzp07
sZ/OzI8ePQr+UMi9996LIUOGtJ5x0VpU8RIU3f4bE/gFl0c4N94qW6K1VWp5im8bbv1EbyOuqkXE
YAfrbltbWr+1GQ0ZD2Q8kD4P+D/3+tprr8UIV3vcBOU4PHbsWIX/9xnfRFFhN+R3yqP3TuXQCTjf
PcU3UbX3+pQyj2Y0Wi4bNGgQevbsiePHj6urDJ40+HmOVk2RPHpeJEBDHBwH8CC2AGktAEfUMy1B
AtrWliArMvCMBzIeON88wNdLvJ9BUwXdPUUzBxrpU35wl0U6QoO7dOmi3nzbt29f9aEQ3hjPpIwH
Mh7IeCDjgbb1QLOaLLLQSBMGzxJ0pUF743SVYb/utm2tCaGN75rKpIwHMh7IeCDjgfbxgFqE4j/8
cF8O33jLSW1y8HSSSRkPZDyQ8UDGAxkPaB7gqYG+Ea52MqhIr6Kip/1oBqEH/jIp44GMBzIeyHgg
4wGPB9SVBW2Mq3uneFWK3znFVx7NmVnD46hMJeOBjAcyHsh4wPJADu2Cq41wuuqgt9zSX/rPW+GZ
lPFAxgMZD2Q8kPGA7gF+Ily/uza7iS47mpobeZFKp0utzPPOhTz3nKvtP1ftTm2UZrgyHmgfD5yr
xxnZzQtRNFXQH7p7qpFut22k1x01OlMJY7h1SSQ/udRZFCd/3YKG/9tS/vCaUqMU+4Rb6tJ+gXe0
XOwUu6QudvvrQhc2byl/WD3tQSdtM+kW/5lw8WAiM1V+kS1yuN5SWSKzPXNTe/wwfz2evYlo/Xh/
PZ5sE07nZ7zUpW/8dZOM9oSRnfyFV7ab3yASaaRN8ChdaTTQVFJXRx+R8CRpjQcYW4lHxo4RvDgp
VkJ8SEv540tvOVbsM0lKtc0mWemGJbJb8Km2oaX86W5vOuVJ20wy29tfum2p2mJqV3vBfO3hJqn1
ddsePgN26mHa65MX0ywN75HNhGHk6wI1WTpYlUkWixPbla4YomCA4g1GezCNfGWQcrJeiZ7Fz2bQ
/8j4u/6Z8iz1htnO/ExEjJc0TWylKYljlEz7nYgeTwiBj1nkmdBhcD5x7VYV+43tt60SGjEyUfuC
6Jnfj2MYyzPBBce5Pwm9bTej9dcISNnPpnQp4hiMZUcinIHtnAPZvtO/o+D4K6AvAg8t31hgOk5y
CFk1+6/QKgIPJngM6Dw+lo5eZdP9fvD70VMnBsXDDZPxrTfSQepAuxwPZyCPOQ6YX0+afuM4IVrd
9lD9rsnUVYXhrapqwatK+ZOv1D7+5Gt2A33kZ9dfd9LylMxEAVaxhUaU5inCqwOHe5nB0hK9dWHL
Rl0sM6yAdqALar+pLSaYmGzCmWBCnyhPxEt47jfVdzwwLrR+S+S/OHh+gRsfGM6EQTXrfsRYJn/w
0yn8wzpelylaEwHD/IJ0JedJOdaPhkab/JPIPSH8px8b/n4wWKF5nIVbP5YhP2+H0Ql3gN0sKL58
S7qm0C3GkekSJSiRct7/5hTZ+j/P4/0Dh1HYl97tNHNmjGZunH5AmEQbaZSh9McXgDy0vsYwjpOr
j53r1hWveeYymdVmME+bRKun/VZDTe3THe7H++v+pnv0Gnzp+lGM8uYefkGRHA6EolvAHlqDLqYT
faoXtXGjeP3Gi+BzMOf2OS5Q/orfCPGl4x//OGdhCiZS1aB3hPp9z6sEkmJkU2ixJjKL4nzyvccP
4gBDLl5klN8/fnK/TJ7wY/wXEMkDwDj9xiYcXfMgfWPnPUed3eVO3ZoCVMe7x43vmGFiGTNcFls7
9eyP3nc+gK6jb9TwccYMM7cgse3qRw1meyL/9C83gT+xym9ANCXVATxInZ7wVBRCNd32inK4Q+uT
yE7xgfSqCafD9M7U+dq7zHY5g5Nb6DHarUjJpdUs5z7XqlzUB4wPparx8H5ZRv54dmsMYq8GSqrY
UfstqUaEJE7GV3zIBAUeXV1MPxs619XrR/rruuTztBy3yf74RT4wgJL1jOX/LFTShHGi7B4URrKQ
l+++ElvwLFfvc4ZL//rLlg109NjtEXzd6aNKB+b/CMVXfdJoqsg0IpMEZtGdU/xjR/FzfZE//Pr3
2LtrD6prqnHbbbcpcTEK43WCjVOBgRzA//h/jIwkDT1nyBO13xAZHN8wLk6yBpqXwOElsB+v47xc
hppmN8uJ129qUuRODZ2SoQ0ttEMS+vsgvJFuMEjEE6sjllf63j+k4h26ifR2RDz7QtoaZB/7QAJt
EI0HnqSTzDZYQo498SAK6ZUbndkAXvG3ZWfRW/+co0LXx0Cp+8uMYpww2niW3Uw6WFfQpOEdM6KA
ZKWS2Aj6ZfFbp8iGyJhPXE0fAuqE4n7dE3aGpc9ngN5QJTieVboHbDoffzxu5Vym70jJZ7/PO6q/
HRg7P4kUc3D4IkIMPgnZumEpydHabebX2srFjtZvyfgqDm3shJq4sWZ/BSvx01sBwfKvH2c5+sLw
fbDH3MEZ659gLhMmWf764+8hNz9HndDxiRiPD3+Sw9gb2KnnBKEx6DC9nEtiWVdQirG7Bccfb36r
t9rayrK7de+G6266Hr0u6qNAumFmg/zaqe4H2YyJZTEr/UvgrCb6gl/1S68h+gF98tXug+j7x1H9
pzfRVOu/TdhsdXtAnXYZ2keNDjTJ4dMpbDcbcUQXBNdFeMtJ6vcyq37zgVSV7eADJeZQiQGYuM8N
WGxTGCI/boOfwsIF9ZEJboKxZIFLzjBJApNc4OdbHqZ9YWiC/JIsr4eel3GcH10RNNJx5tRdHD3l
oOD5M+5DyU/L1a9b2RZkDxyq4Fn5XVD8nd8rOPMHydHb4LFDQwTBNZLERRrC6oKDxnZk0fyvoqh7
CY4dfR//+q//qph1JTzc/XWvBkVhjIGM4ST8/jrjjtNeyjt//7v6dkafPn3Qv39/BtuHncXRUHEK
x7+/El2uuhIls+9EU0MDPvjxT9FAE0fnby1Adnu/Pp0CpYRgyxuqCU7oUDjfJOH3hVWXv+aJ1M9j
aXF1iZ8ZosK2xy7hFi53H0Yg/lyXxzi9zvL1up/XRG+iOVdhbtvdCVLGgL/tMppj4W7rY84MCeXq
cOn0khnP/ewdP66FOve5U3bbKWPY2z5uiUtjtUv8KXCpm2iFxuK0/ppggtdlCUzP5UYFazwEHyf5
M+9HwcQvOLbnlAxE0fyVOPXl8SiYcT9yBg5Hw4G36Wlsd2T57UpUt+wSv+lWhi/z3bY8hsWKSI9u
xfQ51bMo6sJfqI5NQhhfrQohscwKouMsKdZflszPhxzBH5/9Izp3zsVll12Gz3zmMwquC8sh2/Iu
HoDKX/wOWTk5dHVRhzO/fxbdPvsvyMrtpJO2U1kOS8tbXl95cZaBLoXbFS7MCvnieWmSi3d5BMe5
6EkEc/HCIVOepcHVw8HHSjrMzC+yXKzZIh1/LpfN7dVb5PYSe887MsSvOn3Ysr8vRJYFt3S5NG4p
rPyORedvj2WdtIrbLmXGSF18Qti4S8I6ryXZ+1fkWFZ4dVmUVtDW5NCVhf/dr3ztbVPbuVUvuHFW
DDyn5GIUPfAkcoePQfTdt1H54O22PF2GVVZXK0q2tNsWpzIXJpw6NpkyS1ITlxJJVxrZdJmUS4G4
ge6gipeY3k2uG1xYPNNicdKkuro6+u51FT74oJ46mF/CG0sboSW0HvfOQrTyND5Y9t/qmZKiqZPR
7c5pyOla5JrQ7qVY212TgnDJwlliEI+rzSrRt98rKnAmCjopKEFxoXs3h05pCoAWPpyeYH5dy4VX
1r3HZRnz3H/+44kBMnkn8r0u1zQWvPhz3+/SHq/PuF2CkTZKnfxrX9nLpCH1WB7hNeUij3Fu2RIt
1lhwB8tgQdkiGWeBHCobI5kXnjt8rDVhLLkDzdU1RKTjtbKjR4OJSOIxQR10EgWrvdZLC7OpQq9G
b6KPavAgdixIKE6MYQ7355Z0qFmYpYt1du7cWXUwd251dbX6toeRhz4U1UyTSnMjRUC6XMuhL0ip
RTYjsQEY3Y8lEyZgwtQyHNPQVbvWYsKEGdjRgoclNXEtKlbt+CHZsgrpMKWqfBPmTZiEW6dNx+em
T8etN0/CjCXrnbbvWDUVE374ZovszTAn5wE5bphLylbuP/4E68oXiOQu5sIpcdv9v+DWW57iySKZ
CSOcf6345faiZoVh/8K/p6FuX2W6gBSlJanKRXSFceas2t8Qfrn11eE3yND9EyA+eTDFZj6fl1P6
7LxOEXSmJZ4ueZ1DC9NdltjI2MlE+FlhQUGBuoTkjuU9DVNqPFWJkz96AnX/+1f0+PIX0WPOnTi7
7XVUPvkrNJ0JF2Irt/8B21j4mY3YtCscj8mW1oTl5Yfvg7h2VLyEGXcvxYFrZ+Px9b/Bs88+g5+U
zUPBtpWYvmQLaNqlVIgiumsuk9rPAxKgrGOIzwzlaDIHR6FvP4s7nmbxmD+3LDVD/a0QKoZzbJK6
5AznsptcjFuysLyMw5vW/h94Q9yGN9llPy9L4D2MU4um0YRR7dDrvCJXwUiXyJDctTF9JZatJl9b
SXZOJEJn7XQHLgOSSP6pIAlWDynfvdWlsAsikRxce+04++JBl06TbfVZ1JbvQ1dakup+12dRMudz
KPynG3D2b++giZa3EqdaPL/6afSbuRgLJgBrfvGKHThjOSt2PYN5U+mKhK5Kps4pw5sVHGKjeOmH
86i+CoesiIs3196n6nzVUlW+BffNoDN3vpKhq5ayDTss+dFyPDxnCTZtWY8ZCjcBc8qeQaWtNlqx
A2XzZlh8M5Zg3YvltI7k2mS2BSjf8DCWrH0Ga5cQ74xVjjyLM4pNP1iMM0V34CffmobBJYXk2zwM
GDUF3y2diZG17/vomasWr69/GFNtG+f9cJNDw7rmla0iOy2fzLhvLV5/aQPmCK20x27rM5ukrVPx
8Pot2LJ2ieOXVVv2WyZm/ho9oAcsI0EGGNoDehANG9qEh/tBT8IvueD8dQUPcaXBVw7qVePEoOvi
K4zq1YuA0+4VhueqwiRbjGnlPJufM2G7yeDsZnrLbTZde0RoX6MlSW98IjnSOZx37drVumOKLoF6
9e6trjqYn+VZMmkpqltXlNz7BfS4awZ4fyPSuyd63PN59PjsbcguLGTy+Kniz1ixB5h24zhcN/kO
YNta/NVwsRE9tgXT5i4DpizA8uWlmIiNWDBtOS3pRDBu2h0o3LMO3163A5Xl67FgzRuYMudm9KFg
+c27S/HOh+/E8scfx+LZw7BxxSJLfm0N9u3ZhqWlz2DK4jKULbwDezYuw+/UlU4F/vuu+dh4YBgW
L38Mpbd0xpp1bwC9c1Vbgm2hs5Gqfdi2ZhnWHB6G2V+4Gl08ra/FsbeAflOuQrEHDpSMmYFlD01D
iQ9evmEJFq58HbcsJBsXz8aBp5diwdodiop17dy4Dqc/XorlpbOBN9Zg4eKfYtzi5dSeWwi3DL/a
QdOg3dZlS5/BtKXLsfCOQdi8shSlm7pi6WPLMW8ysK70oQ6xDOhrfvtU9YMgngVh6eLJuIBx7D5O
8dzoxhor5giPxen9G0+OolQTAl1p8BWH/WuiXH4C41xPfIVx5vFFKP76aodPpzWV1bKVLqQVy9Zk
QdfCtAeenU2XGOwIbxMs7eIgvy28/+D8YpHUQ8TJPz0JTHIbl0d7GmPHjEFup0549dVX1StNGCXc
bFc23T1V+I/XINKrB9WoM+hfp369UfDxf6DbbRMv6ezavJb4JmM0rX7lXXo1RuIIfvnCfoJ50+5N
qwkwAV+6/ToMvPgjmL7gXjJkI17YQ8+ClIzBssW3YM9P5+PWe1Zi6L8uxax/4PBbhE/fS5PMvKkY
MaAvBn94OPHQRMYNsPedJyxehmnXjsKo66djZldaIaPXFEff246nzwDzli/EuBHDMGbqN7D0ln6A
/TaX3f+XbMny2UKT2Avl8lzKZDz5429h2vgRosZtDKk/cpzOViSxLUE/uqZ4ce0bGPq5BzD16iEY
MvrTeHD2UOxZsw0VzN9Acq5biG/dPgYjxn4aU8jEoju+ixnjRmDU+C/gDroyUtd6dlsnly7DlCtH
YPz0WSBS3PvQXFw5bASm3PkFqp1FA8tsz+T3g26LjtPh6S6zHkNSYLHBgHcOChMuVZjoC7ApVbEd
ks9uqy8EKVNVuCK85Lr9ptio4z1lngyYwf6pO6loIuEAL8/IqbygixMm+S6pqmXz0O3+1RTrKEAw
r80TP2fCtklKE/uP5gu6wODPhVN8441lXwplEnuZpiGWEZNsXAzcB+BbbUeNGoU3t2/HsKFDccUV
V9CSmfnKR2yS3PKwJdBrg9QO4dmVdJmBPZg+YaOref1zqJgyC94phyaBrM24++bNLh2Vqmo4LOah
5NppNKU8DcbeevOVFk2nPhjY7SDuu2kCTUWShjq7BRy6e3UTLVHIPWq1Jw8SZiSG97WjLdUuu/FG
4GmiUKbzhGS2JVpPt0jfMgHmHSBio6uool6xt1BHD23BA4/uwqyH/42I7FT9Lv5Ek9eeNQtw8xob
Zjv3AMnhXY+iXj1thGV/obX4RrAovU3AnjQo57Z2LZC2UoWmjWE97fZ16akmEYZ2yCTDpZWNY9fq
qvgMTtV1INE445vxPlwrm3jBiGe3On72tdoPl7p0hdR9bGoJR70+RBA6oc2cVUQP7j30lKJo2M+3
1c5C8aJVyC6gCYMTnc2rpPPaIE/GE0tbJJoI2XT50VZChCYMvkXN/JXwRHYnsln4xdlCL3Cu5+Xn
Y/z48Th85Aiee/559QrefIKdOnUK/fr1Q/+LLlI06upGBNi53Bmh5BuOrqq3n6fz80Jal38UI/M5
zEXQcPA5zC1dh63l02kJyk3Rejq3Hjobv/7xNOTWNBBlBd7cVo7+Q6yFnv3P/EBNGH3pSP+P+57C
1f99OyLla3E3ybpjyeOYPm4w8qI7MGPSUleoKtmjgCMEJ8ojRfRWYezEUVrZGcbzA6WjO7ZThB6l
ysqWS2bjVz++DXl1jcqW7Vt3K1tO/kmRBPwpxIeuK8KZdT9H+cyHMMydk/DX363Gn3Zcga90bgbf
yKdS4cW4iq4WLrrnJ/jWjX1RS3s20YrdeONvUVxG8N1CF5DXy0hycmqr1tkN3HQHp5VlAGi0HhWC
9wBbp8Kq/GY4MD+CTRDbTDjBC84RxAhKwmvVbIAQO0Ct4BegobgYxCp64uH9OH/dr1pk+kw4Z6vc
XmqTIWyoJhnhRC9uMOGtZSTXI1Z88ioq+soj6DT4MvCEcWrx51H8rdWIDBpBYaEZ9W+/Zk08LEIU
ueI8Jf8SlweZxoqELRlr2dFoVAXprICdcG6uPpY4cPuT7ZLANpp4/DIGDByISZMmUQdmYdOmTXjm
mWecH9dPnqRXiBiSI9tgF08Rr/xiDZ3Q34lJo4Zi8LChGDZsEEaM/zQtVjVjxe9pD0FZ3UzLJs24
9BO08L5nJVZv2oWsSBTlW3+ChUsX4z0KfA3Hnsddy7bh2oVP4mfrFyKL6Eo3lCNaY1079O5TiOZT
B7GhdJG64jhxSpaRNKPFRsrzhlyFawm1+Ntrsb+yFrzp/cCKnc6exqWfmEK2/Dee2PQOXQZGsXvr
E44tmkRjccydX6FFszdw970/xI5DlaitrcSOZ8qw4OkjGDpzEnp6erQYI2mS2bb0Uby0n+7YqD2K
jbSk9J3VfzPKZiBdgCROscPEy5MI76VuvZqyw3R0EizIRoKbOMRID06X4UEItXW7rbo7xTk6Bce5
LkCHJygnsFGJNdgjJ2FKuqbaaFoCEzoS2tBU27wgTADc9okcyv428pq/vqTELyq0lqWIka4MCr/2
EPKvmqQmjJP/fhsiQy+jrqBnIKpPo/q59aj8Ju0b2ktT+tKWwDw562qTxI0Wf9DyVF19Heob6uk7
4fEt0NnYTh5cnoAdMKocGkPjdJm0uYLLL7+c7vSJ4JVXXkF5eTk9qV6D3bt3Y+/evRg+YgR69OA9
DZ9un1wZ9Epv7W78ahvwqdLr6ExdTyW4afZIbFz5K/z9+n8gRAHpBToPm4bv/ds+zP+PL2Hjf5B1
9P+WBY9hTHEV1n+tlCafL+Ir42lRqLk3Hrt3E+5e8TXaF16GO0atw3/dfTv+ixzbb9RVtAzzBko/
9yRG//5qkkwPT9KdYZJyab9B7QFgAL7y2AIcvmcp7vrMGoUeOopO7SssyjyypezevZi/dC42PmLB
LFuAXVQt1FeBLLT7t2QcfkKyv/W1pZj/uaeduDOa7h5bOOMyRSf+YH+N+dJyzHx/Lhbfdaslo2g0
vvujm2lBztmWcWTnUoN65wo3tY0wVnsiyCdZnbRlTt570hPr4uUuU/L0m4mgFWGBY5TNpzFgts1G
EkksnlpOaL9c1x8k1JO47vWVVffTBUEtYSY7nM5nDWwUJbGL7bF2NBXYwTOd0CgMt8UiOSf/+j3r
bUSClhGz8pNnlmCJFl+sT4net8mt6+tywzTU73sbH8z7F9CrxVH34gtoOn1K6Wh4k+5g4R6xTbK7
S2f3lBPhPcQtqGSJIjUuaGzcMWEiPeKXjbMUoDdQAySx3bqzVTukNUKk5THOUwrs1mt0UlQD066I
Hh6oDD9w4AB27typ8qNHj6rJ495778WQIUMUh8Mr9nCj7LLfDnX0EpfbzWKBm4t+gWQ10lPqtE4T
yStEHsVHv75YHXSCTk+1R+nW1kJ+h360ClVRKne2gqsbLCwNngOSroaqqmodXWKDytmwaC2q6lxb
PJ3iITZXqiorUdcYRWd6IryQZwEt+dsRra1Sy1OF8e5Ii3GWK9Avz+90y480JgzDwsjrik5fyaBb
hCv7gsaRENl5PNqYthCPwJhd738eum5yg7VFbxkrw5zpvPTOsFciRIfI57qULV5LmcCC8EwrNMKn
Ty4MO9cSt1z3YyL7/b7R6XUcl/X0l2sGom9n99RIx7NPc/7PUDTRMnxTZbXj4z7P7yMRzTg6fogD
Y5ksOs5wxbH6KD7yMu+Nhkv8zaTi4mKlg2157bXXYhil39nusWPHKvy8z96P4qIe6EQ3K+Vk0XZG
Iz1okk0vMeGnwvXkdQU3KX4DWJnuIF1WUNmvg+lYzqBBg9CzZ0+cOHFCXWXwFUf37rwHYE6JbGMu
b+u8chgntiincfCnKwJuD3ccp3g6eFLIo2dNnBQppI+wMJPFJR3hCBNCJTtCukiZJF0RG8a2uGNQ
qELnhTRICrXGx+sjniS7SINtDUzv2K9guoHxzVBnaH7Pa7bEdWp80W2C1dsd64fkTGBZ8XwfLC2e
v+PhgiUmwvgnCOUHVnUeJX9/+uu6D6Tf9PHgd4XgeDnKCSZM5PNb4zt7LFaC598+nZanRqkjhMmK
7n8YjXt3ouapJx0aqxDw1yc7gKrlYLqooCBA45ffykHLU19asgjf/+YiNDXSRjgBOMU4iQKHbp/g
mVZ4uBwv+TuFaXVev0wOpPzr27cvGuittvzkeJiky2R63W6dX49dDOe6n9YjSwumHrgtlHn9Mi2U
hrH9a7NQZmnURFsyeOCJMMmZSRFqODFYaPx1xcN/0pxsfapPHUO9/RlGoz6pmHwaRkZLaExjMlie
ODmYQseY2sMwfZzr9OHL7iSujxvmN+nU5YbBK/uSa6qu4vwp+3wQ5Ds/nJ/2Vq8xtz3h6W9NJsOL
7/6O4y+epApvvF3Vzz75M3ucaAwOpVuwXljo1luzRKOOJgxqG5kU4SsMtQnOtYCkwl5MwLOIufF+
x4mYeDihSZTn0WvP+f1UQTqEP56u4JYJt5XHpbMPeL8drFeS8pNU9NyEUGyWxli9JgYWGEupqwlT
ds+glAExE2UiGUGW+fl0v/hxej1ev+l0rV022qs1NmD4G81yfczzvOVnd9wk24fJ0lsmiV6jgQQU
POeubd6Jx4NjM6ymBIk8r+B623X/SCN1vMBUzj7S/aSXdUKCHxk3WIc4ZZYdKoUkCyUrDlFWE41o
2pzPpn90oy0ii+fPRwm9Hr2xrt4ZSMKvG6+XBS+5jtPLjNfretmPE1lB8Bhei9Bhk44VOqk7BCEL
wh9EbsLLYc19aMKrUeTrYItHOP3azGekEoxER7J11iI8MgGxBSJPrEi2HsTnl+2vM5/0k+iUushM
dy56RG68urq+9vWb8HEej9cTOGJo3X5XPtGEujItGtNk5dJojDE6vDiupcKn87hjJ1Z2R4eYxp7e
NpN//Hh/G034Tr37o/bEEXQ23I2qxpMmxF/XUFR0x4gXbtXqaLOddbVNUpGNtjHIKrq4yO7WpQui
9Y3qttu2MaB1tXDQ8QeeOMd9TN9wVwX9TJbrXZsMnyXL6gyzXD5Evf+ETqDJ1pnPlCx50m6XymqP
Xrco9b8meQyzuITSW7fwXk5Tv3kp0lMTi8Q+q9Vike4f6U2TXsElyoPkajJJhEhxSwwJSvFwQTyp
wMUqK7f8lYqcjsTjbZPb98naKHL8fFkY8NUHUU0BvY6WqfgmKu+PYYl+wkNTSgAty66m1z8N+OoS
vwGtUudFKH2Ci/DrO+rr6CkFMqS9k2nmDmuT8MqE4dSDBHC/S9LLAvMEWPIN/Wcyv5ek7jkjFKAt
S8TrYC4L3CvVhTqmtElB1+sPEf66ZpDWqGAqXTa326rzX6efbAc6dc07mra0Fl2r3JLeK5YyHZes
epeX14S5ptyl+UyX6FJbUD+ty+ZS8kqGI1exuTjWxv5kzSZev26h0SXoNOd6Wdol7bTaI9BUWhfL
W/yPnwSWPo5Djy5C/ZH3UhGqeGIlu6Jy+/VXk5PS5YJbr+SMMZ7wmhDp0bUQJ09XoSbBR5gSWcSN
9HZGIo7WwbtBx5avvC9dIBZKnWkYptdtPn/GJLbzGCWSHLIQYkJo8UkOx+HY0E4FPguRiSBZE6yA
ZgU35k1VTrJ625peetIeRqReRlBwiy1aoWOLY2kZ654Fiham5SQSZHBaeD+VRRvqKBDSczq3vNJ6
TeBg3o1+es8loy2of5KRkU5a54SYz1AoRQrpZYB10cYWTxp+B0nDBe6vp7NRcWUpA+iPMkCs0DlM
MB2vlYVUxNkoaWPKo0RT4S2yZFHqxXSkWmwoS866lvInp639qa0eDdeviXyTWFY4Pe3vlba3QDzj
HL+2CQLnqgknMJ3OZH0ivImnY8K4JdJqmjS6FOShgRbeztJGeDoTq2BVXnXBdT9dS21xm2hJ4kf5
9YZ7DGPlMckIJCqCK5SrwZIdIyB1AMt3xDsFS3fqUjOcGQ9kPGB7QD+69bLfQSacCebnO6/qdIXR
TBsb/I+/qxGpraXJooleiEe7/fy97lQTO1IPbyJHHCw4f13o2isXe1qkP6jxLRIahjkt1odRlKHJ
eCDjgXPYA4leExWvada+GcUaDuL0i9Dz4PQOLGsW4ech4qWg2BgmdKVr0khGV7y2pBsndnE7pZyU
Dp1JnBVagM4cmilDmPFAxgMXkAeq6FVHqSbeK+b3KHKkiVSeOY0o7WnUhdgID4plOjwofAlcp021
AYrP2Z2JleK8YMtGiU6xgcEC83ObaHSYn15k6fL0stAnkqEMUkT0x0NsS4sn1N6g8jGK6kye8UDG
AxkPpOwBFV7oj7rJiHL6nEYuciJN6BqJ/QhTKlrixTaWJ/HQRBdGH/NZMtySl4/gTGArsDNFonOE
sUNodHleXVbNoTMgRb/kQhLMI1ZKblOqjGC6ICk7wnx4x9uiNZNnPJDxQGt74PQbm3BszYNoOJH6
LbfxbOzUsz/6zFyErqPpo21tkSi+ZGXlWM+/UTkSpVejR+hZjU45ndwQI0FIgpJtmK8a2lw/H4sP
UBEj06Gj9081na1BTjF93UoB6d7z2lo00fdActQL//wB0xIl/FxjO/y2WFTuX8brPBaGIAqo6fBc
6dhwRSPcFkyruUqoxHr0JOIVzNlZ1/TpxP4yCxPdIkgpEC1ihZ8xU894IOOBdHqAJ4wTZffQC0uz
0JnfeN0Kqe70UaUD83/UJhMHhyMOd/yQO3/nNTuHPiRRXX0WH5ykT8hJ4lgj8UZgacx10RzOTCHN
A6dK7e49+OCJn6N+/7uKgyeL0799FlW/+yMa1dIaEXmYYg0WdKI8llOzWJg9DiIgwz3JC/DWPISq
Ii5XmjwVH22QIMVDf5ylKp1PBOqwTDnjgYwH0u2BY088iHx6QVNnjrL2x5TSnbNs1sG62ibxk0D2
95ZoBqGbpqxlqYYof7vOEPuStMof01imJD9O4JwzTqfVcYxtpA+WVG/eiro9+9Fj1nQ0HDqMEytW
oeiT41HkBEpbA0+NwcJc0fEMYipHhhBK7opwS4wThpD6XWZPiaUEahIVHg5fRWh0kxSJjvDxZKoZ
D2Q80GIP1B9/D7n5Odb6f4ulBQvIpWObdbVFkq+6cpjlX6Seln34q3lZ2dbX5SSsBBkTGMwCGGLi
VgCdAjvB3wq/6pUgtsJ8+nhJt+mfQQVNFMdLy9BEV0a5wy9F15s/hWxaXvMmYgo7cXgYfa3zVT2k
QRVfG4LIEsG5HxKqF4KgTguCO5Mb97trCAAAQABJREFUWyFCElmUwWc8kPFAQg/I1UVCQosgf+Z9
KJg4S1UaKw7iTNlsNO4vRxa9E7DrwqcQuXgEKj47zCyNdbVBskIaxQmKJ/zuhwg/m8G33LZm7OCw
xPGLfxKipMx5Nd0KdvDQIRw+fFh9pY9f185fierVqxcGDxlMX5vqRnsZxSj650k4/cctqP7lb9FU
VIiLF3wJeR8eThJMidtE0lkBJ6WY/2gwxik4E3CKAVjgsH9Fly0pLFsQnSbOIYkx18EkV3BlWyVL
rkd6cgIz1K3iAe6doF4Jwrl9a5kUxN8qBmeEujEngS/0CYNJc0oGomj+Spz68ngU3LlQTRjRd+nj
zv4OTSA33Wj1+Vr74T5+y22Eb6PijxxF6xscXf5Blg6bWSbL0WVxuZI+R7plyxbs27cPFRUVdPsv
bWzTlQ/bVVRUpL7iN27cOAyg74NXPb8NDfv2o+D6a9FYeRpV//Mcci8ZTN/2HkJHlt9quzmi2K6q
QzCA1CGJW2CrdQFU1xtl8+pqfdTWXQhxdbQ+UrcpZW2Gdqcs61xhTIvjwjc2nrogXBDcNE7DW3Ie
UQY6qOVt5ACrLTbEFVjwSesKQyfK6UkTx6Kf0SrKWEQPvI3KB2+nb47rFG65zV4yy/6iD2rwG3r5
1ZeRTpFOiNIbbvXPvUosYFopu6amr3TmzBls27YNL7/8svq86xVXXKG+YRvJyVGTyV6aSLa/+SbO
0qR2Y6++aH7sJ4hc1A89581BlDbEjz/8fWT36IZeX/8yso0PJtotkIbwlYcn4KfYFh4VItMjIgq6
oQt5/GFxSkySSeePB3g7MNG7oDpya891+1vqW3X0t/ZByUr414KkJox3rQmjqepscBxpoZ7wJtLI
oX3w5hyavWgPPDsSyUGEntHI4u/AJkhx/R10ph8gkx9rf+utt/DKK6/gQx/6ED71qU/hhhtuwLXX
Xotr6Mpi/PjxmDJ5svq4+Tu7duH1v/wFOVd+BL2/ei+6jP0HWqr6J/T44p3o1LcP9VE877HV9Gvc
jyUTJmLC1DIc02yq2rUWEybMwA56WLJqxyoqT8WbMQ9OykigXFRJrsl6qezzmDJlEjbsr1VkwtVQ
uQtPr9+CE1GLeMeqqZjwwzc1zkyxo3sg/hjr6NZn7GszD8ieRpg8wCh1hbGIrjDOnE18B1aAjHSC
6eLJCnuU83l3hN+P3kQf9IjQrbd6kglCcg6AcVOIazKWJXLq6TbZrVu3quWo66+/HkOHDlXiRV8u
7WEU0xcFu/fojgMHDmDnqVMYO3068j98maLLLshHtzun0QxIy1m5/PoTkSwSFJnzp3L7/2Ab185s
xKZdszFjRKGDk0LexZ/AgnkjMTQGpclUVyvEIeqEuW4XfrXxiKo9veEvmDp/jCozWfTwK1ix8hkM
+/R4lCg3F6II1ua9espSZJwDuXyv5BwwtVVM5P5iH0jeKkoyQlvFA9pR3CryWahanmrBt4kaeElq
EcU1usJQiQKIP9RYCEuXlFszp3vB6GYp0kAOZFvoxqls5Od1poLXpX5DGcsw/UfVpBPL4V8DTRrH
jh5FSUkJBgwYoGAeC1Qli/A9ccmQITh99izq8/No095d4Msu7KI2yK39DJFsMqkWz69+Gv1mLsaC
CcCaX7wC+6TfQxw9uRd/2LwdJ2mJiUI9dmwow4wJE+jqg34z7sOm8jOuAzzGAsde+QV2YjKWlt6B
IxvXYZeSQc+XlG/AHXPXkbwzmD9lBjaU+y5jag9h7ZI5lg7SM2fJehyyjas69BKWzJmKiRP5CmkO
Vr+wRwUsDlqmH1ttggfCmIES41NJF+rZ97k20afSt+clT2rDPDlXhLnCEBqfZJ4wqlcvQvNp7QqD
A67Qm3KfjNaocnyw5wxr0lAHAAFzcsItT+l+b+kEwg1somWqGpoQYg5EJbwZtTU1OFvD63rNtFnP
b+FlRJKp4s9YsQeYduM4XDf5DmDbWvzVF7tZYrTmIHbufBUfUNCu3bUO81dsxJXzluLxx76HO3r8
CUu/uh4Om8eMKmxavY0mpZtw5ZgbMJKmj9++ai2CRXpdgVm3jFQGT773CxjdK89j/Js/+hzWbOuB
hWWP4bGl83B220qseHY/0VRhw9zF2Nbjdix//DEsnJKPdaV343XtGUwRFOM7QSTKU5wsdLE8cVyo
k4fuh0w54wHlAQrs6mqDN8QT/HSP8YRR9Ti9GuTrqxPyiVzt/FkX1SplFe7oD88S2bwRzrvijbRE
5U9MKD8dxxOHPnnouIRlxUxnynSFw68vOXnqJLa9tA01tTWWUA5k9o+Xzra/uR3l5XTfMsF4CS0b
OQlV+Al2bV5LoMkY3Yc2qS/9OAX1w/jlC/sIxq2TxGVeMqIPttMv0v0jmHf/9zF38hUY0P8iXDKo
H1CYK8SePHroFayhlalp1w4g+AB8mq5mNq/eRNcWtP5XPBiTbvwHKg3FpJvGY0CxvgwYRY+rF2Dh
8m9g/Khh6DtoED5MlIeOMSc9vMN/aqrQ0NwN185cguVlyzG8CwMp2cuBMmFIbqGsdglMcsVn+JMI
b2CJAcnkcSFMIKlemYnTwvo7LJ3IzeTBHtCP9GCqNGB4A8B0ReCDZRXIgUyrLjRhnCmbh+L7ViO7
gF6T5KMNrrdNqzjUiCbOI2foLL+Wloqq+bafOEmYmMQ0YTCe4UJnomFeRUD7Ap06RdC7dy8coucz
Xn31VYwZMwYFBQVCoEibqANefHEr3Yr7gbr9Ni8vX8GT+3MIz66kywyUY/oNz7isTz2Hismz0FkZ
ZFvNmf2LlPQG3noIk0p3ujw0b8QkauiuTb9WjV82+yYsYwFK3NN49dAdmDggglp1N/NZRNnFnv2S
CPr2L8ZT374VpWyinYaquakQn3lkAcqXLMX8u3h5Cxg5eR4eGDlc5gvSoxTZXFYmgSYo9xC3UoUn
Dqv/A0dBK2lufbEyYUieisawvGHpUrEhw9NKHuCAT3caxUtZRV3Q7aH1iqRhP98lNQvFi1ZZEwZD
ffx8mBuPJNbVBqmZ93HZBjaCypFZ998P3pR+//33k17bNjXEBDO1Kycngosu6o+DBw/hLL2IkCcI
1zVWmTfo+TkOznnvw5pU/NKsBlkt0nB2QK3a9Tw2NhdiXtkjGElzThQRNBx8DnNL12Fr+XRMZFWc
JLdq2LXuq1i2cRiWPvkbXNmnEJWvP4xbH1bn/jaFnTXsx8/X7cFIuhKYd21f2tinmbj5BNbcvRBr
//hXTJx1pUuvX2Qo6DEs+9xC/O2WhVj/X9eiJC+K9TOm4BmlpgrHGy7BN9ZuRnFVBXa9tRnfXbwM
3x48HP91y6WuTLvEk4QEGSkH5cwik0qMoCQApr4WN1q51LhnTdRJKLuASaUfL2AXnDNNt5aO4ptb
9JVH0GnwZeAJ49Tiz6Pb4idUnbnq/vYqLU95+Q3nhoqAdbVF4jlDJc7JmMQbGTZ9ujNeahpEyzH8
u+aaa9SVBOvgZzcqT1Wi0X7Ib8xVV2HI4MEYTHT5ebQf4PEgtcJpEJe1nzI4ild+sYZO0e/EJFr+
GXzpMAwbNhgjxt9Mi1XAit//WVHxH/fRRipTfKNXcQH9eqFHlwgqDryEh7+5GSiiKzKHwypUbP8D
3mjuhzunXoPBg1n+UAweNga3zRyKI+t+if00idBmDP2pwoHdh1DLdUm1H2AflQf060lXPLXYtWU1
VvINWHW0ERY9iEfm3o3PlW1BRaQLBo64lBa+gHy6QuPkD/oyYTBOyqbcz8f0qSZxvc5PrlPTA+fe
ZKL2UpwLNfaf/NrKXunHttJ3fuppo/HHVwlxlpcKv/YQ8q+apCaMk/9+GyJDrbtBm6pPo/q59ah8
YLaBn2w3yfRdkbRWv/H44+OZtws4xMac+7aWYr9cvmtr5MiR6qE+fmXIyZMncZTuptq+fbs6KK+5
+mp1VxU/u3HkyBF0oXex5ObaewqeicOdN2ICVe1u/Jrus51cep3VUB43iqgEN80eiWdW/gp/v572
G5oLaLlMcFSmbZNLb5iBoT9firtuflqZPvqqocCffo27V43Dhlmj7ObU4tV1hL92AS7nJUrNrkvH
30q3aS3F87uq8IUhV2NCv3VYNv9zOFb2G1xjcyNvBObdOwFzV8zHzSsIWDQaE0YXYfPTD+PNOzfg
wdKZuHthKaZttBiKRs/GY5MGq0qqgSRVPsuC2L+mQ1H6QXKXS6eOxbp0mVLGA+emBzgExLsC6HLD
NNTvexsn5/+Luq227sUX0HTmlGpsw5tvGRsddKKnhRsjX7qA9OYQFTfVJjiVs773ve8186s7TtFz
EKWlpenSE1oO696xYwe9nr1a2fDss8+qM+U7Z8zAxz72MeesOZ5AZy6IR+THUePF6THhSwDNUZyp
qkUkrxD8avxa/lwile0Hvv0S49Y94VItDlrkakDQZgepQWEh31kVRVVV1C4zDT1lzshInvOkucVp
zX8xcu1G6XChT0euTzpsu7gqrmwmCjQolIS44tsCadrg133RFja0VIfVX+eGv1vaVj+/2mfTjjs/
Pl31v1wzEH1yg8/Fc+jFq010Eqxuq7WV9t2yT5WOjh9iNCOo347VR/GRlw8aeUxA3oIopuffeNzy
77XXXoshkzHNOseOHavw86bfj+KCbnRiTR/s4xuYrqLlH9nTiJHQBgA2snfv3uohP855eYr3MLjs
T/64Yxr+TGOCiywdrxwkM4cQcC5EWREUqQ88Wcg8rayTCwvnHt1csY0WuF1lUjfRhOCKjlBZH3QR
mqfc3XNNpIh25RDEKF+jSHdRXBVXrhAZjROgeCiupHZHykHV7oZkDOiYHuDhLEPaYGHjO3scaP7t
02l5SlYtaKHh/ocR3bMDNU896dCogjrV94IsuAHWGiC1d0KNUrGSNsJbQ0cyMnPoPVP9+/d3WPr0
6aMmja70skL9ADX1A8M41OjhRi87QrlgIzybOkHE+hkJM5iUe4Q74r1QMVByNiOELK8Qb00T5SBE
pD7/cRP0ukPcCgXRL6J1tzr2+omE2MmFQOd2kJlCxgMt9EDbjCv1jqaQT4QX3/0dT5u6TJwG0O/s
kz/zwIOOY9bVFqmJYwkHFPrx2kLk2LFjziZ0WxiQSAdfPpmWPbjLJayIjMBhEBgxueEsyCuJa0oW
8znJptEyi4YJbDqfHIfVU2BaEuIo8SCTrnhMtLmVNbadCuQYqgOTVhWKwfaEp29Eqx8n9fiCraul
jnq3lRqbfPBQ3+snNfHblMG2twfCjb00WMmDXw6ABOKOjBucgMJCB55ohtQTSkkComZa/eE7XPnN
IXQTE11smCJRAiHtgZaOZ19JWbfDgXMwlzZJYFcOtuHMbNc5U7KEXglUSE/nx+qzaXQDTGXRz7iQ
LCYxZphmlYystOswa2ao5Ter5Fhit1fMcOAmMYIUYo1GFto64uTBE0YmZTxg8kCn3v1Rd+IIOvte
y2SiDQ0zDLc6CuCsqy1SNn9Lg2zgEMnXGtn8/AO/irz22Duk32BdW1iVpA6JNSY2pwVyYDOxzqDg
3Hr6OcREw3Dnx3WTdIEzrQHvmXgIb3nZym1yE5tBkhEUe2YbIM0G6802CkwHkHWJ39gpdptNuh1r
FY1N4QDNxsjkYcZmoBkPhPSAaUCGZE2GbMBXl6CazsrraImK37SRlh8dV7ocls06WFebJPqWBj+c
wQ/58b/I/tPH0FzTgA/2/a8VCNUZaxt5uDVbrJqgRSSua1VdtYBNrRYc0zt4HSiCYvQJteRCmFru
SBHdDiBIXuuHWzbFY4YCiIGxdilaz8TKkFh6MzRWXntAZOLOXG20h/dT0xkzTlMTE4qr+B8/CSx9
HIceXYT6I++F4glDxOdlcqzl9utPE8aDULrCMLeUxnYgzx3NNHlE+ncpQUMnemjtktG2VWJaSzV1
QH5fNPKHK3/d3wLbd36wXdeEewIjobnHW5r8MpU8va80/YxLg8qUTDboFZAEXL9cxustYby3NSYK
v5S2rQe1pW2tyGgL54G2HT8czNMd0PVJI1yb00dFj/Spp9R5wlBXGp3odR78RaZiegV57KGbPsVt
Lsk4TigUOWv/TJBccgKbFDwibIUOzoNMTpGJWo0atp+QLFqJt3WoCYW6U1Npg0yS0gaTpsYVKPbG
JbKa48izeYSVm+XgEsjJoDMeOD890J5HgXXjB3/ylZP6RjgXtHjD1XM6BbtXWmnlQYFIqNgJRhqT
Ah1G0VtkOGekekRPwbu6+CB2j61iQBBxuuCeKyBS6ter1zUfMNhjL9UdmMbDNFxlj3aETXF9Wcrp
W7IvkzIeOH89QMceX2WoA5Hunjp48CCOvX8CtdXHUFdHTx7HHMpt7wp1O2MyaiX6UKMk3iiQE9A0
hC5XIpIOS1TWZbKv2JO6HDnF9xpie9yyTw82ehAKrdohVK10am7rHXUaLj1F3Xar7WJDrI/ZBbpr
2AKN2jEoHsy9YUGkOWxtWnBPA1y1Hl+44IQlNb6dcZSQPG0E1nEl3k6b2A4vSJ1wtIO/0+mYlvYd
f1471cQhTr0ahSYODrARfi4it3Me3j98Fp07dyZo+w8qy0FJNtEfrBOxJ0tvkucMRPaqTeDA7Lqa
VMinlLskro+5rWGT4uI/zOJUmNsGKF1WNbxU5g+fPIFS9DG7rlCaRzDbMiNa2Kym0F/NR2KRiJJ6
e41Pt/c0S/x97aLiltT4TpE3ruAEyJYGngTiOyw6M2lYXVPFr0FKIfExyMM1i5an+PjP5kmjR/du
iJws9x74mnDTAaOhW6XIwUaPQ4mV2BEqAaGSKQdsIgXirSCZHDT5x8mJbgahNo1DYnEk/VdJ9ojn
Cv1iEUnLbhkDjyhbguQMID9LVXKm0pvgwMWPPkPsFmpQnVsDt1GRDxr5parSM/GmKiTDl4QHnFGW
BE9HI22/NqjJwj5q+bXtET4Ea86cwAfvvRvXS2q2dkJAXFIPUiYcN3x40OmrhIwlngOW+yEeH+O0
vtJJNbC3DYrIpZRSIL2XO2GN5XllUY03963/zj5/QkFpIFC28B9WzhOx1zBLA8O1SVORWxwKb2Kx
GL1/hY+h/ICRlcJy2+SZ7IL0QFuPktNvbMKxNQ+i4UTr3HLbqWd/9JlJn4YdfWOb9CddX9B3ofg7
4dYvQs+Go1NeFxRd9k/WgW8woyUBv2W8rjHNDQ1ooo815RTT5xDt1ExfG2zi724U0Qv9JI4IUs/V
qDENHYbFY9SFWDHRSC1AW5xUdW6GmSzQaVIqc0BmwXwGTOVW02MwTtqjdIodnlba1vgmDhbFGE5+
e0Wm4BSR74/wWpOHzuEjbIWqvpzoOQFpBV0ZkeeeB3jCOFF2DwojWejMr8ZOU3IOL5JXd/qo0oH5
P2qjiYOOMTIgi7+nQccyTx5oqn6fvtfNuxwdJ/lDQe3/24MPVj9J76I/oIxsaozi9G+fRdXv/ojG
Ot8X9ZjZLyCoaQY6CUqKhXtLS/FFG4TZvIKRXBOZdNG1iKQpgbZUnjio6OKTFp08g5jAnKzY5y8b
GNMftsVKX5C9TKPTKWLtj8WnlGrQTNHvgZgu8RNk6mnzwLEnHkR+Dk0YfCDyHapp+qkH62xZLJt1
sK62SNb44ZNS6xfJonupcrsNQnH9+0npT3W5KiklGnFj9VlUb96Kuj370eOu6Wg4dBgnfrgKRZ8c
j6KYo4JDjRaKVNGuc2d6EtXt5R0dzNQOpU+cThdUdniDCGy4oiOb9DPYBCwKzU22muLTZDczjAyd
JuisOZ5dykcmfco4Xbpd9vlRLDeJMHAnAIkUkZqA/AJCxwz5C6jtqqltOCTqj7+H3PycpI/nMF2i
h7lcahPrapNEirOVcsuREf74UgMt/Zw9S58YTSLRnJMEdThSCVCS64Esnz5e0u2zn0HFilU4XlqG
ppOVyB1+Kbre/Clk82f3HHPsAsUQCSO6dndJg7HCRHnCiYNo9F7ThfrKItUHVlVdqwK05IgWezQZ
pjab7PDD2Oe6vwXPokWNwPQ8pj2CVIgEzExLJPK8pbD6c/GnrkvaqcMsPsEIl19ay+omH7VMYsfg
lr1HsaY1jm+R3ZZ5W5/cOlcWIRuZP/M+FEycpagbKw7iTNlsNO4vRxZ9qbTrwqcQuXgEKj47zJKm
DkRtXPOVRxskVyMfW/TuqcrKUzhy9BhO0edW2yvxrWCHDh3C4cOHUVNTo8zIpYmgV69eGDx4sPra
VA7d5VV00yScfnYLqn/5WzR1LcTFC76EvMuGG8z2HwIGklRA7D2JSanwB/DIJBmADgaTPWocxYvq
wdwxmKCJI4YwNMDbD+7g0wRI1E/Sr3pXiAhNKhXNUC/NhV3z9o7XF20ebL3qz+1ayLGsTxjc4JyS
gSiavxKnvjweBXcuVBNG9N1dbswhue0yqvmWKdLMrxPhTYzIoEGD0a/fReBPAQYlGVytcfZRWVmJ
LVu2YN++faioqFBf8OOzOQ5g/CGmQYMGYdy4cRjQvQeqnt+GBtrTKLj+WjRWnkbVH55D7pDB6Dxs
CJ2uGkNSUJMILmHHzrWODpYkPHHEtimKe0R6x1XcEitjJ4740sRX4j6pK2sIqHMHDniFsDmTmAB1
2W7r3ZJ4pjXGravl3CyJb+JZzzQZ38XzUCyumd5Aq2JsLCoGUnCjdYWhI9TE8cDPaBVlLKLvvo3K
B2935FmHhnsUsa62SOrIJFX8tvdsGhOReB9Bb22D+NOu27Ztw8svv4yePXviiiuuUFcV2fQd2tM0
mezduxfbt2/H2fp63Ni7H5of+wkiF/VFz3lzEN3/Lo4//H1k9+iGXl//MrLVg4lsseVIOwTZNasl
0nhrPYRr/CN6n++5KvwWp/z1EQpYcu5VffJKIgCKiGRyK8CTSlKbwLJkxKoJO9llGLO/LLWC89jI
ftL9I75T/vM1SKNlGSKPpXOZYX644DiXAJmOAMg+l5Ssj4TvXMrT6btzqd0p2yqDMWUBcCeMJTRh
0F6uk+yh50zm7lB0SFqjwPdL8R1TEfrl0B648+6peMrCHWzcAv1w9tctDdJgfqz9f9/6X7zyyiv4
0Ic+pD5iPnDgQOTn56u19RraY7nsssvw1ltv4fU//xnFh4/h41dejp63TEH+xz6Kpss/jMYPTtG1
Er1wMY7xYlFzdD+WTLoL24om48nfzEcfh0fCjgNQBbP11Vg/49N46h/LsGGW+21fD6cEPwZqwc5D
k9YK2c//JZipoGv1hB7gRGVYk2KvOERCglzpJ+8ZOkX6wpFg26rqbL/jO6tNDp20zQaIaJEnuUPv
Kwhexp4PnanG8UC4Yz+OgAsNZd/h1JJmRw/QFca3aMLw7zPLwCfhajJvoz0NVtusbt8irVSJ8DpV
Kin2AJRDU6T56xZcBmE9XT1s27pNLUddf/31GDp0qDCqM91c2sPgp9W7d++OAwcOYCdt2I+dPh35
H75M0WUX5KPbndPQTLfe5uTmKli8llRu/wO2MtWZjdi0azZmjChSPKY/MZazYHU6z69ZCZNsSyhT
rGFYUqRxgrsegANkyZlxln1pYlsZQM0xnDfHA9FmhAR+4lP8JipdqEMfR5Gi56USOxkM9/iZ6Vmu
L1n8Anek+ajO76oKNkk00U8vx28SIi4oUl65acmyUQNPGIsorlVpVxi2B/l40lMTPWMn/dOa/cLL
UnyXbU6nCCqrT6tlKnAATza11EjWefToUfCXAwcMGBConvGXDBmC0zTr1ufn0WaMO71mF3ahh/2K
uUWB/BaiFs+vfhr9Zi7GggnAT9a/gih3AP1qyzdgzv0/woZV92HChAn0m4FVLx+yZJLcQ6+vx5yp
BL9hAuYsKcUzRwB6lBC1+5/BjAn34c1KV/WOtfdhTtlLJNeKWdLFnEvZpW67EntHJgxLK48C9T+h
Eb5x6qEP9LrtWyY2tlsXGhDgLUU6t2oFgW3DVZXL1o+rTmL5AWOCJVo/Ptx0+Q533AL7UX5xCTPI
dvdAKv3bYqPlSiNM7lPGE0b16kVoPk0TRhh+NxT6JCWuynHAlPrxYPJZc3MjcmjmOFVdiV0HypFd
XV2Nv/z1r9i5c2diTa1AwctUfLuvfxYVVbX01PdZuqOKg0JUTW7JH+io+DNW7AGm3TgO102+A9i2
Fn+x390VbTiDPW88jRVvXIzSH/wA8yYD6771KMrphb9Rmhg+t3Alzo6Zh8ceX45xtdtwhAwpoAub
vMEfxTC8gZ8+v9829RCeXvMGhoy+VEx3crbdE9QcTOsWlN4g5ezGVjYqSLVqtZo4yAiZQCT3uIQl
WEPaA2bD1TBQfyyUf5IwynObLE03HSReXZma7oFzxV/tZicFcnW1wVccCX66X3nCqHqcXg3y9dUJ
+USudv6si3LK7INgP1jHlYXXjiPiFj6B8j5GVfUZ7Nz7Dg5WHAadrBfiox/5CC4ZeomjrC0KfLYW
of2Ik3SrL2+Gy622um6+/OKN8PJyum/ZpqeLJJ0kVHnX5rVENxmjaSMj79KrMRJH8MsX9mtxpxCl
/3kPxowYgSlfnI+irAqcbmjG7q1PKb5HvzEFwwaPwIyHfoIJ5Mmz6sJsAG6bORQ7f/oc+GKjtnwL
tpHkT3/M3S1h4yQ4cTkocdtakswTLhnqEctDQP/Z1ZYoNvF6dJoINBib40kxAMKyQINQ8ZlMPixH
YFyOk0SaSJaDJA6Lg2Jfy88BZgodygOmUdRmBtJEEeYqIaugi2MSTxhnyuah+L7VyC6g1ySFvcpg
Xb5kjWUr8AuKYZKSGevCk01XGfW0DXCmppbGvnqNSBY60TMRBfkFQuPMNA4gUYEP3IAzuyAjWWfv
3r3VVcarr74KvpPKn3jSePHFF9WtuPza9ry8PD9JiPohPLuSLjOwEdN5+WnKXPA11Rvrn0MF5c2g
GaB5IobzmhM7N6cTLT9ROOGIwpPD5Ku1TfNu6N+P6aw04lO30x7JOlqiimL3pqeBCZ/BiHwrJFl/
bUKu2AAP3EanI/NMHJ6+8Gnk8eOOoVjVPvJYAhfiEcN8KmhTIWTwdiXZJWWbGOiRHkNqAViXoGz6
FHQr05WYMDpF34WV83K0/Gvtllsj4BztCw74/OmKOD+eMLo9tF65sWE/7WEsmYWiecusCYOhcXg9
OG15Sp8Ygg5wL41SH+4PHSD5FHsH9+2H/iW9Qa8RYRX0z3dzMQ+QdCSWYzI2JycHF110EfgjULw8
xROEPzGMn+PgnPc2Cgrcic1PG1Sv2rWFposizCt7BKPygQa6cazh4HOYW7oOW8unY6Ji7IwcHqPS
ZDvoRtk523aiav4YtY/BvVmvv5K+5OOYTfv3v/3V79H96TOY+djHLDNYTjuOeb0pyhDbllY1yavU
mjg8k5flGv4rdoi7XYxdcgj8QmMoCSBSiJb1cVUNahFi8YSR5FJySeRa0Av9Lx/D6YoJiX1p9V2q
OrnnnN5P4SQisX3BFNbSUTCeMUVfeQSdBl8GnjBOLf48ui1+QtUZV/e3V53nMriuJ//hxLrCJlMM
TsxrHTX8WF9BXmeMGHgJXW2c5Y3wLByvOYLXjr3oyEh6cMiB6kjwFkzyeGmKH9zj3zXXXIMiepCP
E19x8DMavNfBE8uYMWMwZMgQDB48WN2O65WcqBbFK79YA4y8E5NGDcPgYcMwbNhgjBh/My1WASt+
/+dgAeSvIR+nKeXMU/jPDTtQFa3Cm+sfxjq6IHKnrjxMmHUrdj71Q1qaugWfGsZXQpajYwWzk1o3
ydWG0sRm0I8Hml1MqJz5Er3SI64Q/6gOOGBjPKEUGySz4e7hbyDQQSSE9anGKkYdqcpmaAyZDeDD
LJZDNsFbuqQYpPVCh/t97q8n65+YsZasgGTp+SohzvJS4dceQv5Vk9SEcfLfb0NkqHU3aBPdlVT9
3HpUPjA7kJ9fGOiRzbraIGXTccVPgneimF1SRN9eaqIrjJK8Phjc+aMtUJ981/ADfCNHjlQP9fFS
Fe9t8N1UvIfBke7qq69Wd1XdcMMNOHLkCLrQu1hy7VtrQxtauxu/3kYrTKXXoZOHqQQ3zR6JjSt/
hb9fP4qmfhtpxwjO+NdlxAyU/dt7mL9iPratcAXkF0acSsmVEzEaT6PmizeihKHMGMcdCdCO3JYW
WE9HTuwixxdSEKBuuMIJgY4IKDsTFfEwmy/FSBJ6/4Rn87U0aPnUd/gqn+D522w66evwDWknA9VJ
WpwrgC43TKM3db+Nk/P/Rd1WW/fiC2g6Q8+bUWp4862EVsuJIRN6h2ycoJNQqplA+r2BTuAbaFQ0
1J6hVR96IpzJ6xvr6cPhPJe0beKnwLt164YdO3bg+PHj4Jcn8qY4z2yX0HMbfCsuP6fRvUd3YwAw
WeuJO3kj8OPNmx0yPYYMm7YMm6dZqM0bHBLaKR+Fn9HGuQSXUVO/gc3/PA9VNVHkFRZaDtPIQS8Z
e4OoF08Ypk0WlqZkupHPXPUBoatIpswy1Fmwyv0DK74k3T/xKeNhxXM2jQrKBDMI9/jHgHe0KBz9
kQDvIOIVSLr2qLxHl4nNkU16rP8mqvMe1hEnDLZJAliYDvC3IQxP2mhkTyNA4PG7J6CJToLVbbU2
TclSKwAdHT8kgEsDq2PBrntW9NPfaktiFv5+eB9yKt6jZzQqUVNfZ8XAvcf3opomjvZIHOB4QzxK
H1PinJenmmkPo3fvXm6Q0B2VwMh4pBw44uF10U6Q4UJOHgqLqOCZ2qvwzJJ7sGwbPbhx3dcxVl1m
sASbUwQwDyuVOpO0QXKXT8K2OE1GqbZKg+PoVv6gP7ZPhSOuFUzrBPe4lDaS5LMevd+YX6/7O4dU
xLGaWF2s6+MwtnQMGuWOFpqih6dkgnlita5vE9N2UApuQpxmNL6zxzE8//bptDxFKx12Krr/YUT3
7EDNU08KKDbXZevlWMo0QZrx3sn38P7JU6itP4ucSCdenmpElCaMLhHaJW6HxPsW/fv3dzT36dNH
TRpFXYusM2buAeu/ouFBH5T0A0KnS9m3KkDZ3FqwsPTnYThdat57dS9cd/1Y+wrEoEmXQUa1aM8g
qOE+uHO14YMnrOoOTEgcZx5kN6iGar2gioQQFykapiME+VZXrXHFWiH94BA5BZtWFGhw1QeEZl7+
CYpJ+Sd1xzhb1HmYcXP1xE33w3Q8TxD6xKBPGEznx+u8yZaTsSNZ2W1FT+E09BPhxXd/x2NWl4m0
9EG/s0/+zAPXK/pJC+tqi3T85HE00lVN167d0CW/C909RVscg0uG4NB7dMbcARK/OkQFPbZFO8Bl
cPsHlnO8x7FdpxE5ccgtlASaQMIIho2j5zcYn3AmEK2Sm4XGx5p5gqBtNXHE6LcnARWJuEGeRABt
ycjqX4bRj/o6htzD66vIQHAmJwawBF2KwGxep09tuFJLZVs3Q8MkvsLQD94wPB2VJmyb2X7/hCFt
suD61CKY9OZ2r6VXaLqlsZEhnXpk3ODkteuy9XLykkJz1NL3lgqLitGNYnNfuuU2OycrB03NDXjh
b88EDorQ0tNNqB//tmwDqEVaQ8mLR8Q4T+fpFb3MZvrrPtOdoOaDp1BNaemEzUtgYowpMb4hAdIO
nvRjEjHoPEKjw2J44gAcFSSAZYk8xcJCmcAhsgXFKvNT2IQxmfhV8hiC8wSgTwE8KQRNGNLcWI8K
Jp152F5Kp87kZHXq3R91UbIzzh1U6cCxDtbVFqkTrQb17V6CQb0uQm5WhC4zaP/7fbr8yMtxn1C0
DPF3kL/OVC7MM6hiDt4Um8biXRVOrOEBahqkGmmMQhGl05hkuIxCSVRcDCIWMsldAT6mIAEehhZX
OJi1JKBJvA9tiN834gdHkAB0ieQL3R1qvOh4y+XMaeL2UjKRTSU6pa4IbUXpGpMxys9PgOd4DtHE
ZOn9IkP1MzElomupHX67kq0P+OoSVNOebB1966KJxlxr/Fg262BdbZG607eMutB2QU1DHd47fhQR
fh6iX4+BGNV3NB3H+pGsl9k0f90Li+E1kbdyC1llokEV14RUBThtdQoBaqzbGeNR+QO+s1QnATFA
chBYlydLKjpM+PTlLJMq4RV6b04t4kZ5gjXVFczOvQwaMgahAMJqxhqgrJsNF0apizRZFlNwBjKh
S64qIf7ofjD5MYSI85aEA7Y3DiTT1BYduckoalXa4n/8JLD0cRx6dBHqj7yXdl08/nL79acJ40Eo
XWnXECuwMz3qkJMdUXe3njp9CpG//7+/0+2k1ajRP/YRy5ccxDoek+NJgdqkxokZJM+Ej6+GOCS4
6IQiSITrOCmrMc+BSwBSkINB6oKPn+tB3Fnuic9CMZsOWlPEN/AlS2sQYYH0Zjm6uc2MoJ/ac5C6
TwrTcxBPkAK4Y7lkQlB2MJfIFluERXAMz6QgD1jesf6GPYMP3VdBShPCXQ3Su1Y/pz5dJVSZJAEH
89YK6HzctnWKNjSCJ4samieidJERuWzEZerV6PE+99rWRqZLnwyvUG52Ah4fJMQhzBJ44gnRcYF8
hEgxRiUT4MV3iXhcUxyDhTUmtz0SA7cAriQvgcgVbql7qRLVgqQH8jlqhJMB/iQ4d1rxU1zIddc7
XDL5r/29EzuJWdc57W/Z+WdBbV0NamlpKrdTZ3VSGjn/mui2yB38LkxKHpynQhRyrMiZqzAF5HJY
KTF+WTqPEOowQ1nOJiRnEr1sYHFAOp1edgh0Wc5Zi2WYope26wzxyspH/kZTXcFZLuP8dU2gsBp8
IyiNOlxR2qVOBFiK2BGOPR5V2Cu5eDI6Ak68Et+W2NAcn56xqfja0PlxFAVTB2PiiMugEnigpqEG
nXPzEW2KorE56n3Aua6uLgF726A5eKUcMGwT9aFrGkoe+c5Vht4+kUC59V9HxpQdebI0YlJKXEqq
UR/hJNjFSO84AE/QFHtV4x0P2MbaTnPaKnVG+2kJJLJs7rRlMbZJx9g2kF6BhNHpaX8Yhg5E4x9f
7IFk2h6mKakuEiXXC2EssWjO5f4ytdLfhyYaE4z3rlNNBflFdLttd9TX1tGrROiVr3/46Y9pnSqK
Q/v347bbbnPk6od1vIGl0znMKRZYT7rkxbOZzfPocQKbGE7cIoBxIQKLI48LwiviJBecpi/VQSAi
/bl+kLBsqadLj8hTevVAr7XJtUkcId6x/aqqAiNqXY4wC40JJzRhc5El9CKTbFY+IrhYKiRBubRf
920QbUeDp2sMJGpXKhNHe0wabeWPRP7y42WM+eFcb4nNVVX6K7pN0s0wvnsqwhvh1RWoa6hFpHc+
3XXbuTt9jS5iBVLtWLZE8BCwD3azTC9UBQ8+BGMEeen0w9Q+YhNx+AQEVsMGgFACKMAEyTPZK/GI
ZSs8/xEBlHPRxMf0LUk80PwDKt7ga4kuD6/TGFPLHKTNQnUFsh0Sx7fsKDXumN4m9+q1ESach1D4
WSDxaDqz7M4KI0JE+n0s8EyeugeCj7DUZYbhbJPjI4whHZzmgxMV6oN5Z2lfgx8/iRTRNyoa6Z7f
Lp3pPbAS8PWjSB3kdqsUnsp6ZPQ32MHpQojIkSMFzpmGclX00fvl+uomapHsI1VVHce8tmablGom
gSZBBHNkqQL9cdrsZVA6kpDr5U69xoGt7Q4IxxtJGGz5LJxrWL6Bkn3OKI96S26gIcSjS9LLgTwZ
RNIeYC8nc7VhnZaeP71x+o1NOLbmQTScaJ1bbjv17I8+M+nTsKNvTLpvUmFopCfCeXkrm95w29xE
X1zN7ZyPavqwRlXlaXPwk4OTtamy5ygNZ4PD4hRsPqmbBwxDHQoyvOlsDbKL6XOIdmqm74c30YsO
c+jts5x0eq4LL5cTJib2meGrGkTYGuwzWANBm4PkTFhy0xVImxuVokLVnzLmOPcnP4i7w9CPfraW
1s9ln+ptt0evAxJ3WgHfO8E6ROdYoW1PoACeME6U3YNCekFT5/z03mckx3Td6aNKB+b/qE0mjk6d
ctWDffwgeA69DT379Okz+OCDSnpwozp2OJgOQtPBy5yKlv5wAPX8HGSsfIHIaJW6nbNISbX/bw8q
Vj9J76I/oEA8WZz+7bOo+t0f0VhvfkOvXyzX/TCR7+S2UhMdo3SbTNK8eBOFo0kVOACl48fCTHKC
4CbaMDBldBr+mPxrEmvR0V8eUwkTU4ehSygokIB9xEnyQMJzAMHesvwba2wQPJbSDDFNOUEyTbRm
qalBJdimxp0c17EnHkR+Dk0YPE7S+CqRZnoKXOSxbNbButoiReh7R51p4siO5NLAjyBSXXUWdfV0
KxU30J+CetlPx3WmNR6vRqBJghEmYhvp4cPqzVtRt2c/esyajoZDh3FixSoUfXI8igImMl1z3Kbo
SL1sW6TL8RppY0Q/Vw38DAqW4ZV4TtVSahR5w+CjuO0O60Ch4wNW+iSu4AySPRDbHbGQZD3lX56S
icHqInfgCDxZ+cnSt9XEUff+IXTPp/f5xfkQU7K2m+hzyYX1x9O//GXS1RCl7y3RMZWb0wmN9LAu
LU91RjQrmwrms3URIsej1NOa80FOQ9f/zVs5m2Pdef9nKLpN/wwqaKI4XlqGppOVyB1+Kbre/Clk
00woSYa7OyxNB4VFHdQmkwyRr3JlL5XswOTIsRl13R4+qsTD+Wk7ft3QGvaJAhtw3Mfi3CQap/yr
5JLMRAKELjNxJOHhWFLuvRS6yhZk6ntXB08U/knFxZ7jJbm6CNmM/Jn3oWDiLEXdSB90O1M2G437
y5FFXyrtuvApRC4egYrPqndpx0o0nejHUrUY0kAP9+XQg325nfLoR3NFp7w8NNfzS+DDy1YHsZ9c
AqkfHqLOt4IdOnQIh997jx5Vr1GzGn8CtlevXhg0eDD4dek59Cv650k4/cctqP7lb9FUVIiLF3wJ
eR8eHldDvGaZhnY8ekeRFrgC6eMddTZ/IK+jyFww2a0ofTp1+T6UWbABauJz9Hv6nLSJQs4dIk2o
4DVQ0sVQk4FtQCja5CxoqzPW5KxKntrUr64Uq/P47rVkuyzZyYDpk9fiWtohSyGdpk8Y3I6ckoEo
mr8Sp748HgV3LlQTRvTdXe5x1U6NVf1DMYvfCMTvoIqcrDiFk6erUHM28YN91WfPYsPT9D1sCuye
ZAcPvjK4/fbbUWhvTHtouCJngRqisrISW7Zswb59+1BRcQLRhij4++F8cBYVFeHiQYMwbtw4DKB7
haue34YG2tMouP5aNNLGfdX/PIfcSwaj87AhFKRio1S8voul9vaNH8+ydJhJtp9GMQghM0vZbr8u
T1wiJCac0FiGEIU9+XjarjGqW1Y1o9RroBwhCQqOHDsMiC5mM/ia2ya2KxJDXzMf3+aq0yWwIjW0
1mZlq257ahLTzuW4lyTH9wdTxqdIxbjEEhNTmPRK7+qTh8B0eoadjxMG7z00h7wCKLjRusLQ/aIm
jgd+RqsoYxF9921UPnh7oDy1z6Ezt1KZP7/Nid/Yy8ZE+DW72fQJv84F+jC2tSsQ/SFiLtbSZPH6
66+roNFEt+mqwcxji5BZtMSVnZ2Fmz/96eBJwxds+NOu/E3wl19+GT1LSnDFR69AcTe6qsjOAU8m
e/fuxfbt23GWNrpv7N0PzY/9BJGL+qLnvDmI7n8Xxx/+PrJ7dEOvr3+ZnjXpbBttZakNeY8IpyKy
JHcQhoLtDgvjZ2AnCkzzRW1VJSpP1SBS2AU9iq07wWJEM681W7goTYYL1EvcMVqdZw3Rr4HNRZ2R
KJQu4RchNk0rTgQ+K8ymmqA8wMU/nHO9gySnTVxIaFZCgpRb5dhhS9A16eVUFMikkArvOc3Djmuh
85wJYwlNGPFeJNtCPWH9nJvbmfZommgfPopoMy1P5dHyVDZdchTwvoAcXM5osgsOPIu+ERvBRy6/
3Hp6XA5K0v6LX6zHX976C4kgHjlAmV0aptGysY1099Nbb72FV155BR/60KUYO2YsBg4ciPz8fHWl
cZauakZcdpmief3Pf0bx4WP4+JWXo+ctU5D/sY+i6fIPo/GDU/SkScRRwXIDU3Q/lky6C9uKJuPn
G+ajj05o2yZnwU7ziUbM18n9ZcVOhDqfotHbrwsSX0QPYe0D92HNG9pXE/t9Cj/64XxcSnNH1Y5V
uHk+8OvnZqGYBeqB0G+EVrf4nsHS32zAhw6uxc1zN6HsN2sxSp+PandhzpS5uKrsN5glCLFLk2Uu
eluqN03oGaYentNlkv0mWuEx5R56GVc2obJC5PtwMbL0vohBtgOgnezR1Xp8m2YX6FcaQaKTHw1B
kjoQPMk9DZPl0QN0hfEtmjAoBsZNIa9o4soIgVRhh1Z/GhvrEK2vQ6Rr9+70aHgDzsiSkxyE/sNb
HaGWBp44uvASlHag8tVBTIozKutJ59atWxGlyeP662/A0Esucc8MSVAxTWK8l9Gd7Dtw4AB2njqF
sdOnI//Dlyk12QX56HbnNPoeLz2nQe97T5Qqt/8B25jozEb8cdds3DlCj6CM8A1h/ehiNCXNBRaA
/nITlVMdiK/A/tT85Jz9Etmudd+mCaMEix9bhrGDi1F9aDsevmsh7vnuh/E/36UHd/g27650+56j
mbQpZSZLXL15F38CC+aNxFB/E5Uc6ZQoeEjmUl+qJP0utkrdFUsl0mtQzScKya71+8WIVR51hoq+
pKF4yF7rhgmRGCCJwAEYg5bWBVl2J9ahtzUxdVgK9lPrLg3pE4bvqApr5DlLxzfztGTZqIEnjEUU
1+iu1kTJf+NQIvpU8Z06RehFhXwANdO1RgOya6prUUf7GbVVvn0Kf3TgkW4zOnmQFXL86njm5WTL
qKclp6NHj6KElqUGDBjgmTAsQusv4y8ZMgSnadatz8+jSyR3es2m5RzeINcDsc7rlmvx/Oqn0W/m
YiyYAKz5xSvUeCvV7vkN5tz3Q2x4/D5MmDCBfjOw6qVDDmvFrmcwb+oETCTc1DlleLPC5qQ2Vryz
UeGY72YNV3XoJSyZM5VkTcSEqV/Eqi3ljjw+YK0UxcG9e4ChH8dHh5Wox/SLB4/BvNKZuHZgLurE
h6cP4rerlli2TSTbXpbb7KLYsaEMM5TNZPeM+7Cp3Hq3TPTkXvxh83acrHXVNqhiLV5afT/ZtAS7
aEwWEGzTL5ZZbbjhBsz53u9R6bKEK8mYMFCrljp4q908F1lB3mJgqHjEIEKBEgUhnrDkn8hQchku
P0FkcjqyZXC1vjPaUlfrtyaEBrnSCJP7xPGEUb16EZpP08EZht8NhT5J6a1yH/KIyY7k0F229LxG
bQ1NGnV0pUGb4Sqgp0OfRAErQrgSOYD4Ej+ezktRQWeqtfTU91m+o4r4ouohvlgZPpGx1Yo/YwXF
52k3jsN1k+8Atq3FXzm+ktBoQxX2/OnX+MGfBqJ0+XLMnwysW/woymkObTi2BdPmLkPWlAVYvrwU
E7ERC6YtxzG25dgLmPalMiAGV4UNcxdjW4/bsfzxx7BwSj5+Xno3XqNorCznP+yH5hx85IZPAXtW
4maaqMpWbcDrO3ajy5gZ+Na/jUchG5fF+zTbsPL1nij9/vcxT9n2CMprm1G76+eYv2Ijrpy3FI8/
VoY7St7A0q+tBzcrWnMQO3e+ig9kZqTpoWteFK/T7XyL172DeY9+BSNoxsgn2iPbXsfHv1KGsoV3
YM/GZfjdLmvisa0lCn/S/M8BmdAaxE9sTehy1cKdqBhsDoIzKFGytCSisvAJ7QknpkNQJdPuZAxm
ucnI1vsoqMeERvJk7DmvaCmQq6sN9coN8nKcXG83TxhVj9OrQb6+Oi6PLk87f9ZFpb1cXX0aDfX8
9o0mdcKXfba2ht6T3kSXH/a0pQIaHXqSxw8J4Qz0Tx7ExWebEVoaOXnypNoMr9HX71g3JX4nFm+E
l5fTfcs2fTYMy2CKOvjPrs1rCTkZo2kjI+/SqzESR/DLF/YTTIZ4EUr/898wZsQITJk9H0WowGkK
uLs3rSaaCfjStOtov+UjmP61e8kbG7GlvBa7/7iKyhbuYsJ9lnAg3Avl9ahnsfyVK3THtXcuwfKy
5Rju/wQ7kfS5Zj5+/aPv4I4b+mPrz3+AhfPupgnkBvxwk3ZlkqXZdhfb9gFO02VDpPtHMW/hcsyd
ciVdqV2ESwb1Awplmc7K3adX9uAHX/08Fm4EFv7kl5gyzFq34mvLyYsfx7RxozBq/HTMLKLVuyjd
fs3JjutWxfw3BIkmiJ1i+Zv5HN6QE4fZgnMbGhSAW7NVYScLOTLYFumrePYKjdvH1sQUVl9rtrlN
ZdMkEeYqIavADQg8YZwpm4fi+1Yju4Bek8ShONTP9XprtjGLXonCWxKRCN3slEMb4dzJzWpnXB8m
ZAIH+lZM/BxG79691fMZr776KsZcdRUKutDpb7MbWHjH/sUXX6RbcSvU7be8aZ98OoRnV9JlBvZg
+gSKmpLWP4eKm+6i/YJ6OigmYjjFUaWZ7iRztwJKCLYZd9+8WXFJF1XV1BFPCcE24x7Gia9IQFVt
Dj7zyNdRvmQp5t/1czX3jpw8Dw+MGmGHTDEgior9hxChJalZ3+Af8VaUY8OjX8OapUsw9uq1+BDZ
BtyobFNcYhtPoD17A289jEmlO0UgQPNGUNq509ps3/t+Jcb376HIeNW0azFfzXCKKm0+Iy2U529y
48Ka/+19B/tkwCMuU+mgHuB+lhFvmRhmAghD00EbnB6zONjb511BArOKuqDbQ+sVumE/31ZLN7os
WmVNGAxNwO/IZV1tkPhkQYU4NSToltuCwiK6k6mRvsxkBw8VE5ILDMF286CzZfkCRk5ODi666CIc
PHhQLU+pW3jVGHUHKsP41lvOeW+jgN7Im2yq2rWFzv+LMK/sEYyk9Rj+7lTDwecwt3QdtpZPx0Rl
V+eY6xe2IlpfQXsOs/HrH09Dbi1zVmD71t3oP6QYJ//k4jrX0XdzHVwExw8OwTfW/l8Un6nA229t
xncXL8O3Bw/Hf00d5pqf9QF+MHs2ar/2BB66cYCCF5YMw4yF38Caqd/EgRO1NGlwIttUj7l+Yeiu
dV/Dso3DsPTJ3+DKPoWofP1h3Ppw0LM2RVi8fi06/XQGFi54EFf/fhlGsBCVDCOU9bFf+Kd0C23q
ub786B9d3palriPDmR4P/H/23gWwqurMF/8lOXmRhABRHiIFDPSKglNtKdoWW2xUZqS3gk5Tp38q
FS0o0oGOUm2uFdpBmdiZZIbi4Ch2KONQ778VpwP9eyn+sYUZRcQ+oEVLQLTISwOEJJDHSXK/b+3z
nb32Onvvc05yTnIS9oKTtdb3Xt967bXWflzwA38P3GhtH/kLKPmbJ5A77grwhHFm+dcwZPm/qjxP
0q2/f5Uu4v35Bcu6eiN00jumOnM61HDAw3l2Dr2IKi8/jyYN2tKITif+pvCAbwYdFi2KJIwJg3l5
a2osPbjHv09/+tNqJcFwfnaDJwo+62CZ06ZNw/jx4zFu3Dh1Oy7TJB7C+O//vR6Y/FXMnDIB4yZM
wIQJ4zBpxq20WQWs+dkbxrWULZkHto9+dpY6c3h2634yOIwDv/ohqqqX430aZyfquJx2HPjlsxau
9T08cf9CzPuH7fgwVIQxkyaCp4RCugPBGcrw+YoS7H7ia9iwcz8a6Kn4BlppbFhZRW3nSlw+0lhV
iS8jQsKtBBh1MYYV0XR1eCdWVdGKp6gV+msnrcNvZihGaVExpt37GG3N7cPif9xOk6dHED2qLXjQ
eHrNi94F7ivfhb7fgLjlJBaCwTkxP/UrKr4G89laKn7wcRR+cqaaME5/80sIlV9BDF3obG5A88vP
o+GRe3z5HbJdrvfS4SuenDro1xmZzULtdNAMeigvwclN3SL7u9/9DidPnlQrADaSn+DmO6H49lkO
jm7jMmEwDT9lOHnyZFx00UXgrSo+22AZfIbB49anPvUpdVfV5+munmPHjqGI3sWSl8CttSw7GloO
4Kd0n+0tK6+nlYAeyvCFeybj50//BG/fMAW0EHHaHCEtmFCJmkXvYEn1YmyutoBzlq3FNH5ootTC
LbZ45S0AAEAASURBVCXcFsF9i3C0Whi38k4sqFqJyshuWMnUe7B25riIVIlC+MwDa7EI38GaFd/A
ei41F7xkKpatfQiTaM5QR9Jkmwri1Ig/J9LhefnGatx96wsKPXVqOfD6C1j4zHRs+DSDBsGepyIr
tIJJeGTlbaisegw//cLfg5/nzKM7IiTk0b6cY62iBnY2SpQLpZkXeIKxPmF4tI8EJWUgGfsrCBeq
B7g5+60Aij5fSW/q/gNOL/1LdVtt6y9fQWcjPW9Gof3N3yTltt7qOvzgNo9N2fRYBZ9pZK1cvKir
nbanzpw9i5oN/2YbrXdshpKFH374IR599FHr6UDaMlq0iA9/6Yp9zRo1cWTTymDFihVqIrDWMgrt
/Yd08ESzd+9eNNOV9ml6FuOll15SsubOnYtPfOITtPjp4QDlrd2BUVr4j9HnVTbcgmbansopKEaB
c/ahPSwLF2JcbsRW8hXf0dzSRBNyqAAFMUyWaksn/SUZDc00XGfnobRYW2GYZddbCeO62tFEOkR3
C63SIDaavKpgEfscJdcyIl/ndYMJiyqnZJKLxRLD3ckJSYra2pe1itN7WpMyMSDu9x747afHYESe
OUjYxcr5H+XopItgdVttBDxy+zsqdXzGeJswgdQJejv5n/3XnxKgtEj4Qp+ffeMxlX+vvfZaDK+M
t7ydfO211yr8+Ms+at1qS4sL7j+hpsYm8DulzlDsDNyxpGtzMkutCPh9ULyFxFtHPMBzyI2sANgg
3nZSQR94LIj11+q10TRrGE4vJgzTQ3x8MM6y2WBOS9ALIrD0xGyNNaBYfyNaaOBXzzK6KM1iXInm
J6bhSkEujd/ejYfJlIdVLRRQZUYmC87bZjCZHdinuv/o3fbqPV8RXxdQ3SipDuMZFAEYZtqCIym3
OhOYsiueAKdEv3ozTXRypjJnTRYi0SoON/7ELPArg8hMJuaWIfXb0+0psU3062Xywwm90PjxMa2O
F95Mi1NRFjcZSZeTmxX9TFmS73z7kBLJ7aDwy19BzmWToypKvr0K4YN7cf7Hz0VhvonEmrCviESQ
Obk5NN7TE+G0RcVtIdTWSu9KpxmkmN4a6whskDFGDKZJ4e676VUc9L4oXiGow2si+7Nh9OFxmixu
vPFGDBkyxCHGkXEpJE8+o/nhvkgnHjFihDKMJyd5UZZDRjozZIOLiUqjH9xwU9RCbijxOpxyM5dd
BmeJ2RLNnhgdUR7TMhmUDLgSILAYaVGbfRNRnREqslVeveLL14fIqDvJBq4L6byJ1E06zFYtTKqh
BwqkHLoIKZM3zm5mOp+k3fgE119i8YFpr173Ji6V+S46Z1BPhEe6WLT/u3S50oV/q1QLTdGNlQD9
zj33bwmZxLp6I4TbuVA5qv/wuUbolrvn0/CUhWNHj1otyhwYNKu43BPUYfIEDUpJ6ZnEKw6INkBd
nnKc5j0HzoKXyqTDOA4iWyWJhnUoROr+aBb1SKiUnYWo8ksZJK9JF9qonzQcl1HKHbVNK7eDJ+of
9kqUOsqvxLI8h9MiGeH1kq3bJLQ6jNME17TG1r8iiT95mmLTlWe/O/wXUWTCpH5MO7zoTLjw6XLc
aARv4gQucrxioTP5mT4WZ7QRD6HC54Hud2Auj+kfM68Xyg0nPhGclae2rzd+FsIu1vuanmYU98VI
OPaZcSqlw1i+3qME59TL3c5JJzLTEXd1dtACIUzFosLSIxHZYTrP2E9nCmG6W0mFGC9oZkRw4heJ
oxRckMiPBz4pcBRvJhLQZbLYLjcxyee5vqN1zraw7cmLiXJI2TnmsoutnDeDGyxK40KvbFMmxspS
fKIsKkRLsD2cZbnqp+EicLE9oXoz2PWsb7l0wj5ISxlV3Wid183mnsD0ookciXWcpN1wbjChl9ju
X3abiMdnll1k6THL0H86LlPTti8sC+P5IV45THlu9NyVzJA34lK0hqm3edxBlUWDrvyYRq1KIrQM
N/lMmPCyjtDFl5jq05JXD37T1lQ2HYizX7P/m75l8Vs6EPntnjdcFZrOcxubTBolKNLwTKGutBEi
xpl4Pa+nTbk9yrtUfjLy3OySTqfLYTo3WqGJwfPApg1u2hSnWByyjBbswEUUKJiSRwVmeofsCFGk
3kx+My82c8w4E6/n9bTO1xtpN9163eiDC9O60Zt2xqOz8CaXlffj9cKJvaatlkQe4G3Z7lp7DtVt
0O3ouWQ3CVwg+bnh/WHJ2Cc+51iCnhaYVyz8gr/0gRVoppuE+JMT/P2JeD/WyjQSc5rfhME/nVfP
s2zWwbp6I9Bz4HzrFNUIxfQ3VDFrFvjlgXyy7hYi7dENpWCCF0ervLRig0toDHCvZcXWWIXemFha
d4hetniNVqcVaW6w6GggREYcT4+aFIy6UF2DGqYC859Ig/WTFWMbC4m4LAZn2JgJWd1Gv3KKrTq9
wPTYlGHmLVrNSTpzJO2mw5Rj5pmVYcKr4wXmoiphkClDl5+wkJQTSt9ULTdp6WaZkhYQh8H0Uenn
bkZX9TN4/+8fRdux92PqSrdHeBmmp0WlFyxv1GiM/psVYF29E6xbbmkKVONF6Bc//znq3noLTc3N
1jcyyAoxNiGDIoMSVy0X3h6UrMrWu46i8REaD+/DGoPykiVNT1mn/jhZBc9QLxk6h+4raRB6I9Bp
JS08Qi9wM1ZyNKDyZcTfDDb5Ra6w6L4XmB1HCi8TB9UdB1OGTW+nuJZlI4/pTTtsyr5PSXnERuXT
qA9dGgCZbPKYpRBZOlx4bJi7bMELvS5LTwudVyz8jNf5OK3jvPjd4MKnyxM6C2aVKeo+QaY0dvOb
3iu9lfWk7N5SbYz4x4ZYKfGX4HkwHzJjpkKaOMkzUuhNu4VGx+v0SjD9ETrJpysWO3jvjNOhqddd
i3xaehTSAbSNtNX7DzyW4cInsc2dQIoHK2mFFLs1GZHC8hN1lFszc4OJbBXLwMkZZQjvP0YmQgeh
ndErPF754+FtqVYqhj5in9DF4AWRQJyM3W7idH7G+9nCuETrzU1XKmDu9lHdquYnrS6xrR5TlnvZ
uLWJXLsEJq+NsXyo+9Vdrs5hpXWZOo8Oj+XyhnjzWT3IaIbegnqMidtje6zBTQCXn/2o14W3TywJ
8fCix4tO18W0Jp2ZV/LITtWARXia4rxc+qKP2pmiDSq62zW7ZHAprr3hBlw8cqRSqTc6BsQ2exfL
POrWlOVG5gaLGOKiKEF7XDi5HPrPItFLZ1miIFGwp3UODWY5BSlwiQXOsRtM8K64SE91xcWRJ3LN
uLuyzKldb9BeMk3dvZX3sscNzn3QL7jxuMHcZLjRCUxi5hNf6jBTntCYcMm78brBhF5iNxo3mNBn
epys7Tp9PB/rZU+GVufjtK5TcLo8E895gcVpriKux3HJ4KH0mil6eDm/GMWF9Cze2n/4B+TRazyO
0IsDb7vtthgFYlhiw2cMe1wAy3eTHXUcOymOFC8ZwqbKoI8ISiD9MWZqBkt5hVfieDYIXRAn7gGu
Y+kAiXMFlJnhAekpZs8QOFup4xiu5/1KkQytn5wAJx7gd/l1N7S3tqKdnsvjvtraQp97vWzsR9Dc
0IiO4SORny+vybbFR5uANsBy1UfhNmlSKb35xMhSAPojV9eaZJ1Wl8EkOs7KRSj0CSMiix2g0+uy
FDxSXoZrRY9wu0fMp8txp0ocmoi8qK0sNoEJNnHtA4UyES8OlLL2ZjkCv/amt1Ohq4le1cQXatEL
8gSFnm89T9/TyEUOLS54gAsNGTIUHfS97tBZ+8V1uiwZBHlvX4IaqCSjxTaFPoDbjYvxwmtDrYFW
4EocEfL6wgHT9KhRnGUZg6QuXzHrBun8kbSDXserSYawMnHEkSOsCZIJedw4njy1TSRO0uonruAL
iiCeFy8oZ6SwsOnwqz4qpNDUQFTUA9YwkdzNEl1ZRE/n3kNLh9J79AbRy19p1XLxyFH0QErYc5yV
cYk1J9pUbDorxTKkSYg8ybvJFRrGxYTIAGnriKGwAGrwd8f5yheWOAOxLiOuLSLTJRY5ycpQG3fJ
MrnoTx/IOli+sLaguDalUvR0+rw8cCSL3wZOiTKrJFZ/TNamYYPL6L2DecihieN8cxNCjU1nUTKk
1PoIEy9djIGSq1GqkruA3g04rQeh02F62onXJdlUSmbkCp+hTh6bjlOmBNMemzuC4bL5TCRR6You
mvNMsG2xOj3JPRFSRl2WwDyZMhThWPpSIS6sCYMrRa85PZ2hFZYSs9SaVyv5hVLulDivV4WobflE
xkDNqraOdnpjCL1rkF7EnUPvKQzlZNObWKmOc83zjIjg6EAWnUwYYjWKZJtGVJYyiLltWWKjgpIu
N9lOfrHC4hScSHVCRbp77KaLDXCFayJEJ4NiS6IRJpiMpy9BMX1KFm0myoqBUKI+dWc/Ue7eX/uJ
8ReQmd3rj610pkFf61NfEM2mc41Qayt9jyEvV91/q7znOQulYlg06sdDZLyiueHdYE5t7hRuUIbp
E4JTjp1z0BEDbf2p4CbT5hroqQu79AO9doPyXXge6KDPvSK7i1YZIXVvUqiFbqFqpYPw4sHyiTjN
KZHLRn0YoJsknafv2qpADbT6pKPhzG0htW0h8il2bGtoJuhJ3Q4dbqaZTm2z6baYRD55sSU6cWjl
EFyUPVIGWZkwj9DI1kyMXyLMgo/K0hIiQ0B+tELjFZuydDpLrnOvU9dl8uo4XU6mpXW7U2WzyEyV
vFT4TGwSWbptfjih704sckWX5FmWwLojN+DJTA/wOjInix7qo62pDtqmCvH3LBrpcCOvQLvdVo3O
7ktONSDrZeOBWQZ/gkcHWqbRcDqLnuZ3Xr399tvqc678LY3Ro0fr6NSlE5xx9A4QVR4phx+Oy+oo
e5SZEsyfRHDTw7B0dEhLbmLGyfyYGHVAlW4P+LUTP1y67EpH+0yXrYHc5DxA8wW9Hr3DmjRK6ONL
jc2NaGg4q0lxnzA0gpQlj9J3PPgLgPyMyJVXXonbb789RjY3RrdOwITSUL3wSpjHaOc3j/jJNXEx
E2lMCSyAKgdNLYl619TDZRSYh4q4YOH385fo8aMRRV408fQInuW4ydDxoqunsZ8eE8f6TZip3w0v
drviWIBHWzRlJ5MXnW48gnOzR+jdcMLHNG54NzjT6XwiP4j7twd4wmjvaLPqltpv6FxLi/ra3jvv
vhstmd9g6tWAoswuCT+eVnrakB86OXXqlPo2uAu7Lyihhprklb6vQhckryOks/iVVXCyJhGeqMhw
E04cP4OsQYPVt3zzI4/O8DiT5iJETUhVIl69CF58kiq9XnK89ajac2FjuHfwkiflcuP00uRGGw+m
69fTMW0qniAPvF85hIV16boFHsQDywNt7W3IoVexc/vl+s7+8MN69QEm/mIeN4JEG51O59dw/HDs
Wl5hSONrpjft8idkTTtMGbpulqF3b5MXTXuxoKICFcZvwapNqGdmI+j8pl6D1M66jOh7nySdNW8q
mnDDfmx6fjvqwzaLnsrK6sC+F/8ON/75bHxl3jx8pfI2zJpZgZrN+6Nke9fNRsWTlrwoMCbRhCep
nDVvNsRgBMBl0stl+dLvMkE448e679yoLbwbxpp0LVvc8amCmjaaVSd4HS4w3Qax1Q1n0gmtDk82
LfWm152bjHh4Z29xSjDLIjqFysQLXOJUlFNkBXHmeKCLXkHCX++T+g3lFRXhWH093vnTkaSsjNc4
WUE8GlY4aNAgRcf0fKaRcND3hPQebgrIIUKSPX1JDRZNHYrz7WGc/MPL+F71Gnx/8tV4fNY4kyPG
bnFWDKEAXMbcS6ZXoarLOp9pf/+/8IN/2Yzy//k5DKPVg+4XTh/evBJL1+zALWTjXRWTUIQG7Pn/
nsa3axcj/5LnsejjF5GmYpSAHuN3BPPatQAzqpYhPLbIQeWV8SuXbqPN71JQG5lgSq+4BFkSJBOb
/colophG6AXmFhOZb0hEhq+AbiBNnVJeE+4uOk6B3JmiA4YHOgAPYA+08B224Vzk0l22XfSt8Oyd
b7yJ/3rj13i77lDcYvs1Sj+cn+ChQ4eiuLgYoVAI06dPT6gjszz9XEA6jZse7iLN9Bt/+SSU0acY
L710HK656SuYQzeLHTnRaLE01WHdw3PVauTGGxdiw05rAu1qP4DHv74cW7c/j7mRlcqCms00pEeC
4luAz1d8nnhnY8WGnWiJoBrf3YVddY1oqduEv/rGj6lcTVg6ay421TUJt4pZR03Nr3Dlff+MJbdM
wWDakwoVlGHa7CVYRvmzR0876DnTVLcd3/7qnMjqaS5qNtHnetV6qwUHd23Hu6ctK+q2Phm1e/aC
Vdh1pEV1/q6u83jtx49jdqRMS57cGi2T6UtnXl/TxZjVx4DkbEu0vXpdj+j8Th+l3w2sr7d16uVN
fwkHmobk2mamlT6L3oueE8pBB7W7DlpxZP9gTS2GDrkIHxkzVg3YeuPgtJ6XwkijTabhutGy7NLS
UhrIL1V6hg8fHrVB9v1Zpxuv2GLGbjYPIqKdW1/Crl07sXPndmyo+WusbxyF+2+fQpgGbLh3ITYe
uQYrV69G1R3DsH75PGw+3IIsmmEPH9qJJx7bglnLa1BTdQcObqnFf77VTHaewjrm212IJdU1WLno
euxYvxx//by1pdR4giaNY2fpO75XY/6cycrMWffPxyeHFzpNbjiOdwly3ZRL6a91FWiVtwA3f7MW
D39hYpRewcN1eOTex/DWlV/F6meexvJ7JuDnTz6KvTwzUjixazf+1EKfi3x/CxZWb8I1y6rxzNqV
mHZyG6rmPQeesuo2rUDV07swp4rKtPwevPtCNZZt2Kv4E/nj5mOLz7299ExmItxMY19Bu7VZkeJt
u1DExt3hiZViQ0SebaflN++81Qe4/t36gsizNdgpN5zAbH0WvcCF29Rn4oUuiON5wG6b8SgzEV9S
NBh5+QUoyCtAXl4+QtwQyoYOU/f0+BlsNjCh5YbVHZzw85nGtGnTUFdXh1dffRUj6bseeXl5fluv
wuqI/ezgYXrfC7WoekFnKcEHRxvQ8sFLWH8MuGf1V/FnY+hjIx9ZgDmbd+P5lw9g1lcs+orltaj8
dBllJuLOf9qIxnAHrSC2YSPx3ff045g1rgC4ZgpWN72Fbzy9HQ2Vk4i2mH709GTpONx84zWofeE8
Zn5hBi6lB/A5SOdvOvo2GjEKE0eSjIRCCb64aBkm/vlNGJ1zHkcaLyeug7Gc6vykC2dPn6OJayqW
/Ou/4pajQAFNkr/80W6U31mN2deNJ76J+O49/z+++cwO1M+dgmGxkjSIf+PXr8qlfBqza9Kv3lwZ
kgSKHV56BO8Ua90F5NWunbTO7UYTl868W5mkPH64dNoUyB54HigpHqxejY6sTmSHshGa/7WFGDni
EuTkxN4uJw2Q3aCnTbfoOD1t8nnhJk2ahClTpmDPnj0oLy/Hxz72MbIncutQRJnJa8qWDi50kme6
8/S7o+ZFzJ/CAzmFcD2ef6AStd/+CT75XZqgKDy9uBJPq5T1p1xd1dHWFsUXDWYaHjDDaI1c7bW3
tZJPrsSUS+3Bfvx1N6Br/Y9R13gvcolOQks7+68Z7efpSjFiguCKx19NU8ZG/PqdJpp3bCSXo25z
DX7S/Fk8VHmN7f/QCFxa+h4euuXzoDkrEsoR0vQxb87Ym1Gz6I/4zprluFMVbBTuqHoUky89hddp
V+7g+mW4db3wW/Hhxi4MIxPEh4KNl/eiY7jJa8KknoRO8iLTjnmJb/vUhtspkWFDnClvvNn2LT3e
9O7l0rWZvHpeT1s8vIJwcBt5HedMx8qy8V64VMFZk5cs24og1d89UETn3tw8Ozvb0UkNNZQTKsBZ
+p5GFt+M20ehsLAQM2bMwLFjx/Dyyy/TAyQdYNiZM2cwatQo9cBfQUGB54pGN9tt0DnHBJErfEUb
KsMVH6XUu/QCLjpTAR0xL3/+/8VnisIIE93x372Bk8M+QvD3FDn4VcCuYR+O0wHHBF6EUPjw0Fv0
93qMpoH3pIIYf3QbBFU8HBMovXnbb2hS+4xAKT6C52q3oO6OCg0GWuFswMKVG3HH8mfwlc+MQ0F4
L+bOrHbQcCZM216FU+/Bpm1L0VR/GP/9Yi2qV67A1S/+AJ+k85xL7v1XPHrTSLTQiiRcfwC7/xDG
FfacFSMv3QC3erN1urXN+JOIzZ9IStfhGMEjzKnWl4hNAU3ggb73QMGgfLU1xa+cammj91DxiTgv
OTroTYZ9GcaMGYObb75ZmbB161Zs3rw5+uP86dOxB8K6vXzFI1c9fNWm5/lMo+53v8fhw3VqG2z/
rk34AW9VTbsMpZd+DNNpg2j5D/4TJ2gAbT7yBh5ethw/+iNdjvuE4onTiQ9Y/u11qKtvwIn9W/Fw
9Q6U3PIpxNwDFm4jyia8e+CIGqSdYi/FnUvIgi3L8TAdpJ9oaEJTw2E8v2IxdhBh5c281WWH8HmW
BYwYSSN/wxFsWvkdteL48IwcwVu0Le/9DAvn3YoNuw7TFtlIfPSysYTgE41STL6+BDuqv4+dh+kg
pOU4tjy+GCuf/YPFmORf8bP4Pkl2Rz2Z9eYtSwZ4jvWfN0fiGHPCEPmmBC+4SZf5efF75luaCRZy
vV9YobWtBW3hdvDzGu1092noIrrSzqczhIazdMnchyGb3tV+1VVXqbuo+GyDzzjOnTuHAwcO4NCh
Q7j88ssxbJj/jjub7zZ48ZnG7qer6GcXsLxiEZ57YIZagPzNM1U4evdKfGXHGkUwinCP3HQpDaiN
4Aknj+4ckECfygW9IZhWLuPwLeI7TXwLKzcqdMnUO7F28TSV1hcVxeM/hYpRG1G7dB5O6NtkihIY
N6sKNe3fp9tul+Mr6yNAlOOe6tWYFTkEEXnFk27GHZNJ1kLaXiPSUZOn0vbWbqykQ+6p2yrBG2ls
X/GUr6Jqzh+xsupuiEi+pfcqsj+0eDXuPLkYy+++zVJWMhUr136Rzjv6LrjVm2WNdFIZzPnQmDCc
jcSCcR6E2dDESiX0os/kErzAzbzAUxlbt4OwJmVVxDQe5C0HpEpXb5QlVbb2rRyryVl/+9aS3tN+
/Pj7tPNDAwe9kbWTmkrW7XP+qiufXnd7nLaGfvHKS2mwJDkH8+Dx3nvvYd++fbQyOIzjx4/j/Pnz
WLRoEcaPH+9hX3I63IWE6cl0ulqn7briAhmi3SlNaAs90R7uBp8pB+EWNNADjmHaIystow+4xxDY
AIdOepK8KexhN8lsoj2oAr6t2WZXqXBLk1r58C3PmRv0uuU0NVqKrIHTSovtArMHVIvewsvAqMOE
04r1g3zBpH6AFsnJxJFyE4uUQk8lIymg7ZkH1DYqVQLta/RMUB9w83v++G5VLgP/XnvttRgrZJuY
x+Frr71W4cdN/Kh6wy3fdsv40PmWNpz84AO8++47MQJSA3B3Ll9DWRgnno0aO3YsLrroInxAdvEq
gycNfp6Dhgj6OektG91giVrPDiSpXbn0vEiuh3x/WTwgpyTQxFNamtj1vkNnqBjF5owgBvFk5mFe
qID4hC5jY6nb2MGe68096AjhZ0odznnBWW2AIZkbemuYYh+JXzLXG31lmfeKuK8sSr9e/uSD+rQ2
bU11ddGk0dTUTIPzh/R6dGuvPP0mWBridQE+secf34Ibpk/R8sF4ahszT1uWxAuxIfRWPXdPjwzu
MnhJ3l5Z6BOGvcKwtAkutl5FHtPxRBGRS2CWIVmxue9XGdJCxaJ0xnLxpPsonfoC2f3FA9wPeFsq
Lz9f3dUaqqcD5pbWdrqNiq+yMy/wXVPpCfGmrfRoTUxqbw4WiVnUO1RSbn3gslcB5uTAF8Q6Jduo
Bv4o3Low4KsDm1c4qP4lqQrHuiNB8TuQgulxHLGI7I4vn8vCV3axpeyJGVLOWP1Of/RER8A7kDzQ
SR9hyg3RK0ToLlJ6NSB9uY/ecstXZB3tlAtChnggtkNniGFpNEMGM4ltVTyY8QAasxKwSayNpwir
7j2VjgKiCY3TSpqyYwhSBYjYyJOHuRKKrnxIF+MsPDPwz9v25EzzkuMFT056QM21xVvvA8efXV30
HY1OurW0PUTTRgdCLfRq8i6aSQZSIYOGm+keiIycSXYs80rYbaC3aKTDih72h8Bs31id285HU2qM
TuVAHZWsTQSmPbqtNr2b3To2SGeeBwbaWKr6FM0RYZo8eEoMqfUG9b6sbPu20syrhsCige0BfcDk
wZSHcxWpMZMh5oTBaAlOnDkYm3mLS67qdc0ij2NrQopgSYS7FHeoLsc97c7H5VB6Y9BiZQzCXXwA
DTyQQg/wipfWGcjmb2rQywtD+fmFqkPQZ8KDEHigFzwgA2BkapAsjYf2FRqnCBEdIzkhhLaJ9mQR
JbSRit4d7rZC0Rhjk6Q6VjuTWVBzmylWgBtEl8h2WrZaZaJJUzPSLqebnL6Aie1u/u0LewKd6fQA
v9KJL+O4TfIvlEtvLeRGyR8MD0LggeQ8wINHMgOHDDYRLXpWiXKT5yffC6cLtkukD8Q2tOcplus/
cXiVS+x0w7vZJfSC8yq/4NMV95XedJUnkOvngWx6PiObL5BolcFzRUi9c4ry/ER2EAIPJOeBZAYP
54DnzFla+eLaultIt8KmlJSlNZ5uwfPVkS6v99J8dcb/ObjfBcU2msbZ9lorDCmHEpNhf9j2TLYv
w9zVX81RDTEbfPLNIRSm5zM6u+iQg14SyN/rDkLggdR5QAZEt8GRhsvogGppNIcgM2/blchAZQ++
Nl/6Us6Vhq3bGvitsmb+JNBd/3jXVHclBnyp9QC/BLa7oZ3OLnLo4WG+CMrmM41nn/0ntLXRU+H0
iHn6nolwmuvsYE5c7+Qio1VwlZRmd+uDifjcqdJaXThhnJMJhdMy8Dqvau2BmWkk2LRRiEr0eGvK
fd5TJllnMe72sPKBO1mIj/tZTI3LvTVmTjnS0Waa6HVH3Ql2n7K85vXyie7I7kc8iVyp9qPiZKyp
4me9i9owfWLQJw9FTWRCaRVPz1ny7MbMOGvQtuXY9D2eMNgAVmmp4ZwdCJ5FD+AxKh0d3VYUpFLh
Abst2O0jFXJTLcOyM95ZWaq1usvj1QV3gE66e4q91s8mDWuwkKJJzr7rhoqmj0RCyHGkw/f9Kkc3
6kJMS61Zg6xUl0wAZp49ZE8EKueyCmGZ1ArU09NMk+JAbSfaxjJ7rElxwQequP5QiZEBKwOqgNs+
P9zXRfdK8Rl46LbbbkcX9coOehnVl770pbSZ6DmY8xUiaY2tRoG4Y9lQoeBZMCbYSAvlQhLDEwDS
4AFxPFeIvYUjkwTHMlGIcsFxXse5tSGFJxlKekSVzW8B7LxTntIX4bV0sxQO9vZFdLKwEMHfwAMX
nAd4paGux3L4woy+3Bf9jobes3rNLdYgYqmWDmsq1+GS5sFA0k56sxiq+xO5vw6njCCXag/YdWXW
D9ejBbMnFKWd6swa8q26c5swmE5fObIcfZJxLQWbEhXM2jnY9qks22Qlgr8DyQNxG0cmFpYba9+2
Rn51SHZWLrJo0uA33oay6cGNEP1yc61vZfeu22TASFZr4k5UlPafZBUF9D32gF9dueP0vh07ydgG
6ROGBWV5ZicTmE3h7IPuNjC110RlSRo4f2P9OHDKppdErhV0WKanuS/49YHesL+TXnGblcVPg1sr
8FCI3l44jL5V0dJyvjf0u+rgRpu+Duo9KLgaEwDT5AFzMI9VozoHkZmdW59EhCuxgU7qXmLmjm+H
6AjiwAOBB+i16PTeKX5Ko5MnDToTD7XTt18/+KCevv3q/MZ0bzmLb/V9++231bczRowYgdGjR/eW
6kBPr3pAH7h1xfoUQTSRO5F0CutKi/mtLaz4V15+E4OXHbrGIB14IPCAeKCrgw7CaV8qm378ep8Q
PRKuDsKthYeQ9V589OhRvPTSS8inD3xcccUVuP3223tPeaApzR4wJoTIGsJcOeiTQqxB+iDP25ne
E4KsVlm++51UuqxYTQHkQvBAf2oDbKveh/qmfrrojik2I4vfGkJxCNn0n3pZiN5B1ReBn0Lnh05O
nTqVxi0qq2QtDfX4sPE8CkuGoKw08z902hf1kUqd1uAdK1FWCubk4aT06txucGsFovPrsu1JSacI
0oEHAg8k4gGeH/gnITsrh15FRb8QPyfeB4FXGHKm0dzcrB4gSbkZ4SPY8PBszLqtEvPmzUPlbbei
ouJh7DwSf0tu77rZqHjyTWWSnnazce+TFaiosWh1vDpAIqe7x834tzk34qvP7nPiW/fhqzfeiGf3
nXXCPeV4yU8Ofur1Wtw459/Q7KaHbFp441fx62Z3mXqZ+ZLEHt7tlE7Dg7lMIBac6eSnU/ql2RY/
PONEPxPGJY4nLMAHHrigPCDjVhctNHihH+IOl83LD/TN9zQGDRqkBkWeOPhMI/WhARsWzcP6g1NR
tXoJrptYhnD9AWyqXYzl8x7C6s21mOT7RdlilEA+haunYy29ZHoVqtCNMxmPRc+gWBVpgxx+cyd+
/fudWLN+GzDqTrrJzg7hhsPYsWMXtq57GgdRHvWGTeGRkrHadaCOIom5uwO5y4RBYlmyTCSxB+a6
Xg+7A3DggcADtgf4gXD65WTRHEEdKzs3FEIufR+cb73tizCU7twqLi6mw5UQpk+friaQVNrRtPcn
NGEAy557HDMmjUAB6SkeMQlzH12NW8qBg0f4fSxh7N1Ug7kVtFLg39yHsbUu+fe0NL67C7vqGpX5
dZtWYUnNBtQsEZkr8GZ9cq+fP6c5ounITqxYQKsetm/2AqzbXhfF1u/fjCWzLT2zF9RE9bANKzZs
xoYVc6lM69AQ5YhNnDrwOxxuHIypJRZObw3h0+9g176jGHPjdIWM/+kVmQR4gDYHaS9YrE1+EDm/
kNVKNPZjirHFlzhABh4IPMAeoC+B0ztt1S4Qv9yWXpWeR1tTucjLlavp3vXT4MGD1R1TPAgMHz48
5ZPGO6+/ApTcgWnmIqZgEpY+VYtZE4rRsn8jlq7ZgmuWVOOZtTW4o2w3qh98HslOG40naNI4dlY5
sL3pHezbsh7vTqnC6tUrUdG0A9/70R4P5+oDKx/22j9r0G3CpsXL8auhlVj99D/j27cUYOPKBdhF
s0D4xHZULq4FZi1Tem7EFjz4pX/CCRog25sOYcf6Wqw/OgH33HUdihyDpqXTuhLvwjWV92Lpfffi
rsrL0NUoA7tlR8G4z+Fb31qC++77S4xCM5VBt8+tSMIvOMlbOgXa/VgmJZagy7bkM9aaRFKlr/uW
BpyBB/q7Bzo7O6z3TvFnwelHD/fRcoPONLJ5w6oPAp9pTJs2DQcPHsSrr76KkSNHIi8vdQ8ahpSo
PN/Nt9Cwj2FJ1Scwc8YkoKUel40dBdT72RBG/eHDOEkLh1zQdXdoGMaN41mJ95kik28brROmLsP3
589ALk2IuV8ux7Yf70PD0mkojfGzDIJug5yFa2Oe800IZw3F9fNWYNS0Y7ikCDjws2cJUYH7K6dj
JKW+8uAi/HTBD/DKgXtxFeW7uv4C//7UNzHCMWEQIrIlZF2x23rb2W4tkOkqqLgluZWSJiZFSfGT
Ls6CiZ1RjCoS4+yyRXFBIvBAv/JAKtqxW99J1AnEyxeydKet9UR4Fm1P0ZZNR1jfxU5UWGro+Fbb
KVOmYM+ePSgvL8fVV18N/sRgagKdDDR+qK6PHUcHdDi+7pE1GDG/CrPGDQd+8zhmrtxnq6R5wzu0
4MWlC7HR2okisjvw023zHeQ8vJZMGBV9I6Q1GPtPXg4BxFkUredi3P7EMhxY/ndYMn+j2q+ffMtS
PDKFJjkMo/r8BRZ88ReKXQbPxvOtCNMEUDKnwjlhcOU7FTn4BMU0fLXOQWRy2rqC51TvB7aD9Ys9
EpuW6HZL2qQJ8heaB6Kdqf8VnE1367QJl6RnZbcOwiP9jtYWdNMUvUKE7pzqCPfdVWRhYSFmzJgB
fmbj5ZdfVkshhp05cwajRo1S21f8rQ/Zx07YV0Q4/robgPVPY/PeuzB/in2NHz68Gxt378aiBSHs
3/gAardMQPVzL+KaEcVo2LUKt61S1/Yeqooxf9PLsKYJn9p0+aaVGnQdjaADXbQPdvSDBtUueCZX
ofk46ig9lRi6uhpxsn08HtqwDaVN9Xjrty/jseW1+N64yzG/tR5Z5ffgp//yZeS3tNNUcwpv/PKP
GD2+FGd2c0WzMmk0JNChO6KLopjBVexgXERCDI3N3iupRPRbNJbx7s9q9IqpgZIM84DXBUaGmelq
jkeXdaV1B2qd2Z3AF5pFg1KWOgS3xoLsfHo+g7eDcvvoTEOsHTNmDGbOnKkGua1bt2Lz5s3RH+dP
nz4tpEnFBRNm4s5yYOPS+7HpzcNoamlBfd12PLBwDcm5BdePK6ArckqOuhjDikK07bQTq6q20U5T
q1qdWKOsPvCK+u5VBDdeJY1j9SvF1XPKkbVtOWo30/ZVawua6vfjyW+vJEWT8amJNNGF/4Qn7l+I
eTXbcSq3CGMmTcSlhC3MDWHi574AHHoGz27dT5cAHTjwqx+iqno53ncsHNnW7tmrSkusiQzYijbp
P+yNRINVDrbFzR59wkhUYkAXeGBgeyCZ/uXuCTVy0GCVRdtT1jN9eblqwgh3xL8nxl1kaqD8jfKr
rrpK3UXFZxt1dXU4d+4cDhw4gEOHDuHyyy/HsGHDuqGsFHP/8RlgxSNYs+xu8FTBoWTyHKx+5Oso
o3TR5+eifGM17r71BYWbOpVmmd0vYOG66XhMDbbWYBX7JItyp+LhPzpeTzMuN4+2yRz7Ywy1wpS5
1VjWuArVtUuxuYYf1KeQNRnLVq/AFep24En47so7sbBqJSp/bjWCkqn3YO3McXQ32DjULHoHS6sX
Y0u1JW/OsrWYRnPNW5Qtzmcb9YZj2cwQp/UWb24eecTDTosiVX+9LEhEvmV57ErCLJGZT0R2QBN4
YKB4QPq9xN0rVxadd/NkoXYt6EGNrKs/Pq2LVxqnTn+It//w++5JTYBL31qKvXfeFsC49957D/v2
7cNhOmw+fvw4zp8/j0WLFmH8+PE2YTdS4ZYGNDSHaWIqQmmp+XBGmJ5Mb0GooJgGYjoP508jRtLd
UOVg8Su7ozpbmvBhcysN8SGUlpWqSYiHPaHpoluDWwlPRtKneY1pKUwrFDqoDuUXIV9DRXWH67Hr
V2/gHL3imK/IGc6+bm8fhI/fMA1lGo/D+DiZqHyi86tXS58tjFdZ3V8Z2B6xJaY+pZct9dIzR6Jf
vWWOlT2zxKrL/noR0Z0v+EkfEb91qU96l5aWqr7P/njttdcEGY2lzXObuPbaaxV89EfK+TZbStNN
Uzw68Z1THLro9bdJB7vnJ83qxcBGjx07FhdddBG9SPEDtcrgSYOf5+hpCBWUosycK6JC6fkNel5E
QoGWFlg6YofXaZIqo59bsOhCyKctND1EO3xOPr300e1VMMTJ/7vacebkaZymCwS+L4ybVBfa6Pvw
Q3Gej7OcYnUVKUlbdtoNufsTBpvj8FpK7AuEBB4YWB5IXR8ppAtR3prqpK/38SdfQ3y5x/86Oxyb
4An5zxp4EiJNmqioqEi9+ZZvwQ3TIT0fjA/kwPMvD+UyCcjwKrGFjXhABxogs6lYgzNJDo3AzZWV
itqkiYhIQ6Qbylp1zYzjnw5LgwmByMADgQd65IGiohLanclVEwZ/4TXEg1S4vY3OD/ihreSCDHDJ
cSVHzXdNXQjBvPLmoVSGXBlWJVZ3WAky4hyd3s1fwuuGSxfMmghpWpCZy6EonRYFk5HD1UEm8EAP
PMAX7SWDBqPsomEoLCikSYPeMtR09ixa2/xuMfXWyNtJ7oOCxiOjhwYKku4eYFfpY6zb0KpPEMbc
4So00SFUZLnpdBUcBxi3XcTh7z46VSXovgUBZ+CBgeIBfiKcHgwArzLas1qtnexzLW1qz6o7hYwO
DOZopwmTwUgDBUkvDyQw3ulzsD6BqDQ5W590WI3QJCA62CzyqpcAHnjgAvVAHj2WwQfgZ5ub0HGW
ngXL42+D08uoQrl8Ot69oFYb3WMNuEwP0IwQnWS10Z9hMvjbG1cupwJEJLS6aHPCUDoihIKTWOeT
tM81gZAEceCBwAMD0AMd9HXXllZ6vVAbrTbo7DuUUzAIRUOGof2c3ztQ/T3Bqw1r4jCHKzPvL+dC
xrL/VOCRO5J0Dv88mVhI8bfFYMFlwJfYwiX3V9S6ydDmr+SE9gl10O76xO0Zq1RadsYamIBhfdem
Ozrb0cb3SdEzGvw8XfaocRNR8Rez0E7fge1JsLapLBk8AFo/GvZkMOyJ8AHOq9YW7DqpAompnXBT
UU1e/WESfvgvkmG/6EjOJxiUCvojqphNTycoJg4ZGye/OKQpRFtNTvNRCmUHovqfBwbCENSnZaCn
MrKzc2gsp++EZ9Nv0hWX4/TZBrpf/3zc1iCTQWSkiksfECTqAb/h2mXQdRkPbSoXpIcZflo9WJIA
63akV5PTKL4xwwlJPCde1G1PnDugDDwwED3Q3k4rDbrDln8t9HnuUNmwMuz77a+RT++e4u91ewWe
MFRfTKBHxltdRA/PvZT1CM4dvtujRo80ezHr/jDLbq0a2F6xWxuwtCTLVttSMauMiFYpMvGYOiIU
CUViRULEROReNsPwDKuP7pQtUZ7+SNeT9tKX5VVjUlLjkXSSvrS6O7qt/tSTeuKziO6GNpoXOto7
6KlweiN6Ln0a/MNTp5Cf1Yn8QYXgb1ukI+gDC8vvSeHtwdXLUhmwMqeB6OU3yy5bTbztxMGyXsoQ
BUTmQaZxwTEjhwg6VkeE3aJK6V/vsomdUg+SF/UCl3zmxXrZMs+61FlktpfUSU6fJK6bRO226jHz
25u/txIvr5ecJn41UjdCW1s7cujhjByaJ7q6Qsg+fboewwbT+5botqqeBXNQsKSlvuPFq3zGx6Pp
WUlTx235TCYMV7laUWJKFgNwldDH3uAymm1DK5S7yQE08ICnB5KZMDyFBIiEPUDvC1G0nbSq44Vd
KKezDTkFeTSwmB07YZkRwmAgSNZj7HHTa1ZeaoMopFoixJJlOkk7hJgCI3Qu4GTNTYI+YlnEZpux
d62w9QapgeOBnl9xDxxf9E5JsuiOKXrNLT2aQdNHF21TlRUV0mu78xx706k0JdElZCp19hdZ1goj
diCVyYDx7D/5cbkULDJLODgjTA5YxBFusER8JHYkQis0vN3Gd3qouz0cih0ZIQ/iwANJeiBoR0k6
rMfkXXxnLZ2J8CqDT0ay8+lDPl20+uD7by+s0J0hMf0e0q2SNMde23zRLkQJKx2F9NjYbkmKGM0N
LAiBB1LvAekVqZccSPTwAN1qS49o8OWg2t3I5lUG3zXFj4qnKngNcKmS33M5mdvwZKzlWNLWZbte
ai/7oxw6ca+mebKInTD63i5vJ3j50psjwPSlBzK5LfWlX9Kom/s0H2twx6ZXo2eXDqZvSZ9uoA8d
taRUazITR+9vYXHDy9zG52WZ7VObgoc8laOE2hLyqkVfpBdTT+G2nT2VFPAHHgg80Dce6FRnGZZu
fsgv9Morv8R//ddraG3xfkYjnaaePHkSb7/9tvp2xogRIzB69Oh0qiPZ0WE2zXp6RzwPy6pEccZn
fsomDonaAuv5BG5qMfO945fEtWS6fYmXJKAMPJAWD0S6CH+9T00aO3e+SoNOJ863xn8iPBmDEh18
jh49ipdeekk9I3LFFVfg9ttvT0ZNN2gzeZBwn9Di+dIqEf11Z1c+SrjUPjISc3aPBSSmJiVU/cnW
lBT4ghNir877c12z7byT0Ed3juXwzS00S9DWVCfdbRuaNGkSeODu6M7nXj2aIA9yUlnxBjw+T+GH
Tk7RQ4bC4yG2x+CWhnp82HgehSVDUFbq/lnVxJWkoxH6DO1Wu9F21VxoXUDR8vjhIkTx6ioqyzeR
gCJf/gAZeCBdHpBOlC75A1NuNk0Y7LmODnWwgex75n8Nt/7PWfj4x69JS4njTQT8FLpMMs3NzWo2
S7kh4SPY8PBszLqtEvPmzUPlbbeiouJh7DwS/xxn77rZqHjyTWWSnrZGb3al3RD3PlmBihqLNvEy
NGHD7ArMXbc3Iisis2Uv5lZUYN3eBppMLS22psSlJ0tZv6sGFbM3wPHsaPgENq1aQD6j8tHv4XXb
0f13IidrUbro2Zv6BBfxe7rUBXIDD/RTD1hTBo1B6i23dKYR7qCPhdMDG62t3ftyn5sf4k0UOs+g
QYPUCoMnDj7TSH1owIZF87D+4FRUrV6C6yaWIVx/AJtqF2P5vIewenMtJvl+UbYEJaBvjqjJoZjS
uZqJ+qADXDK9ClXoxplMdNHjlDcooolvWkh3OPzmTvz69zuxZv02YNSd6n5s0bnrXxZizbaxWFaz
Fpe1v4Unlq3EsuIxeKpygpD0w9h0qpnvh0UKTA48kAYPZGXRJ5jol51Db7rlV6NTGu+/fxR7fp3s
FXJi1sXb8hg6dCiKi4vpw+UhTJ8+PeVbVE17f0ITBrDsuccxY9IIFJCe4hGTMPfR1bilHDh4hK+p
w9i7qUZd2aur6bkPY2udXGvzYCI//zI3vrsLu+oaFVHdplVYUrMBNUusq/OKuSvwZn3YX4CBpc+e
REPTkZ1YsYBWPXy1P3sB1m2vi+Lq92/GElqtMG72gpqoHrZhxYbN2LBiLirmrvNdHZw68DscbhyM
qSWWWPuTXE3Y94tG3FK9AjdNmYAJ18zEZ4jmZP3ZqP4gEXgg8MDA9QB/7pUXFl38NDhdPGcXFw3C
8RMnUF9/MmWl5olCfizUb+IYPHiwumOKVyfDhw9P+aTxzuuvACV3YJq5iCmYhKVP1WLWhGK07N+I
pWu24Jol1XhmbQ3uKNuN6gefd27RJOCdxhM0aRyzBtP2pnewb8t6vDulCqtXr0RF0w5870d7fKT4
bT41YdPi5dgx7MtY/cxaVM0qxMaVC7GL9ojCJ7ajcnEtMGuZ0nMjtmBZ5WqcIE1sw471tVh/dALu
uetTKPLRfk3lfVh6332Y/2WaSWW+VPTFmL9pG5ZeU4oT+3dh05OPYD3Ni1+e8VEfaYzK1O0escvP
33GKFqADD1xwHqALZzr35rE8dPCPf8Qbb7yBwnzfPZq0uYjPNKZNm4aDBw/i1VdfxciRI+lBQ94O
Sk0IKVF5sK+cY+WGhn0MS6o+gZkzJgEt9bhs7Cig3s+GMOoPH8ZJWjjkop3e4DUM48bxrMT7TJHt
qzZaJ0xdhu/Pn4FcmhBzaTDe9uN9aFjySZTGmkAQ/+0RtXl4vonWREMx/c4VWP3Jo7iEZoEDP3uW
eCtwf+X1GEmprzy4CC8sXINX6u7FVUrPLXjuqaUw50yFcvnTzna7hhbs/t8/wJodxxS2vv4MxdF9
NYPDGpCp2NTIDFSfZ9mgYMLo82oIDOg3HuiiySKL3j2VlWO9gyr00kv/R925lF/QN5MGe45vtZ0y
ZQr27NmD8vJyXH311cih/bPUBDoZaPwQzSTMMcTR4fi6R9ZgxPwqzBo3HPjN45i5cp+tkuYN79CC
F5cuxEZrJ4rI7sBPt813kPNGVMmEUQhFoNZg7D95OQQQp5xpsOW3P7EMdSuqsfTujYps8i1L8MgU
muRQRr9tWHjrNgd70/lWhGkCKJlTkfCE4RCgZVpawiig9jHr0Q2YhRbsfPIeLF/+M1Ruuw8XaXR2
0popMm/CEAszbiYTw4I48EDGeYCf8FI9hneQ6Lbb0B/eegtDhpTSba88rPZNKCwsxIwZM9Stvy+/
/LK6g4phZ86cwahRo9T2FQ9ayRywS0nGX3cDsP5pbN57F+ZPsa/xw4d3Y+Pu3Vi0IIT9Gx9A7ZYJ
qH7uRVwzohgNu1bhtlV+NwZYWzbOaUI0anFCz0vSK8BoO+jYB8b9SM3HQUcx+KQS14QP2i/DQxu2
obSpHvt/sw2PLa/F98Zdjvlt9UD5PfjpU5XIp8E9hHrs+dUBjB5fitOva7Z0N9n0Ju64dRnmrN2M
uRP4wqIAn5hxE/DCTpykm88uKuyu4IAv8EDggf7mAXWucaahCeda6CMb2XJN3DfFGDNmDGbOnKkm
hq1bt2Lz5s3RH+dPnz7dLcMKJszEneXAxqX3Y9Obh9HU0oL6uu14gLZwgFtw/bgCuiKn5KiLMayI
htzDO7Gqiq7ai1vV6qRbSn2YeOJz/obg6tsmIOvlFTRx7cNZem6l+dRb+Oeqx4huCj790SHI6jiC
73/jXnyt9hWcyi3GR674KMaQnEF5ufjo576ArEPP4Ie/eAtZuR2o2/Gv+F9PrMDRTlNPN/Ml43DT
4Cz8aM1P8O7ZZpx9/9eo/saPkDXhz3FZ4UDb5hlo5fFpiAEq8ECCHuBtZvU6W75rin4h/lB4Hj3x
18mYPgz8lt2rrrpK3UXFZxt1dXU4d+4cDhw4gEOHDuHyyy/HsGHDumFhKeb+4zPAikewZtnd4KmC
Q8nkOVj9yNfV5k7R5+eifGM17r71BYWbOpVmmd0vYOG66XhMQaw/8aZVHa+nmTs3jzabHPtjtuAp
c6uxrHEVqmuXYgudaVthMpatXhG5HXgSvrvyTiysWonKLRa2ZOo9WDtzHN0NNg41i97B0urF2FJt
4eYsW4tptKjaT9niJN9DmZtH210OO8tw1+rl+NPi5bj7tvWWglEVqH7sC7TmGGgh2LYaaDUalKfn
Hsii902pt6DTmQZdeiLr4ovK+EgcrfRJvzMNxhZJz/VFJehbS353UzHuvffew759+3CYDpuPHz9O
L1M8j0WLFmH8+PFRed1JhFsa0NBMWzihIpSWmkNemLboWhAqoK8Y0ojfwp9GjKS7o0vn0cuuw2PS
LU2ob+Y9rRBKy0qj5yE2XZjsoj2hUAGdMRjTUriFVlFUNi+bw/XYtWMPzslBfURoe/sgfPyGaSgz
xNk67RT7JEy6i03dERK/erWl9J9UwvXWf4rkaulAqze9kAOtDntSV/yev9LS0uhOx2uvvaa7SqXF
X6zn2muvVbARl4ylnSh6RoNXGvQ/xA/18cl4pgQ2euzYsbjooovwwQcfqFUGTxr8PEdPQ6igFGXm
XBEVSs9v0PMiEgq0tMC6Gydc0flFGEY/FfjQKUZhDvKLLHyMzJx8eukjLyvUNUAMJ7roouDEKZym
O9Ps+8La0NY2FOfauzAsJ5bFhLBupYFsG7iB+8JALt/ArbmgZOnxAB9+d6oPalC/oDeJhIroOY1c
euBNzSLp0dktqUU0QPGPb8ENh8Pgg/H0hAtkkAiNwE2VlelxYb+Uql8omZPEBdIm+mW9BUb3tgfo
G0zqMkqdYFA61NTcqA7BO2g2ycTAd02lP8gAYg4e6dfcuxqsckrlu61l4tszEAZUqW8u7UCv8/g1
GlD0tQekDertsq9tsvWzdfpmVCjc3kEPjPEj4mK4TXxhpLjcUlkDYUD0r7Xo/Q5UVD7UsqrdrHs/
P5i0/voyD6uXjdN6kHx/L6NepiCd+R6QdpehltKMoS4wuVvwSwt54KC9KeuXoTan3ywZJCQWjRle
mWJmdNKLArSElEFiDUVJaxLRcZwWP+hw5jPzDOvPQcopZeC8CRNcEAceuEA9QFeWquerW26zELpo
+MUK0N7OzzBfyMFtsHCDZaKP4tlpD/ayoIyuOGKKw7KYnmNdri0jhqVfAfQyuRku5eQbCuLRuvEH
sEzyAFehd1vPJEvj29JXrZHPwPn5DP6uBqdD//7vG+kOmjbw7Vhyu1V88zOJgkvUV+7MJD942cK+
MX1kbUt5d6YLzZ/sHw5cbvGX6TNFEPzpdx6Q+ux3hjsMVj2yjy5i+FXo1h22tC9Fp+IJ3J3vsD3I
9EsPqCanWW7lu9RtdBo4btKUE5ehHxDIhKGbyuV0g+s0ZtqcZMy8Tu+H0+mCdCo8EKwYe+ZFdfZJ
ItTJBnWNATJpXCidUMrJsYTuDOQih3gVuy5P5Jpxd/SYMjIxz+UYzwl6AABAAElEQVQSf5j2ecFN
Os4n459kaN10BbDAA73ngc6uTtCLQ2i71honQn+3Yjma6XUdrbRF9cUvfrH3LEmZJhnwLpSOmGh5
zQFP+MTxifjLlCG8mRanwk5TBuUdoET8pfvFwawjgnTggV73QEcHvRi1m6GTHsege6bU2RAfYYSu
mHQ5jh07gebmc+r11/13KcedlEOyndvi6j9/kxuM3M6prK1R3U/Jycw8X3Wn7uOXmX3HXlKUyl26
z9gLXjLc7PGizTxvBhZ1xwOZX79N/GqkbgR1hy3fZxs5BA2NGTuOXo0+FH/60xFef3RDZG+y+FWM
2C4dlu0SWG/amG5dyZXJrFKud6vurcNwy9rkZKa7hMnLT4/94jvnQ5B6+2JLzXwEFGNSDCD5YgYc
GeyBgVu/6gNMmufp09wh+lJevnqRlRpNpKdoROlJcmdLztE82MU3LzmZ6SlbOqTK4JRs+Zz0lv9M
WcnXRTpK2HsypfzxNDp955wgTJzIItnRRqrr8aIXviAOPJCZHlAH4fzGEP4wHrXtELdv3pLK4pMO
ClYzp79Ge3debfW0cLrwRGXF8sipPpUgUSH9lC627D0riPgr1XJ7ZlXvcUv5vTSKX3Q6gXnxWHDn
Kk7n9+cLsIEHMtYD/BmNLJow6LOvHLI76SUifNBBB+R2MPsH5WU/yybqSaonnUmMY6PYLrGN4fwb
aKE3ytST+sh0f/fEf5E2Zc0ECRS0J7oSEB+QBB7oAw/wtzRUy6aYB9zszvZOdHR2oCPc3svmmANV
pIN6WmHS8xO79k6ANXkws8iR2E2gcoEbIsNhpg96am6q5fXUnnTxd6O+dZaomzgRzbgay20yCIEH
BpoHoqMpJbJb6POnOfTEX0dk6dEXhbXu2JLepvfWeNZYnZj5pbPK5CGx++qD+aJuiKekD/G6L8Q/
fWjOhaTa4W6rndnFd2s/Vl1xu7OCQ4AAgzjwQL/zQGcHb0PZ4yW95bYdefT68Zwc7Tk/HoHt1h8t
JLOluivw60vefvtt9e2MESNGYPToS6P64id0i3ji4NvCnFyctx5KSbXlTj1BLlM94FXvetsxbWce
P7zQu8uWCxihCuLAA/3ZA3x8kZMjfYJWGu1tYbp7Kg+FxfQN60hgtHX1zgMx5bReYIzJwkJdzAsT
JXFNHD16FC+99BI2b94M/ja437Rkz2Wsy5ognGctEXsNTeZEYqFVKQ3KTMqKP9Npp+jIpHL3li3s
154Ek9+qJ+equSfyA97AAxniARpAO9Q8YB18h44eO4ZBRYXOlUbEVjWk6COuddkeUxIZuLPoSp+G
7Ri8H6C1tZW+zd2EU6dO0SrBfxBzou2VBfNZndXSZKUtWcLDNOfPfIgPG8+jsGQIykrtT7v62Zca
HNuSnF+Sp0/WUjdfd8fOZPX2F/pk66u/lCuwM/BAch7gt9vyvy6OaYjILrtoGBobGnD8/fejktyG
Exvpi42SJZrIz89XAz4P6s3NzepOrvi80qHdVxYWP9NY+K72I9jw8Gx84fYvY968eai87VZUVDyM
nUda4qrau242Kp58U9HpaTfGvU9WoKLGotXx7Gjv0IQNsyswd91eJ0nLXsytqMC6vQ1OeEpypkGc
518X6nfVoGL2BjieHW2pw6q5czF39mzM5h/Z9fCm/SmxJLVCzHKlVnogLfDABesB6lo8eXAIXUzf
4G6n90797vd/cFytM1INzbQsibcCYFoVSKaakbTtLEF5xYMGDVLyeXXAZxp+gcWy3WKPpcZv4mBp
Ddiw6E6sPzgVVauX4rqJwxCuP4BNtYuxfN5DWL35HzGpQCYhN+3FKEFuBKGnY2kvmV6FKoyOQeir
oBgkAzwWPfaGoStXgkCu6NjysR+lmjh9+M2deHPfDqxZvw0YdSd9y9EO4Q/fwrZjwKLlj2Bsbjva
6Rxs0LgxNkHGpLicUl6OJcSWXzBWTLSKLR6dkyszclLezLAmsGLgeSAnh76lQbfb8tkw95BQ27nz
OH/+PC6++GLP0sqgJ4O1mhhcBiIRIHQmn+SFjuOhQ4eiuLgYZ8+exfTp06MTgk7jlGcPBvbAJ7DY
Tt+09yc0YQDLnnscM2ROGnEF5j76A3z412tx8EgjJk0owN5Nq1G9ZgtobKRBcyqWPVqFmyZ4jOa6
cZE029j03ut4vf0juOGqkajbtAqr37kEY99djy37WOZ0VNdW4Zoy7YYDFzk66JyWaTqyE3//vb/H
joONQEk57vjGg5g/Y4KiqN+/Gd/7di32KdQteOSxxUoP2/Bc02Rcduh5rK/7HH66YT5KFYe9tScq
Th34Hd5tKsUnB2fhdQLSozzRumh+v4503oQbPnMVcprCVF+JfbfdWW+iKd0xtwFpD6wrtk3IxCL2
RS3iBsUcMptGERmWIDv1Ekp5xW4pl+STtb6n/MnoE13Mo9urw0WejheYxELvRyO0frHIYRqWpecF
Jvw6LlV63eSkUo/YnkysvtsXmTC4O2Vn0WtE+LbbUHaO0RBjxUYL5GyxsYQRiF5YL6LBgwfTHVOj
VeUMHz7cqKRYRWZ/Zh3c1yP9PUbNO6+/QgPeHZgmE4aioJIXXI6lT9ViFk0MLfs3YilNGNcsqcYz
a2twR9luVD/4vHOLJkayDZByNp7YhdeOnlWI9qZ38Puf/wjvTqnC6tUrUdG0A9/70R6bKalUEzYt
Xo4dw76M1c+sRdWsQmxcuRC7aOcqfGI7KhfXArOWKT03YguWVa7GCZLPNuxYX4v1Ryfgnrs+hSKH
Tudgek3lfVh6332Y/+VyZDU7/X70j28BjetxW8VM3HrrLNq+WoE36zP8S4/OIjhK7j6R2CRSnzYk
s1J60fRazHS73bwYHVPckAQTvF5Ok7Qvyt2bOqM+MAc/0xFpyvMlCr9FxLKDXiPy8euuUxm+i0mN
vC6za9QWMVriKMJOSAHZqSaZ6Wim5TONadOuxaFDh/Daa69h1KhR6m4uMVDnkTQ3IL3j2NpjU6E8
huWpK+dYrAUJDfsYllR9AjNnTAJa6nHZ2FFAvWL0YAmj/vBhnKRxMxftyMotw7hxI6i8PCyHLOe2
nUPXJx7E9+fPUB8tybtjAl7+8e9x9pvXqqt93U9cLvmxQsZJXuI2Rpxvouf3h+L6ed/FqGlHcUlx
Fur+84dEeyPur7weo0jO/7PsfmxauAa/PHgfrlJyZ+HfnloCx5zJsrQgtjConex2hhYc2n8Sgz/5
ddQ89EUMPf0GvjP/USz7/kv4P6u+EPNBFpHFdkvgtNUW/Lq+UKcoTkKV2Myadbvd8kJr0jEt40y4
0DOeW63mFgVx41EI+uPkFagdC171B1MwkXnb4m4HS9Z5OC06bK3pS4k+3QbRxq3Jq5xCw7EpQ+wX
mWZe5xWcDks2LXp0Pl2uiddxzOOHZxzTmzTM5ydHxzGv/nPjZZgZurJ41mBoJ0LhcBh1Bw7QHVTW
dajd1U02ykvD5NgaBWKIpEC6oTFEBuDKK6/AlClTsGfPHpSXl+Pqq6+mu7lyYhzBbJZc0u9qqAD1
EYPK1ViPZuJ1bDaFj2DdI2swYv7/wqxxw4HfPI6ZK3kfKRJo3vAOLXhx6UJspO0gDllZf4Wfbpvv
qIx28k/JhFFqUGWfWIOxPXkxzMtHlg9DsM80ivGX3/8W6pb/HZbevVHpmXzLEjwyhSY5lNFvGxbe
+gsFZ3s4NJ1vRZgmgJI5FRjpo4tppc44zcFpVwFmPb4JsywUUPoZrFh5C26r2oPj4S/gUmO3za9c
IiL9sRpeuCQJqdLLr5ddh4sgv/LFo+duk0zw08VydH263fF0uNkRT1c8mRcKvnt+4op3H+wTkudW
YYbDdTmc1oOOE3gy7aWLXzNFMlUpKA7t+OUraDh9Btm5ubjzzju5JYpcFbNw0whGRGGEd6MRvG6c
pAVHUpS6wsJCzJgxA+/THVzbtm1Td1Ax7PTp02rlcemll6pvfdiGxe7J2+ODc6AYf90MYP3T2Lz3
Lsyfwjv6Fj58eDc27t6NRQtysH/jA6jdMgHVz72Ia0YUo2HXKty2Sl3b2yodqWLM37QN8zWY02uW
f7JanVAuv/KBw8d05Ey3Kh37oCE6WCv/NB9HHdFPpR8TfNB+GR7a8DKGNNdj/2+2YeXyWnx37P/A
3W31QPk9eOGpSuS3hGmSqseeXx3AJeMG4wwfTvgEtsWuC5vQAQufwIZHajHk69/BF8YXKqIObkBZ
dK4RmTBi69WaeESO4G0NvZFytgNLI9eHDXcrv5vNYr/gTOtNvJlnep1X16vDmU7Hcd4tuNGIHNHN
fKrp6IMV15smUGiF1+Kx24TgNZa0JN3KI7b4KdTtkzLoMD9eXb7wShyPLx5ebBB53N2turA4Tbwu
zw+n03HajVZ0mjiBiwzOC43AvGL+cl8WvTWEWoZqP9k3//lf4Nbbb8e1tE3lFkxlMTRqALEMYCMS
NYTlsDMl8MQwc+ZM1bm2bt2qHvbjB/74x3meQJzB0sWVofQqpD0gCG3BhJm4szwLG5fSts2bh9FE
5zf1ddvxAG3hALfg+nEFdEVOyVEXY1gRDbmHd2JVFd1BVNyqViciJ14sZU+k/EJrySzFx+aUo+sX
j6Jm8140kH1N9fvx5LdXki+m4NMfHUIHF3/CE4sX4mu121EfKsKYSRPB9y4NysvFxM/SGuDg03h2
634axMM48Ksfoqp6Od6nuSgZWzxpQwVo3f86ah/5Z+yvb0DD4V34ftUWYPo0jIznlIzBc0PTGptm
l9SFZ/ldaDWQq4+5z+j9Rk8zr5nX5XFaH2BMnOQTs9vZH3QPJKJDdPVmHM83YouzvvSSCUX8mHUl
qk+XJjxOG2yKROVKHdqcHilnNXoQOcGJ2JAIDUvtpMZivW2D/EyTR2jLz/5DXeE3NTXjS1/6ktIs
TlEZbl366G7mFZHVEcSJHDtkRGjMSBfF21FXXXUV+PsefLZRV1ennts4QFtn77zzDi6//HJ1p5Up
g7qYAlnNhiYvleeceLoUc//xaWDFd7Bm2d1YE4GXTJ6D1Y98XW3uFH1+Lso3VuPuW19QsqZOLQd2
v4CF66bjMU2hsRNj6dV8I3guv6SFPTePNpsi+2PiG/HXlLnVWHb2cbq7aim20Jm2hZ+MB/9pOS7P
5xJdjhV/+1UsrPpbVG6xSloy9R78881jkR8ai3+47xCW/t392FJt4eYsW4tptKiiaQTF+WKBMxYb
GCp2cJybR9tdjn28Uty5diWOPFCFxZU/V0KKJ9+BZ75lndU4pWZSTtqA5RPLMmkT4uMIlBsiBS6/
7hcLa/8VnPjLxjhTbnjhZUoTr+OckmJzOq3I4ViHx3JZEC6leIObbaTYXuQDFq77KlHfJeKMZOUK
vdRjIjoSpfGS6QZnO9zgUV3UUGh4Rjbdessh62f/8R9dv9+3T932ev83vhGlkwQLk8IJLJlY5xfD
RJ7VaG35gn/vvfewj2ziyeL48ePq7q5FixZh/PjxPoXjqwbpCPbgoNsabqEr5WbawqGr9dJS87bR
MD2ZTneRFRSjgEb8Fv40YiSty3BLS3nccHr5TbyOU2VvaUJ9cyuVIxelZaUxE09XVzvZ1UIH74W0
XeeclrraW9DcSmWL2Cy+FNu62j/Erh17cC76zIk1cLa3D8LHb5gG807gGNvI+NbWZjqIL0BRPuu2
682tXAwT3ZwWezjdO0GGR/e2wDbo9pk26eX3w+nl8pJn0VjtM0YW26EBTVpdvpB56WE80wteeCUf
i2cfiFS7jkx6myK9KS+9Ancrm1gkNJzX6QQvsYkz80LHsYnzy+s4TnPojk0mr5W3246fHjdesYFx
/J6/IUOGRO3atWuXspP/uPFee+21Cj9qzDjk5tJ5LH1Tgy9hQ6UkZBptTR2j14kIsyhSgB78EUMS
FSF6x44di7KyMlxxxRXqriq+JZif5/APvITypwgVlKLMnCuiLCE1cUq2gJ4dSTRwOcV2nUfK74YX
nE7Pk1QZ/ThofVnlLfoQkRS76kIoH8W5ZuF0KWE0nDyN0/SeMfu+sDZ6UG8YzvPds9oc5GobkRRE
bPPzsxevKkSv/uHGwOXnn3vD4HLog6aYJ2Xg2KxXwQmtHvvTiz06B6W9jDDI9KybHsb72abzS1ov
uzevt/9ETn+Ldf+Z9ZtoWdz8JXK9ZApe1+EmR8dbaY+2E0vogHjZwUQ6Lp4N2fwBJupHnV30CQ0+
37jps5/t4qfCG5sa8eJ/bnYodcvoynS8KE51E+MJg+/w4oNx3sIKQuABdw+kuuW5awmggQf6qwd4
pVFaWqomDB7H+RjADDK+83guK40xHylHdojvZrUmm9Cloy/hSQTFI0f4XJM5ZyZTEedFGUvm7suB
58eehgJ6bXsQ+tIDqazNVJdDbGO5qWhtqbYvkBd4oP97gB4GV92LzsBpbKdbbstoe6qlrQVtHWoa
4TVuz0rpXPP2TFbA3ccekEG5h22iR6WItNgYGZlgW4xRASDwwIDzAH9Pg14+hSweBmiLKjsUykZB
fiEiX4GNrhL0kkv31GGJpLvLl4jsgKa3PNCXEwaX0Uu/asG95YRAT+CBC9YDatKg0vOWFT3mR98I
55UFzR7RBQIleLDXf5a3vDqvjy+jQn1oAlQGe6AbdZ7BpQlMCzwQeKA7HojcvUX7U1m0vMjOoeci
+ESc33QbDTzYq18U4n3Bp5EEycAD6fVAsHZNr38D6YEHXDxAZxk0RUTmAJo2ckO5ND9ko62tNZZa
u9C0khogljqABB5IsweC9pdmBwfiAw/EeKCLzrs7wh20IUXbU3S+EWoPtyPcwe+coKs43qrSt5T4
wo77KcGy1DYWp2Nk2gCTP0JuiXAyyi26NnPmpKJ3gkVM0m31w0kJhMaPj2l1vPBKLDIkz661KkMg
icemLJ2TbTDxul1+OF1OJqRjbWWrlON8yyi2C79f+ZVEqzKEzRGLDAGms95Yh67Py24dLnYFceCB
RD3A757i+aGznZcbdPdUe1sYufT+8FBuDlroe916I1RCudXLRKKnTY2Ec5sceCJyg2dqQ44pf6Sc
bK8fjslMvJTRhIvrBC95iROjlxlduLxjL3nCYZZNt8vk1XHCnwmxaafYZJZN4BxbZYns12oIKaOf
TI08mlSngc5rI4UTeVHCBBNe+pmduyJPiDqNrscLzlxBuPA80MELg+6GTnrNiGrXvHig54CH0/cr
ikpK6VwD6tsWFk5r+dqgz41Sb4wOGzS6ROB6Axd6N9lC54ZjPsFz2o1GxzNNvCAyhE/P62mWo+cl
rct3k0FcRKJ6vE7qSIssk5+JTJjkHQKMjMhz4xeYTuMFEzjHEkw+gYtd8fBM70Yj/CIvXiwyhE/P
62ldH9MKTpfvJoMI2fk6WUxaZJn8TCiwGCYfgMjT+U2Ynhc6N5ipxqQRvNgZD8/0bjTCL/KCOHM8
0MSvRupGyM6mcwz1yVfr4erQyRMnMKyjE/mFLm+2i0wESk+cDuPZnXhrqxuGCgs3TL+GKHi3Biwy
ko3jFNVVnNjoZ4eNszwiPK4C4wB7whtHdErQUi9ewgRv+8SklFbj2bJMhnhjegw9A8SP3nZog2Nk
xS08rgI1ILejCIsGzeyk1IuXlYL385cXbwDvpx7gLkhLDT7T4BCqe+cwBtHEkU/f0+CgwC6jpkWu
SCw6otEbDndxk8amTi4lnVLkSyxSLHzstgLjTV7hSTQWfqY39XrL6EnpneXQ9Xvr6z7GLFMq9Yks
U4dYy3g/HNPZ+ORak+h2yhDNXnEq681LR2rgtl8seXp5e6pBZJk6RK7Ce1z8xeMVGUHcfz3ABwyq
nnmPiv6HigYV0+1UfMstvT2VyuXWVQWuNyo9ze4w+ViJSZNat7FGtiz1wbRbOoa3JrP0TkqT35bv
nDCYy8Y5ZaQjZ9sV68d02ZHOdmHabJfPy3uprLdYHelaZfiVy/RBrFXdhPCFZLoK1E2TArbe8QC/
PoR2qGixwdNHJz/cx0+I56CtPRwz8ItJ/l3LokpbYxUjei22B1DunH4dNFGT2Dfu/rHlc5+0fra3
3XlYq21jojYInZRJL5c+Fuhw5jHzIifTYt1XUsae2pj6euu+RVImr/ow4Wa++5oDzgveA3xzrXIC
jzt0vnHv4vvUIYd1IeEc3KTTmENUvAbs6mRWYISofH3UIhqBC3kyHcDkFRmJxropIotjPQhchyWS
9uKzysf+sXykl1fXLXA2R4ebcs18IrYlQ+Ml3wueiOye8JryRRbHehC4Dksk7cWXfL259y+xwUuP
4Hsae8t32pWMHm+ZyUgJaDPZA7y+sIZv6wk/ei48iz5y1KY+dCSGO7uaNZRx43ALMpCZOGqGDlDs
lGGjvWTYFPFTqZDhr8X9QD4RvW40bjA//S5zrh95UrhEZSdKx8oTLV+idEkVSCPmduumww2msamk
G40bzOTT88n4TOfrzbTetRMtX6J0vVmOQFd6PJBFLyuMvK1Qjeqhby5eirFjP0LfrKAn/owWruf1
tGmajpO0TDLRPDFJWvg5z+94f/vtt1FUVISR9F2P0aNHx9AxvclrwmL06T1BFCYQu+nR2bqLj8en
6+C0H72JSzZv6iJtpM+GdleeyedVDp0uqLfE/W5T2indl3razfcmXqS4wePBUlVvYkMQZ64HsvnC
S00X1kN+oU9cczW66JSjs7MHD38Y5ZUGxWBecfDyxkrz8OQMR48exUsvvaSeEbnyyitx++23OwmS
zOm6k2QNyPvQA0G99aHze6A6qLceOK+fsGbTm9Cz6M6pji5rxRG65JJLECosoE+dliRcBNl4MicA
gTsEEVC9h52BNGMxjX4V00pPofNDJ6dOnVL79DrOISdORvi4EUvaZGlpqMeHjedRWDIEZaWJf87V
lBPkbQ94+dqm8E8Jv1+9+UsIsN3xgPi9O7zMI/xBvXXXg/2Hjz/zmkM3S2XxpEGvFMnm5zSyCFBc
an9wPF5x1GSRzPYP03rQ5+fnqwbIja+5uVm9ECuefj+8NGYHTfgINjw8G7Nuq8S8efNQedutqKh4
GDuPtDjI3DJ7181GxZNvKpSedqV9sgIVNRatG94d1oQNsyswd91eJ7plL+ZWVGDd3gYnPB25lv14
mHTNnjsbs2fPxty5c7GAfiue358Oba4yXevNlTLTga6XTpludLftGzj11m0XDHhGfvWU+g4TXfLz
nbahPx06SJNHO0ZdcqkqPA/evIckW0qeHqFNcLVq8CRIDDFo0KDoCmPEiBGJMSVF1YANi+Zh/cGp
qFq9BNdNLEO4/gA21S7G8nkPYfXmWkzy/aJsMUpgPfhIH8XV0rFGXDK9ClUYHYuIB/FY9AyKx5cq
fGg4bq1ahnNczlzS+sFLWLlmB8YPT3z1mSpTek9OKlqvm7Xm+tuNJoAFHug/HuC5oItnDjrG4EPx
7M98ahrO0tbQ7/f9Nrrk5NnAvPvJLCJ3DbN7mHmTxy0/dOhQ2horRoi+6zF9+nQ1gbjRdRfWtPcn
NGEAy557HDMmjUAB6SkeMQlzH12NW8qBg0f4fSxh7N1Uo67sK+iKu2Luw9hal/x7Whrf3YVddY3K
1LpNq7CkZgNqlpA8JXMF3qwPJ1WMcxp105GdWLGAVj0sa/YCrNteF8XW79+MJbRaYdzsBTVRPWzD
ig2bsWHFXCrTOniuWUJlmDbjJsyYMQMzPvNnOPnSDoyaU42HZlgXElFFAybBE0YQAg8EHkjEAzk0
UeTm5SInlEPzBk0aF48sw+UTL0NH5HsavNyUJWdvdK3BgwerO6Z4hTN8+PCUTxrvvP4KUHIHppmL
mIJJWPpULWZNKEbL/o1YumYLrllSjWfW1uCOst2ofvB5JDttNJ6gSePYWVUP7U3vYN+W9Xh3ShVW
r16JiqYd+N6P9iRSRy40Tdi0eDl2DPsyVj+zFlWzCrFx5ULsolkgfGI7KhfXArOWKT03YguWVa7G
CZLCNuxYX4v1Ryfgnrs+hSIXySboxPZaPH1wMr591zUmagDl9Uue3mjl6XbdQChDun0UyO+uB/g8
g989xS/K7eDvaYRycjB4cBFGj3KOqnG3p1wsiDZdvn/T4wzDZOMzjWnTpuHgwYN49dVX1W23eXl5
JpmRF03x1zb01ncKebDez2iIiWRDwz6GJVWfwMwZk4CWelw2dhRQ72dDGPWHD+MkLRxy0U4vYxmG
cePYf7zPFNnKaqN1wtRl+P78GQgx9Mvl2PbjfWhYOg2lEb3JRG1MfL6J1kRDMf3OFVj9yaO4hGaB
Az97lhAVuL/yeoyk1FceXIQXFq7BK3X34irmwS147qmlcNauQrj8OYK1K7dh8qK1cbbsXFj7NUja
ExcifpvKvKL2R5szz4uBRe4e4A8wqbuZuJlRVwnxl5iyaflRSlf8vXInhP5AQMTGK664AlOmTMGe
PXtQXl6Oq6++Gjk0mbkHq4PznNTFL9CK28lpj77xQzQTpePogA7H1z2yBiPmV2HWuOHAbx7HzJX7
bJU0b3iHFry4dCE2WjtRRHYHfrptvoOcN6JKJoxSEwYj2nkSiTN5MZ0dQrDPNIpx+xPLULeiGkvv
3qhIJt+yBI9MoUkOZfTbhoW3brNZKdV0vhVh0lkypyLBCYN49m/HDjq1WXnDBIeszMgkUtfdsTTS
E7rD2m2edJWl2wYFjIEHPD3QwY9j8Bk2vR6dXj2FUCt9G/zUqdM0gxAgFcEazT0kua9fCgsL1X46
P7Px8ssvqzuoGHbmzBmMou998AN/BQUFMVtXiUwc46+7AVj/NDbvvQvzp9jX+OHDu7Fx924sWhDC
/o0PoHbLBFQ/9yKuGVGMhl2rcNsqdW1vlIM7O/+KMX/TNjinCYOUsy5f0I2logqhfbBjHxgnDs3H
cZCIP6kYmvBB+2V4aMM2lDbVY/9vtuGx5bX42/GTcFfbKaD8Hvz0qUrkt4RpkqrHnl8dwOjxpTj9
eqw2b0gYu/9jvZJ1pe0mb/I+waRrsJWJI91X7Gy/hHSVReQHceCB1Higk15QyGOtar2UyOY33DY0
NKonwlOiQlYSEutCffrkmDFjMHPmTDUxbN26FZs3b47+OH/6NE1sWmDx/NO7oYaOJgsmzMSd5cDG
pfdj05uH0dTSgvq67XiAtnB46+b6cQV0RU7JURdjWBENuYd3YlUVXbUXt6rVSVRQyhNsOf+G4GNz
6Mp+23LUbN6LBrKvqX4/nvz2SsJNxqcm0gge/hOeWLwQ82q2oz5UhDGTJuJSwhbmhjDxs7PoNP9p
PLt1P10ChHHgVz9EVfVyvE9zUXKhGYd2kRs+c5VzRZackH5M7dM4+3GpAtMDD/TcA5HboqiL5OSE
EMqnK/rcvHzw227THniM9NDDW2RXXXWVuouKzzbq6upw7v+y9y2AUZVX/r9MJu+EQMJTQIJBBQSr
VoQiuKLRsoXdFbRF/pZHCxZcajfZtlTMikFLpam7oaUoLWBFyiJbC7qFrktxaYWKiLC2oHRLgICR
dwh5TzKT5H/Od+ebuXPn3pk7z7zuB5P7Pc453/nO/b5z7vdubMSJEydw6tQpjBw5Ejk5Of4sCpoB
CNMMwpwfbwBWPIO1SxeCTQW7rDEzseaZb4jBnYz75yB/aykWPrRdpI0bR1bm0HYs3jgZPxAxyh+7
YF5bAG/ePHchndrPcUnJNNjkGR9jHK8bO6cUS+teQOnqIuyiOW3FmIzB0jUr3HMLo/DcynlYXLwS
s3Yp6b3u+gbWTc1DamIeypacQlHpk9hVqtCcuXQdxpOtITOCTJ27tRQozV/HOXxAw2333jZUk9BZ
glq5M19e2StcasNmefd9HwoW5yfj9fI2S1sPLtr09PKw4iwJREcCYnEU6T47TYgnJ6Ug4ccrn28/
UX4Kl65cxutv/WdEucgmJvoyohvgifHSpfhATYYZPHv2LI4dO4YKmmy+cOEC3fXRhCVLlmD48Bu8
dHx8gSh6AV2OGtQ00BAOfa1nZ2s3Z7hoZ7oD9tRMWpZL8+F8NaLb76+cmKa2bOZ48Mfz8gdHHaoa
eEwrCdm52TTUpKXpIr7o3pOkNBquU8wSi1lYYhf1UHh4ysOzii57XVU4uO+wshdDleR0puPz941H
rtbKqWBi75Wy1JY3WM6Mp8bRhoPhy3SZvwzLp5q2jLOelgS6pgT4nL/s7GwxmsPz1++//75fQcQ+
PYplPTxhwgSR3rf/ECTSJX2JYgojAfZTp0/havVVGp5y+REwiuDOiqHq58GvIC7QhDunDRs2DH37
9sXly5dFL4ONRp8+6l5GeI3ZnpqNXK2t8PBK+zdov4h0qSq/r2KSEMxD8LJKaOVJkiMURdH7pohQ
ahbxxzxo6cqwnexYpnjpDO+lQ+n2NOJfxPIfHedCzaVqVNPKNO+6sBa0tPRBE7/6DjUawd6nLL8W
LlhYRwy6UVo6ukBWpCWBHikBviM8gSbAnXScCB8JJVRFr15ZSGnxqpJgkjEyGKLpkSYTTVzPeLCW
k+0/SCZ86q08+ZYNWlqady2RP5GOafSKATDKWxbUKJ0FINMkLMexn+O9cVKUvFpM+gWkF0SZ36Gw
sqKMUyVt9pOzD8CDs2Yp/i73V1OWqPEvBRgr+lpGOb945aXN2wqzBOSXdCykIfe3xYJ2R9LkqQve
Ec66h3eE27Oze+HKlWo46ea+mDtFy6r1YdAsedWU13GDkw1diVVIdkxjNKoksmLqpXt7B95SKYpE
XQZ1j4QPYOTKrvzUWNIvaerlJ2Gsp1YCsh5JJa6WvxY2lHAgOjKvUOhZsNGSgGyX0aKnpSPpd7d2
yFe9JifbaYjKTtqXdoSnpPD4eBoNU8TYaFB7YWFGt9kQvegS1NaDsMKinLqMMbPqn5q8qiBSn4lk
JZ7JqUkKvydOhasmaflDkEC0ZMh0fF6gmwe9uBDYs0C7jASk8egyDAdhlD5hhe5pbWlFq9MJez2d
LOtw0EawEOY0guQh1KKnibg1nWySMp6fMi4YPd90daOUVCRVX8j4hyQ/vjmHW4kC4XHPg53ykOWX
TyUt3n+7zheWWk7sD68mBpavlm4s8gjMgZXacRKQbbfrtAljWfEGcN7gx+dOscKxXaFJ8NZWl9g8
Z4wWfopsKtyE+OczKB82WaYqf0xE5hI2wSggitJFgY5FIv4SiPa7k/Ux2nTjLxkrx8gkII1HZFQ6
FjuBx6dIx7bbaF6D/HY+8TYjKxOJQc97Co9xQ6HJ+Y3wyHYyLKkcpLLoZOx1O3YikbfEVQslFu+N
aXJe/IsFfTX/lr8zS4B1YFfucdiT6OY+2qMhajP9sfft249WJqXBRvsSZPUWY1gRVHRDQxG1Nys5
jRrBCAgxL5aLjwQikXUkuOGWzjIW4Uquu+F1ZcPB5wAqa2LZMpDRyMntI95Ps5PO0iCLmMBzEJyi
U98jNSbRqgjKeL4yOaPLaLQyMkWHBdURCskUcz0ESE/+6gqsrtASVp3OYpLx7NemcZzlLAlEJoGu
aji4Zdhs7WjjKQ268tXe0NRIcxrtaKQNdHxft7JEhxRyhA3HTG8j/C4bmS8qiTLH3lENnEVpLm8z
soisOnYO7PDfp1n+1e9dwfHWAy8Nbxy/HzPGwAyMl77l65oS6CztMB7tRKubWvkyjDBdGx9tS0tt
eWMfy9D+wJf+jpbbtoC3mPPdFp3BxV6o8S1lZ6mssS51uO+N5WMOVzEa2nLofzyoDYEaQ2vozcKp
aYTr57y0+YdLy8ILVQKdqR2aq++hljAwfD0fjRSG406FjestWQ3ubdD/ruaMGnlXK4fFr+wFiBFR
7h4EcRKE4RVDEQiBlbPej3E4L/njsHRqeBkXzSfTt5wlAap9sjJ3AWHwklteMMXNSdzc1wV47kQs
sqIJ1vCl8gsG14mK1WGsSBnxJk3uRZjtcSgMe3sY0gBIeoEKJN+PhDGDI2EjfZqpP5HmYeF3tARq
D+3GxU3PwXnls6CshNPjSOo7GAPmLUevcQ8GpR8VAGoifIVGG196R23UfuDgf9FJVKmoPPcZZnWJ
s4ni2ci1IjeTtxkYLV0rzMZYOTfLWLEqPRIpKz05qw2CNl2dJmnE+6nlKd75W/nFWgJsMK6UPYFM
ewJS0sydAhqq4WiuvSDyQNHLcTEc7XRQoeiZk9FgXu15Q0ajlWbE+/UbEGt5WvQtCQSRACtVVu5G
hkMaFi0ZtTJW4+oZCjWslo4VtiQQmQQu/uI5ZCaSweDhJx7SMeGojy2UsQlQASJoJwKcVzx6G8yf
cGKTHy25TU3NoHGqdjQ1eC68Nsu7BWdJIEYSCKTYA6UxO+p0tT9GrFpkLQmoJNBy+TMkp9G+huCT
biosxRsKTjLpcc4rLo5OtuXTbXkGnO0GbQx3ge7XINdxc+LBhNVGN/g17H8fLr7L3O1cly6j4YMj
aKPrUS3XnSSgVvTuL5yQisc48hcSogVsSSByCXDvIoRf2pxlyH2tXPz6rP49Eq8fIfAT0uiiuO//
RsQHpBc5x8EpUHNKoN6TjX7cgbI1k0XkpVgOR1Nw5BhA8FLf/fv348iRI/jsM33L6bpagytrNuDa
L7airZbuM6+6iqs/ew3XNv8H2uobY8CVRTL2EmDFHsypDYgWVhoG9VMLE0nYDH+R0Ldwu60EuNqa
+KXNXYb0BxZ4xJCYOxS9/nmDwE2fWwz79aPgOnvcmJYHM8Ye0QypPYg5DZoIb2xsQ+/UJLoCNVAD
jR1T586dw9tvvy32iIwePRqPPPKIX2a2jDSkXD8Y1/7jLbrZ3Ea9i2bU/eZt9P7ql5GQLLpJfjjx
jvBf+SOVTsfINd7lDy0/KZvQsLzQyhePJ0wi9kpZ+vTy4DiZ7sE28JiFM0C3onukBNppT4NYnmqi
9OkPeg2GBBeGY/kWJN08ngzGJ6h57lFDepxXPBwfUsg9jHY66VasnurfOxEOp4O6HurLjuLBipIH
70Lnns7Vq1eJH72GThMvffogZ8kCuGpqcXX1z8UxvVkzpqH33FlIpFsHzTpHTRWu1DUhLas3crO9
V7uaxQ8EJ4fYXOKebmnIfF+qi4fS6FIpc2sqAuXW1dNYLvrv2mzJ9IeMtUZBLw8tjNkcLThLAiYk
wFXbt9mbQPIFSR45QTEYK8hgNAQYSYkwH99cjUM20stiAVUbtR0yILaaaw1wtrSTItZrYMaEopXC
u9BZ4bLBaKC7PXgjib8j6dBETDud595Ox7jTgmEkUo9DmD9/YP8YVyU2L5uB6Q/Pwvz58zHr4YdQ
ULAM+ytDnw+pP76ZcOfgqM7myuPbCjF1+lQUbjtBPPi+0eObOW06Nh2t8edPE1N/fCPlsRHBITWI
XSroKx/zrAerp5wuYTgPvZ/53CxISwIhSSCE+Qwjuq4z1MNYTgajjgxGMHpGRKIY3+akPRqtxIiY
DKeb+7Ky+iAtuVdYs/3R4Cs9PV0YDDYcAwboL/ttvVaD6pd/geb//TNyvvUN5Cyai8Z9B1Gz5Q20
1elobx/GarB5yXxsOjQSxWu2YCcNhb25ZQ3mjTuEkvlP4XjodsOHuk+Aznxkd2z9b3DRo7g4phJv
bTrGHvMuKxmd41AX8yx3Pki1AVFzZxSvhrH8lgRCl0A7fdCKISoepgry06PuJINxbfks0msNwmAE
pMGXd8fD0Qe9zWaH3ZaE5IQU2Jxtdlo31Yomp/w6iwcX3jz60NBTZmYmzanYMXnyZN0hqjbqojnK
T6MXDUn1WfhV5C6aj8y/vR+NH/8FbXzIYgBXf/QNbDoJLN3yAqaMGoBUyidzwCjMeXYNpuUDJyvZ
6LhwdEcZ5hQU0Bc+/WhFw+5yxRiV71iFFZt3YvOKORRv9uv/t/j9ccZXZFp/dC/2IIv+qZ0DB7et
wgx3nnOWbcRxddei7hP86qVlCj8FM7Bq2xHi0u3qy7FxGfEjcBdh8/5KJcFRjlWLVmH/kd1YRmlz
Nh4Fao7ipUI3LJVr1bJFWLGDJte6rJM9By6AXqOR6eqnNBLyqcaV9V6d1mWFYzHe0RII1jNQp2t4
ZYPR8MpytNea6GFIOhoasQimpGQgJYmG1e0psCen0h3hSU1wksVKT45FdsFp9urVC4MHDxbGon//
/rpGI7F3NnJpTiNn4Rya3+gNe/++yHnia8j56ldgI4MTyJ3+4PdA1myM13ZiUkeh6GerMX1EJhzH
t6Jo7S7cUViKDevKMDv3EEq/uw2s9p31p7Fv02psOjcCj399IgLnVgXkz0bhtCys/4+P3Gy58N6/
b8KgmU9gJhkpaeLKtz2F4vV7MH5JCcpKlyL30FY8Of8lEAVy/DIOYdPvUlGyZh1WPj4ee9Yvxcrd
bByo5/TEYmytvAPfX7MGT8/Owasl8/GbCgep0CacOrkHzy4tRWPBbHxtYirWzi/Cr8+MwLNE51k6
deB3h06i/KrH/HBmXdixolcbBz0johgF/+kyaSQYR4HRN0JdWDwW6/GXAClz0dvgHkeQn5o5Nhj1
G+hokO+9EhRP0jW7eVCdTzj+FJqHTUmhX2oKkumyPnsbKSh7QjMS26g71AGO5zTGjx+PkydP4sCB
Axg4cCDtG5ETyQpDtox0ZN57tw93SYMGgH/BnF0Yw2QkBgC059yGwuI7MXXKKMBRhRuGDQKq1FZ0
Grb8rAicW/3xDwNQoqTGTIybMQdYuJmGviZhlOs4Nh8C5iz5PKoPSNQa/OH1Yxg0uwxPzRgrIl/c
0IKpC1fjt8fnYoYbbOm6ZzGJMx31FEpO70HJ5r24ekMyNp0HHl8zF58bSgNYsxZh5s5D2PbOCUx/
TEHMJ7qrF4yFq3InVtKezaVbJJ1nsWT/dGx204/vQyr4aOUqlX0gutIYUEP2sSc+AWJIG1Z4NFqY
Ea0SdBY6chFHZ+GnS/PBQ0bcCwjiEjIzPBBsMOrKCtH7B2/Alt7LF1+/aiq4nFccXEtzExLtSbSp
T7mMiW7yS0RzmwvO5to4ZK+fBS+1HTt2LA4fPoz8/HzcdtttNNEdSM3r09GPTQfqroBNok8vgSbH
Nz6zFgMWFGN6Xn/goxcwdeUxLwmyG+xcLY3ImlkgDIYSE+gvKal6J7LzpmIaXsJbf6pBf+d2nMdM
TBySgR3KiBcZpss4Ssr8C3cN9xCzD8xHPoVaXLSszc6TI+NwU64nGTdOKgAOtsDVpMStf3IWfu5N
FrisIjn53onDxbdzczXPrORjULYETMXYSVQwyju+zqu8o59vqA0nVPjoc2xR7MYSYINBTTiQS8jK
QO8XtgkQZwUvq12A7OUbFYPBsT741HZ8v3i8pE0YJy9w+L7mlmYk0XLbhASayiB7YW9rc9LZU20d
tnqKi8LXzU6ZMgW8Z+Odd96hS6FaRdy1a9cwaNAgMXyVSl2kcL78hn/hPmDTeuw8+nUsGOvRnnBV
HMLWQ4ewZJEdx7d+B6t3jUDpljdxx4BM1BxchYdXuWe1w5J1b/zd47dg8U/LaDhqH8Ys2SgMlodi
ahaGEd1Pz1wDxrpNWXMVLnny4l7OX3CRLF2em+VL//cxxd2LRJoDovE2lGz7Fe7OcMFlBy78+UNc
yrmevpfPKhTY8JCzZ+XQ35OoYYspVlQ7cHQ/dVPu4tR4OlbUsTAcgQyAXn6B4OMpDyuv7ioBZego
cOmyvv0jJOWNBhuMayVfQ++SX4gwYzV/fICGp3zxjWwG5xUP10b6uJVmvhMSyHAkJcKWRN2OdiSh
TX7CxoMLnTyGDh2KqVOnCsOwe/du7Ny50/PjcHV1tQ5W8KjUEVMxjz7htxZ9EzuOVKCe9kpUle/F
dxavJeRpuCcvlXoT5B3UDzkZdlRV7Meq4j3ULWkWvROjHJy6CfwS22nCuh0jCh5B1vl92Hd+EGbf
l0fx6nmEAZg4MwuHVi/DzuMXUV9FE9vPllAHYDLuHyUNWx2KV21DZT3xe3wnlm89T/MidyF3yG0E
VYeSn9IKLSLZUPkhli0twWt/VboPCgfKgEtK3jhMopxLnt+Miqoqmuz/IdaeBPqrR94oPT4uPhU8
sHHSMyTxKb2VSw+RAH+vsdI3+GV+9wWk3TVVGIzqf/4K7PmjhWDaGmrR8M421DzzuCGuH02fHkns
5JtAWx34x462+cHOVqylhSbDW/hztOOcjdYA33rrrWIV1XvvvYfy8nI00plTJ06cwKlTpzBy5Ejk
5PCXc6guG3N+vAFY8QzWLl0INhXsssbMxJpnvgEeAcq4fw7yt5Zi4UPbRdq4cWRlDm3H4o2T8QOK
yaSpA1+XjiT6wvcqKEUhJiUTNTkGlnsb5o4B1qbNwufcdoB1tZwIH/+NdXj8MvVwnnwMqwXxMSje
8G3kEV1lFGsMCrAT8x9aL1KzJj+OF+co8x/f3lCMcwtX4qv7lNIMKliC5Q8OQYKjDjxSmmJPdH/X
D8G/bFmJlYuL8fisTVxojM2i6RpPl0eQ7oR/WLmHY2SkUZBPLpqko47rhEW2WOoWEmB9GqgHkHH/
LLSc/gTVRV9GOx2B1PyH39PyWhpxIOc8IhfP+IrCaM7JqAfiix15yJaQSKqOT+KlH5FL+O1v32qv
rb6KuprLWPjEdyPPIUIKLKAzZ87g2LFjqKiowIULF9BE95cvWbIEw4cPj4i6y1FDQzUuMkx0GFi2
dge8i3amO+jY30xalkvTDnw1ottvnKlaEUnl5A8daFjN5aBzv2iMKTNTy49CR6TT2FImM+XjFH6J
YZ00N6CjAptffge3/L95NOzG+LTyas7D2H1vGTbTRHm0nVHlDj0fKVdjmXppGsEaxXsxg/kCvbdg
uF0pPXrvrXOXOh7v8093D8WAZG1b9col8eZ8tJ0/ryyrdUcP3Hta+C5MGe4FVPmM3s/FFhc+98dP
VZCBvXzOX3Z2thjNYVm8//77fghSRpznhAkTRPr1ebeIxUntNG6WQAbE3tZcg+TUdNgd8hPZj05c
I5jpYcOGoW/fvrh8+bLoZbDR4P0ckTp7Ki3d1dfNRJoVt1cGqSq/cb6s1NznspjRbzqE2Eh5c/UH
ME735dcfk2JSSWZ/2Yqlj23F5GnTUP3uLhyrG4SVD9EqsZg7VtphCkXwpsWV9OSTgdgfzEkYLb1g
eFa6JYEwJMDVLEBVa/0LjQ+7Xdqjj9HwlPfjLevpVXCdPIqm17dIEOVpRM8o3hc74hDPeztpKMxO
G/xstECJNvllI7GlllZP1URMPJoEMjIywD9egutyucTEeDTpR48WrceO08sLnWcamvvZTnzhyAEc
PXEJLQtK8J17J2FIICsVeia6GLwvIjS5qI2BnkBlHD8lrIzTsiANhTpe4qjjLL8lgehKgM9oMnuQ
YPbi7/tknvHALIB+jVt+6RNv1NMQ50H5QMYmwAulkmnIm3saLlcz7E4yi808q2ujwe5O6HjVlOUi
kUAqRtwxhX6R0IgHrtoABFPwalg93qRh4TQ1rDQm6jg9fCvOkkCYEuCqZbJ6nZ+UZy4TI3pG8eao
moZKS85AAq3Uam7hDcRkKpKcDbR2in5kSSwXjgSkIgoHt7vjRCIbY1xewWHOyVbF8Mowojk8C8qS
QHgSSOo/GM0uqncGq6eiFc95cF7xcDwP3ka9DB454PvCbQlkLBIpts2hzODHgwkrj54hAR6i8jqf
gDfax6cod58oVUAxFnp01HFaGt40aUJUJC2vJYGoSmDId1aggU7qbqbDCttIy8bix7Q5D84rPo5O
tk2001VG3AJpyS0SM9CWSCuFUmj7uuWCSIAVkFb1aMNBSPSQZP4qUYyGV2kbF10FQ14hZR2xyij5
9NLzj/GmqXwmwVQYlteSQEgSyL73i0DpBlS+uBwt5z8LCdcIWDunkTxoMBmM5yDyMkKKYjwvtJV7
NRIS2nlHeAtZxQS0cR/EchoJCPWlibOC5iTAGto7JBR4UlylzXktuLAhqjjFjBA9dVwwLpT8GVWQ
Y+xQ0IORt9ItCRhIgJV5NBW61mgYZBuzaJt7Yx9nwB+CNrutDYntaaivoeN4LaeSgFQ1qqiQlJYa
r2f6WUmHrqjDQjIWsJtc6HwYk7RSLAn0JAkk0TJbMTQsjAcNTzlqLqKmxkmHFhpvSOlJArLKGk0J
KJ/2isJmI8w/JS5wLmbh9KgwfT2DL2HN5C9hraclAUsCyUkpNDfjQAKd2iHmNNpcjUjvNRA5bdXg
+7o7g+vo7phXBpEoLxUV3xlhb0I38wV7b97dprLgvgqc09nAsLgUQ+ObrmBJg6CXJulKGBnmZyB4
NZzl764SkPWvq5UvWLsyUx4+BDZc10J7M3hC3yYaJfU0mtuSkZ6VhcrKi3TRRkq4dKOKFw0hRc6Q
VDyRK5uuWllDlaGZ9yZloWcUAqWFxot8dxIr8ncoKVnPrisBWb+6WgnMtCszZarno5HCcA1NytRF
K12hwTK09erdm45GdyArpWMPLAyjLHFAsZRNtIUsG4Be54vToi/x6FOMtkwsepYEOrMEWmhTX7Oj
iXa60/w3Lb211za1I5GOX7UFvNuuMxcpFrxpv1RjkUfPpakYDgMZe3Q8p3sCIQqL8Qzoh0jJArck
EKoEag/txsVNz8F5JTZLbpP6DsaAeXQ17LgHQ2UtLPjMdDrElc4nTE6hUanMLNgTqcvR3kIXMbXE
/Tq3kArQ7nSirZGuHcz27idpp7sx2uhcqkRThwuGkp1UVpEorlDy66mwBvI1iA5NStE0HFFhKDT2
BXRH5RsGqxaKkAAbjCtlTyDTnoCUtOgsLpK9cyni5toLIg8UvRwXw5GWli6mLhxkJxxXL9MxIo7P
0NJ4EZ39igXHX0/i6itb6Cz6M0J2bCxq33ob9f/532Tw4s09N2bLRSoBZYhKR5bSZgfsLejg+THk
IeSXElpEtOiElmv4Pa1Q87HgoyWBi794DmmJZDC4csfoKBGmzXlwXvFwTY5GWmF7DU2NdWiqb4C9
2pmJJOp2tNojP3o8lgVobWhEw5530XyyAjkLHoOz8hyurN2IrC9OQZYyqxqF7FkRqRWE2q8mbxSv
hrH8wSSg/9qkbM0YhWA5cLr2nZrBsWAsCYQngZbLnyE5jU+ElfU4PDpqLD1ayVStOa94uBb6KLeR
oUrkk27pn72dLgtHYxWaOsF9GlI48qle7ZBGl5f0fuwRVJGhuLyyDG3VdA/IyBvR66EvUXcpKUqy
i96LjhJDPZhMsHcRLD1aRqcHvwKr6KFLQPYuTGKmzVuG9AcWCOjWqk9RV/Y4WivKkUDXQvQqfh32
60fhymP5+tQ4rzg4PnOKb1ZV1sGT0UhwVOJKdR3dOj0mDtnrZ8FLwSorK3Hu3DlxSx9DJZEh6Nev
H/Ly8sRtU4l041TW309F7X/vRcOv3kJbViauX/pNpN4yUp+oFduFJKDuDUhlH8womC1etOiYzc+C
6/ESMFnl1AaDZZaYOxRZRetx7VtTkD63WBgM19njvoMfHSBcW6JiMPheI+6527P65qE1sQ7Oq+Hc
vx15CWpqarB3716cPn0aVVVV4sIl7mFwbyOL9o/wLX6TJtHFQX1yUP8/++CkOY30+yajtaYW9f/1
DpJvyEPKiOHKjrDI2bEoxE0C3LKUs6l8e/JKfHTYMGq9aiMVnZwsKpYEWAJ8AROdIm7KpT+o9DDU
wMJwPPNLGkWZANfZT1Dz3KOG9Mxe9qSmH47f5eKNgW10PiF/zCfzKbcpyEy5iFz7p+HQiwinrq4O
+/btwx//+Edxvevtt98uehXcFWJjcurUKRw+fBiNNKb2YP9BaF/3KuzXDUTfwkVwVZzF5VU/gS2n
N/p971uwmdiY6KipwpW6JqRl9UZudhyur4tIOj0BOZDhiKT8gYxCoLRI8rRwLQmQBLhKG32rmBSQ
x2CsIINBc7mG9CLMxyQ74qSQ1NQMZGVkoXfvXNhPHfs9WtptqKuPzvIws4zwtvaPPvoI7733Hm66
6SZxifnQoUPFta7c02hsbMTo0aMFzMEPP0T2uYv4wh23ou/M6Ui78za03XoLWq/SHSB2u6FMPby4
KrH5mSex6ZB6WfE4lLz6LCYN/r+0YwAAQABJREFUSUX90Y14qAj49Z4FyPYgGXnq8VLBQ2gu/TWK
7jCGdtUcx2/evoB7Hp6CvjTlcvSlAhQ1l2JPUbSu0KvH5hkPYfv0MuxY4L1nGI6jmDO9CPeWvYkF
Yzu/YeQepTJ3FS9lHqeWZlR9rPjuLYEQ5zT0hOE6Qz2MZ8lgkA4UzqjKmuzR6OURSlzvPv1IL2ci
Iz0L6ekZsE/84hPg2fFLly6FQidiWM7z3XffFcNR9913H/LzvZM9rEiyaQ6Df3369MGZM2dw7No1
THjsMaTdMlrkbUtPQ++5s6g7SPs0kml3oqGrweYl87Hp5DgUrynEF27MhavqBHasfhIl85/Cmp2r
MZTtJd1263uIipESS8WU4qVwDcswzJETXOfew9r1OzHiHxSjcd3kYhQjyjdtkU3QMwvpgrPwz5oJ
WLAYJCrDU0YtI9QM+b3FyhnViVjlZ9HtahJop2tRIxk2crLBWE56rd576rhcGKSVBecVDzfk+nya
a3agob4ONXXXaCN4Bzk2GhcuXEBubi6GDBliyAWn3zB8OGrJ6rakpfLImgfWlplBm/3oa596Jkau
/ugbZDCApVtewJRRA5BKPZPMAaMw59k1mEZ26mSl+zyWukq8tXEFCgoeoN9cbNxfKUg6ynegcMVm
7N1ZRvGLcKTegZMH9+JMtUOkl+9+CXMKCiitADMWrcLBSgcYZ/aTWym9DkXT52BHeT3qzhzEwXJ3
T4cWH2xesUjgMN6iFdtQyXNM5Mp3rEJh2WaUFSo0C+aswJEqd6IC4vs3WdNDpPL5uPpybFwm85qB
FZv3Q+FcyWvRijKsKpyh8DKnEDuP17jR67GTeCxctQqLZii8zFm2GRVu5PrK/VixyI03YxE27i33
yTb0gN471IszQzmWjSlcnszwbcF0eQnInoaZp6awbDAaXlmO9loyGGbwvapQQym6wSuXL+HatSo0
NNWgxdnYcUZDFouHqXgoysiaOmjXd2NTk1ht7yJDYzzAJyn6Pk9/8HvqRczG+AHqeGr4qaNQ9LPV
mD6Cv9W5p7IP6z/oh5Vr1qBwGrC15EWUk4J0OetxbN8mrFx9BNPmPYphqcDFg4dwtqkVrsqdWFy6
HXcsLcWGdSsx/tIeFM/fguZ+t2PBzDEiw2lLvo5x/VJRd5GMxvlaEXfkZer57MtBcdk6rCstROO+
9Vj7doVIc9afxrFdm3BmbDHWrFmJgvp9eP61wyJN78/5w+9h/8GD2L9/P/3o+T8fgmyk21Vh4xOL
sfVQGgpLy7ByyT3Yt6kE/7SNVmSQ47xO7tuFj4ctwLp1ZZg35BhWP/lNHHTbjepzJ3Fszx7c9a0y
wWf6oU1Y+E/bUE//djxZgn05j2LNhnUonp6GrSsXe/DcmYfwICXvp4vlBU6c4JcYAm0L1JJAHCVA
ilz0NrjHEeSn5ooNRv0GOhrke68ExZN0Vd/PalJR99fUXEV97VUxjJxoS4T931Y+R+eJZMNJ7fYr
X/lK1DMMRDCRLve4evWqGKbiL+70dGVgReK00T24PBFeXk7rlqk3Yaev6FDPyLKLkatk1clacsUO
KyL1F2kWVv7rP2I825ChRdi4qwy19IE/0M3MknXrMWMEWQxSmB7n7gDUVjfC3u9OFL76KqadAzKy
h2Dqg5/H6u1NmPp3UzAkKQHVYiCJ95O4kDNxKYqnjqeeTzbqq5pwC8V+fNHdC2mhr4xxS/Higim0
SoFWKzyajz2vH0NN0Xi/+ZZkFtexrSgppqeOc5TvwdbzwJINqzA9j3i/YyzW1P8FT67fi5pZoxQM
Mqg/LZouaI94YQM+KViIvUcvYvwkGn4jVsYsWYcFU0YQ7Fj8a1k1zf3sxOn6acoJAk31VJo+mDxv
BdbcdQ6DAo/Y6XCoivJdQiUSvFHq96TC0fWGAqtLIEBkLGkHyNZKClEC2rYdInok4DxkZKIHkECj
JNKxwagrK0TvH7wBWzodk6TFN6p2cRqecjkdtLHPLnQwf+Tbbr75ZuQNH4YB/fuJSFbOEf9IGvL7
0I+WW1K8D6N///6il3HgwAHwSiqtY6Pxhz/8QSzF5WPbU1NZaYfqSLPWXYH6DF+hjGhyfOOyZdhJ
Q0e0t5J+D2AkGwx29iRS8fJNcVoBJgqDIVI9f+x5U1G2ZBo+Wl+C+Q9Px/SHl+GDCw6h7B1OBmuE
S44FebEwcHA2Dq5+WAwJPTSrCHsoLd09LcN2KGvEIEGDUZxsRKgnlMgBjeOkrNll2EO9Ac+PhtEG
ueFcTuZ9DMbSZL90w79wH3l/h5NUbBcRyJo+UWWMBuJu6iAd/PNnAryFYMaOlGaT5k9uvI1on8cn
F+x45EdLMa5qK4oWzsLUqQ/jZ3tOwqUZGZN5hveU8pfP8KhYWJYE4ioBVvg8nRjgl0CTyb1f2CbY
clbQHMaKBcgqXK0YDI4NgOuTpjUugmIM/tD9y0n89U2Ks7XVCVtu335IJENhE9xEKUOiR5bHTUzT
6NkoUQr3Mq677joxLMXDU2wgtI7jeOktP3luw9sTkbS1GP5hRUnuws6jcqye+WmnJbsf0LDNITg9
cwApKsWs4TmrH7zfBd48XDUXkDbucewgpf3mtg1YOjuXhmloDkLVGfFofw/aRayeX4yPP1eMbTvf
JmW/E4+Tlm9k/S5dCHdhSTsnUf2fx3BBFp0Sr5z6C/29B4MJketB3Qd/od6CdA04cQwYdr2yZ4ft
WOUFlbm9coZMRhZuHOjCZecNeGozGas3t2FNyeOo2rUaz+8ol4QieJp/txFkYqF2awlo2m8cy6oM
HfEQlfEv89s/QlLeaLDBuFbyNWQv3yjCzGbzxwcC4vrSjU857fQRnUBHortcTjjp4FhbC88Z0Iy4
i85Lj4kT5dIUjgwHDzXxxj3+3X333WIjH+fPPQ42FNwNYsMyfvx4DB8+HHl5eWI5rsKjhl4AxlNH
TMU8mvDeWvRN7DhSgXoqb1X5Xnxn8VrCmoZ7eNgmmPPvBAkMx9n/xOL5D2HzwTOwZw/ETTcMo3i2
GKT4SMDsP3OiEg6vVgYdE4nTlDJkUF9areXA8b2vYD0NIaGZexTRdZk3TsZkIlny9EaUV9Xg4vHd
WFa6D1nTJkKZ4smllQBr8eLO48RjPY5sexG7CL7gtiGCkeT+NNOzcjn2VtTAUUMT6s+vpngyOKmf
4kdPLsb8sr2osmdg6KgbwRhpSZF2NbQGw/x7FgxbfywJdLQEuJfA378Gv8zvvoC0u6YKg1H9z1+B
PX+04LitoRYN72xDzTOPG+L60eS84uDsNCrELZONRlubk+4Ib6hHKw1jGE1ER8wT5ybaPv0hYyEd
b+AbM2aM2NTHQ1XV1dViNRXPYbCbOHGiWFV1//334/z588igs1iSAy6tlZS1z2zM+fEGYMUzWLt0
IdhUsMsaMxNrnvkGSG0qsxS05NbQadL4C5w7A5lj56F45gmsLF6ITe7hrGmFZbiVv+KHT0TBoH/H
6qL5uLT6LUyUxGkCvnBJAZ5cW4SHmJmscSgYl4U921fhyNwdSJNw7mcST1wYdCeYDzGHr8HhqY5k
OlwM9jx8b0MxqheuxOJZvJqLs5uHdU+OF36APhQGjcHpjU9iOtsDcgWFazB9iKL8xcjYoEasXPiw
kkhDXSWvPoEB9lQ8t3IeFhevxCy2MuSyqMf18tQ84Q//j2UkwpedhdkZJMBD39zbMHIZ98+ik7o/
QXXRl8Wy2uY//B5t9NHOznnkI100I93snfPTRYtaJE8xtJLB4KGpdhr1SXim8FvtrbTXoYF6Gqt/
/krUMlIIuYWnliEbDiqtjOLzTI4ePYqGhgZa1nUNb7/9tjgca86cObjzzjvF/Eq0mHI5alDT4KJe
TgbtATHRwzCVMZWHJi7qaRIjle718H5rSwMpN69piAkcsgeZzIcL9fUut18DF6Wgg873cpGyz0z1
cnh04xwsx9O0OXAU5V8PeypdtuJJrsdG2jyIH+wEJQv+fMvHjLngoCXIhEjzTbTJMl61OEoyscj0
PAmwAoyl+9PdQzFAuwxelWEiHbzaRh/BYlmtO37g3tPCd2HKcBWk4g3Upi62uPC5P37qhyNGOjyx
UtNC7MXjvW9ynvn999/3QEmPlA/nO2HCBBF94013iB6Gs9VBe1Baqbmnp9DaW2rwtHnDvCNGmBch
/2AvgdIT3PCcgcpgcJCZ5AlxNh785OEpZpj90Xb21GzkRstWeJgjo5CUiiz6sdPTm7ovno5voc6T
W9Emkj+6xyl72HN7UiizFMGftxK1O86hlobFmD/uyfFL9fLfDkdtO42aUUVpz6Z0wqZELzYTTgTT
ZadbRpHC9cMXS0R70thjlO6F9PqUOTEFwwhP1kmjdEktEG8Sxnp2JwkY19PolNKzHNaAnOt4uScl
7dHHaHhqrKftZC57Aa6TR9H0+hYPTECPbvU2W/cDUvZJbGp2T4rSkFsb6QB7YmISnY9Oa2+Tk3wA
dQOsUdSWWjDt5lwd70GWBaAId/vUlpPnLQYP9u6UHjBggBAiH1YorZ6HXKfzKIVSi0UtBo7vzO76
L5WhFNcbsJiKL5WWAjfpLQEwQNGNNhKCrBtG6brEKJINl8TVwvDKPyVOUA1KOiiANgMrbEkgoATa
aZ7B7I7w7MXf96GV8cAsWsQ5C41bfukTbxTgvPxd9Ou0q5lW6dB0QgIdkc4fjna5csm4ITJbxEhQ
XhhA3ZjN4PgXmbtPsXXEI7MpyhO0UEFYkfjyC92rtBiRFVg7LVfzOgnvjelIX3beWBifhGVH3h3G
qf58y3KaLSPDSRx/aoFjlCE/Rbbq/OR7YNJMm3/q9MBUrVRLAhFLgKubySp3flJeZNmZzCeyTGgf
NN0P7qJhKZ6hb6dRIzuv5W+hsTGXi6f7DVyozBl8YodKxoCbCKPZPNLR6xFS0UeXSktRhqy3PF++
sclQn40OiQ21gJEpdKWKBciTk0QWkeXTIaK0Mu2yEkjqPxjNV84jhb/KY+iaabKd81JcbOt4Uko6
zdW2k51ooslwF2x2Oh+dVzIpR3QYlzJA89QgmYfUIMYtqIxrxpJPhbaB7YxbOTt3RpHK3whfNlZK
FyBGcJ1bOhZ3XVMCQ76zAg20wqiZ7tXg8f9Y/Jg258F5KV9GLCtZ76MvN1uCje7RSEGKPY1WZabx
nAZdqUHzClS8KOUWW6sXJSbjTkYZqop7tj0uQ0vOPe6Vd6oCZ9/7RaB0AypfXI6W85/FhLfkQYPJ
YDwHkVdMcvAlaqMrwVNooY+N+hsJrmbY26ibw7v9bGQ49J3ypRbUjjFYAKCe873nKwTubcghKn35
dqdYddnj8caVlVRc73yHq5gPzj8ePHSn92eVJRoSYGUeH4Xubm+iuseurnPHgu/TsNudSGimRVOc
FRsMG62i8nPW+IqfSMKJ6JlilIo7HImZxeHaqzQcTw+Dojx+s2QsOEsCuhKIRx3WzThIpFLnPUCx
sxcii0S6IzyZpjH4G6yNz56yJ6fQUioyGvTzcxre/NKtCEsCPhKQtVc+fRJjEuCc2ChLw8wLchW/
VXljIvAeQZTrDv/iV48jE2ts+UxIINtA8950SCGd5Zqi9DTIapD1sIm7YH2Z59aoxPBDNEPZFvX4
lOMwsgWriOmBq5J7gDeQ4Lpb8WVZuVyxfvOcl14eRvHdTdZWeXqeBGT70qv3+tLgs/zCdqTP22jV
FC+W4o8yO48K22zK1xkfP+7riCk3X5I9ya4vnDtkYDQkri5Oj4mUkutJ0tCWWRvuMS/fKqglgShK
gNtR6HqEjwoKx9loTsNup9VTaQl0IR4dN+Rqaab1t3RFKR1cKJxOL8EnI9nuOVLNtzreB8EKKBJQ
C6unyITLzBselcqhVK14yCG8RtVT3opVzq4ugXi0Ia+M7Hz4aTud2k3zGWins/uuXDwvhqVq3Gc+
eUHdw1GqCKXpWw1SJRLLKySg1AzfrwgpGjnHIMPxehrV00C8xos3K5/uLIHaQ7txcdNzcF6JzZLb
pL6DMWAeXQ077sG4iJG3YzRTx6KOTuNtplv8aK1tO13lR5s3dM6eUr4TFb5kU/OEAvVICJiTjZpt
XEraIZlIKcX3SyA6RY3kbXW28urxI9+NnrRkmh6eHrwVZ0lAXwJsMK6UPYFMGvhPSfMcGa0PHGZs
c+0FkQeKXo6L4WhpboaDTkF3NDXCSUekU9FoVpzUO6/FDdR0ZHNK0DMWci7DIwQekmDDoWB5hyck
FQ+gKU+k+KYyiQBI8ucloUhSlt8b39l8ynvycuXLtyxXuOWIFN/LV7R9vvXSS923/N74zueTslVz
Jt+TTJNhNYwZf6T4ZvKID4y2fntz9ZWNPpwvjBdX7ZOyknGXXn0eGbTKKIUVIO2XlulmaEkawZ6C
No0YXfzFc3ExGrX11e5yULuhcol9GqzbbTZ9q8jNS2lKwYrin84Ci6aw/HPoDDHG0uns5ed6LZ3o
GbrDnZ1vyXNoT8VQmMHp7OVn/qTj9iXDnZ1vyXP8nsbaSy0rlTiVERKT7UDKncsj30PL5c+Qk+Z/
zUG09WAy8ch5xcO5WnnVFHUsWJ/T0z5zznxR6c6dOyesiCy8lhmWI6fpNT1PFWbNI536Tbjj1ELm
KLUgjdI4vo3uEG868mekjL4ZiX16C2quS5fRXPEp0m4dDVtqJJdkiJK5OYzsEag8gcqnzVXvHQSi
zfh6OJKuGlfGqZ8yXTEcbOjVqVwtPG9YJEh4DhilqePZr9DUEPbNpsNCgcqjLgczKGG18TJNGy/h
ZeHU6TJNHSfhJD11WOuX+PxkGjIs4bR01elGaep4PZqSdld76pVdWz4JY9QOgpVZ4PNpTPyjqi5k
6a7y1JfxvB+1jNPmLUP6AwtEWmvVp6hf/Q20VpQjge6p6VX8OhKHjkTVV0fotzPOJw6OT7i10QGM
dOURFasdNl6/+zHdnGdmHa+6sLq8snKRP5K8fAm6sO7IS5cuYf/+/Thy5Ag++8xrOdV5ua7W4Mqa
Dbj2i61oq62Dq+oqrv7sNVzb/B9oq4/0bu1IFZkXn3mWPy67LL+6LFIWenGB0gLBSzyjZzBcTpc/
hWdvmYxocrweXb04hYY5moHy803zNWS+aUYhfRxZdn7G8r1pZaMNa7k2k84w/JN1TUtDL6xHVy9O
D7c7x0lZeuVpvs5KXDY44rpXRtX5sfGQ8WlzFYMhZZqYOxRZRetFevrcYtivHwXX2eOE4cWRuCJO
Isb8SdaJ6xkZDr7pwb6Hrlf97NOz6J3bF/PmzfNTBFwZtRWKm55anHowIhOGYym6nfSr6fH933zF
K+8RGTVqFB555BGf/BjHlpGGlOsHo3rbm2gnxtsczaj7zdvo/dUvI0FnAl/mF6+nXvllGWWZmRfp
l2la/rTp2jDDq3E5XYblU9JUp8k47VMPRtKReTOO9Ms04oJfr8f5pys4El6mexCi4vHWq9DIeWsv
8yV5lDRkWM2z9Ms0CSuf2nRtmOEkrjZNxhvRkvHqJ9PQ4nFY0pawMqyGVfv10tW0Zbqk112f6jLL
Mko5BZKBHh4da0uV3/3xQVrSj4673TBu2gNfF++MYfjHccJwPPNLJN08Hs4zH6PmuUeVngsxJnnx
0KTTbuPh7HRgIU9fJNBxIjY6Xdf+Dw8/TPs0WsT9scYMMHMqLaEDKAvESbJQOmB+Uc00M8+bTqqo
92Dk7DQklbNkAZzXanB19c/R2taKrBnT0HvuLCT2yjJC84t31FThSl0T0rJ6Izc70y89kghv+X0V
qh9N6uM1UWSqXTWHRHFOqjB2TRzdxktxXgpauWrDXkjFxzyZgZF4wWAlnLoqUBZd2nnfW/B6q4aV
hdaLCyTHQGmSppmnOl9Jk5/q+EB0zMIFotGd0tTykPI0Uz4/PG4P8qcmoG0n2rAKNnnkBMVgrCCD
0cjaQnGkWRSPxJVPCRCjJx8j4qI7l7inkcCnh7y1fTt+/GIpXv7pT0SFUwvBy4PXYHh9SioLWP4k
vD4Nmer75B4Gw/OYWUNDA11gbjBQR2eftBPD7bSdna05H6JFGfsSMwq5KrF52QxMf3gW5s+fj1kP
P4SCgmXYX6nci15/fDOF5+BoiBsm64++hAceeAUNbhko2XuHpfTYOb71a/i7v12Pqx7eq/DSl6di
6tc2wX0TL6FVoWzqVPzjG5+g7s8bcP/9D+FwXTvqPnnNh0+Wm/dXh21zCjBj41G9bP3i5DtTN5BQ
3psk6CmGjOjUT28rC6f8EidYEb3vxL8uaNNClrm7rkX+3ky2nWCF7cLpQvYRyFNbHwQ9Vl9mfway
c535BDXLH0V7XaNydaybHl8jq/6JfAxoRDPaSXsz6M4+OmrKjuQUOiL97nsmY9CQoXjwb6f5KX+9
jL3NTklVV3opRHWF1qOhjktLSxP5Mp0BAwYKvzqd/a3Uw6h++Rdo+egocr71DeQsmovGfQdRs+UN
tNUF0/Q12LxkPjYdGoniNVuwk4bC3tyyBvPGHULJ/KdwXLEb2ixNhVPTFIMngYOVn9NvGPd3BP47
lEsLUXUcv6ujqPO/x19Ucbso6m8n3IC0Yffie0XLMCJLaeTG8k6TbJh6GtMxgU6VQA/fCFPKxSg9
vvFKDdbj36jehsq/pKPGk/nppYVUflXXTtKXNM3QkXxI2EC4gdIkfmd7Splo+ZLxfmWKUJ6cj5o2
z2eoFbv0s4KXfn4qCl/54GYa8r04yWBcWz6L9FqDD7wHR2WQxNwJI8fYuWhkp5VHQ2hEytVCp9z2
6ZODrzw6G8OGDRNZS+ZD4kMleDWeGVp9+vRBZiaf1W7HPWTA5EtV47Y1NMJRfhq9aEiqz8KvInfR
fGT+7f1o/PgvaKPhrUCu/ugb2HQSWLrlBUwZNUAMC2UOGIU5z67BtHzgZKXa6FRhc+EclO2t9JCs
L9+BOTNWCOPiqjqKMkovKHgABXNWYOsfygEaHVPUkAMHt63CjIICSi9A4Uu7cc0tF3VZUoffinzU
4cPyKyKPi3/ej7qscRiD83jvL1Ui7sqJD+g5DrcPSYWr+hR+u+cwrjYpuXgYI0/lwW1YNEPJb9GK
72PnecAz6FZfjo3LmFdOX4TN+71lKt/9EuZQ/P33348Zi1bhoLvHJWmr+ZVxPs8AH6mBcQMg+mQQ
aoDpamlrw/40jXiV8fKpxtSLk+nqNL16LOFkmgyH+lTno8Y1ilfDsF/CqfmQcVrY7hpWl1ftV5fX
KJ6UlNBTuulu4yCMgkrBy7Ba+RMZH8cGo+GV5WivpcU9Klw1joz3xPlQiE3AnpiMtNQMpNG1r1x2
209W/wSvbHwFr2zY4KlMLAz5YzakXwpJq744rIaRflmEQOFevXrhuuuuE6D9+vUTT5mPxLdl90LO
P34dfRZ8FTy/Ye/fFzlPfA05X/0KbGRwArnTH/yeFPtsjB+ggUodhaKfrcb0EWr8XNxyUz12/WSv
Z6jor795DeeHfR7DU6vw84VF2HXmRpSsWYeVM1OwaeshoD+fM9+OE9tL8PTP38eMp/8N//bsQlT8
+odYutk7VCRl0J4yBFNuaMfv3j8jGProv3+HW77+dSyYnYVde4+LuPL33kX7LfdicGI7nI1ncfTo
e7hKo3LSMS3n6d9g3tM/R8Nd/4SX1/8Ekxz7cI7i05L43V3D5icWY2vlHfj+T36Cpx/tg00l87Gz
wgFX5U4sLt2OO5aWYsO6lbjr4u/w9Lxfok7zzjkvybM6X/FuCFadLuFEmgSmpzpeSdPWHBVwRF6F
rloJUu4aitxC5c+bpOUxeBkUXInnpeQbr5cu49RPxtKG1XEKVf+/ahzpl1DBwmr6WlhtmqTZVZ7a
8siw9qktjzadw4bO3VY43Q+Ph5C4t+H+tbW20Qmxyk8bp8Zlg1G/YTmylm4U8BJWPiUN+eR4YUAM
mYxeQkpqGvr2vw6ZvfsiI7M3bPk33oycnFwMu36YXy7+TUwB4fhoOZ7TGD9+PN1Bm4QDBw6ISXkt
bVtGOjLvvRv2frmepKRBA5D+hTtpj4b2ZF4PiPDYSacDyaANlCpnXIJb/34BULcJRy4yeCV+s6sO
M+dOhr3yMLbTMFLhmqcxaVQ+xs94CqUzBwGXGK4Gf3jtQ+TTeTAzvjAcw+/8Bzz3eD5ObtpHsxNa
l4nP30d9jd99DAcuYi/Znb+5bQRuvOsBYM8holSDw5TnuC+NpmlwdqIASNKQObFvG8VMw4tPTceI
POo5vfAqCiimsQXUK3sbm6jX8fjTc/G5oUPxhVmLMJN6RNveOQG4jU9tdSPJ83MofPVVlK35IiLZ
6aJhrcOCSjs3qrWSrQDKQIJYT0sCbgnwh4jRT1dIUpmregqyd6B+JqRneNDZYNSVFSJ72Suwpffy
6WWocfz98anLCbR6qp3Kw3eF20lP21NSkkko7XA5Sdu4nVCpqr6TPDokViyOHj0aY8eOxeHDh5Gf
n4/bb79d3Fsu+YnsSV2quitoICLePgWVhCbHNz6zFgMWFONeVQb2IZMxO2s1Xn+vEpPH/RH7aJho
w63ZcBz/lKDGYORARZUzyugHHwS2k9zqz+IDmqg+uWkpHtrkK6UzNPqV681Y5DTk8/cB6w/gT0cz
cYjoLxpCq6l6T6CRrudx8Og4HCCoOZ8bKGAN//DrmjYR3g5UbwwmG/YxRbualHe5/slZoFXfHpdP
PnveVJQtOYHla0swXyQOwuziZzF2lAesi3p85d5FC2Gx3ckkELDHoccrG4sgV1ckZGWg9wv80Qc4
K2jS+7kFyF6+UTEYHBkEn0GE47zi4Ox0ax9nRWsxxVNowES67lUu99QaDC1P8hudn+pmqg1r8QKF
eTJ8ypQp4F3p77zzjlhBxXHXrl3DoEGDMHjwYKTSrm/f4YdAFL1pw79ACnrTeuw8SkNAY7M9Ca6K
Q9h66BCWLCIROD3R5MnG9CcmY+vmX+HXFUeQNe2fkUcgjqwcSjuGCzRZPcLd4blw9DANfY0la3Q9
7qIv+eueeBXPPjgADvqad1WdwKFPXBitMRicU2re58lUrEfx8mPImlwMshlE4ybMzK9D6fISCkzD
5wZ4jRMna53oMLx7DPVF493GsBUt7umZVJon4smWkm2/wqQMujyFSF3484e4lHM9XDUXkDbucezY
U4T6qgq89+ZqlK5cgdvHbcYdOrxq8+2cYbO1T11jO2dJLK66tgSU4aTAZcj69o+QlDdaGIxrJV9D
75JfiDBjNX98QHzVB6agpIohKjOAEcKkJKeKkSAXTYa30lAbXQ/OlzBRt0NuCJBWQZ0R9zqU/0qs
G4Yf8scJ7mgFJsS/Q2kYZSotM2XDsHv3buzcudPz43B1dXWIFBXw1BFTMY8+sbcWfRM7jlSg3uFA
VflefGfxWgKYhnvyvAMz0nYMuGcmxpzfhfW7zmPBjNGCUGreOEwmX8nzm1FRQzSO78Qza48pcxpk
aMbck4V9pT/C/grq0zguYNcLT2LlK58oTGj/2ofg7nEUScNd4++Rw1CZuPO+MSIuy6cHoSBL3jjE
/uETqZdTtxX/uuMo6l31OEKT8FuJHvWrYB9yG/Fah5Kf/gYXybo0VH6IZUtL8Npf6+A4+59YPP8h
bD5YAXv2QNx0wzDCUC8GoGCXdMFqn2UwuuRr7WpMcy+BP8sNfpnffQFpd00VBqP6n78Ce76iX9oa
atHwzjbUPPO4Ia4fTbM9kghlyMNTdhrn5xbURmPA9sQkO1rJY6N9D4GbHafKhkd+GtLyBN1MydRw
eGTDdeuttwrjxXMb5eXlaKQzp06cOIFTp05h5MiRNPfCX/uhumzM+fEGYMUzWLt0IdhUsMsaMxNr
nvkGuNOgqMx0kCgUlzoWs6dlofjd6ZicJ+dMhuDb65bi3OJSLHx4k4DLH0PdiyoFZfyTtIz30pMo
WfiwEkErolau+weDuYJUjLmbTNChcky61TvANPzzf0PDVsfwwMQRCg3PXxVvZBaYz8xRtMpryWco
WluEfbJQBJ+WyYUgXjcU49zClXjMnTioYAmeeXAI9UrmonjmX7GyeCGUUpDpLCzDrV22l8FCiqTm
Mb7lLAlERwI8rxaoB5Bx/yy0nP4E1UVfRjsdgdT8h9/T8tprInPnkY9CYoLziodr5+kLOm6qlY5F
5310Cd9/4YV2p6MFTXRW+g9/+ALxwMbByLFEKE3Md7j9btBo8c9jiGfPnsWxY8dQUVGBCxcuEG9N
WLJkCYYPH27EmKl4l4OmmRvo5il7BrKzvT0Mf+QabJzxMI4u2IDV0/M0yS7awU4XkaRm0vJdTRIF
XY56MTzFy4jj4lwO6j25kMrLlv0yVHglZpGpZTYgnh8hK8KSgCUBExL4091DMSDZvyVK1MSb89FG
RyeJZbXuyIF7TwvfhSmh6beLtEv7c3/kuVZzjs/5y87OFqM5PKLz/vvv+yHKKQDWwxMmTBDpY++4
jz5UU0gP0+ZrvrmPDh6ghDYk0o7swAaDkn0sA8EzChFXR8tMKUUsR+MnO3U8h40mmBiO94z07dsX
ly9fFr0MNhq8nyNSZ0/NRm4gW0EZ8L6MuU+8RIM7Y7HmgeHCPioWnUvJKymSkJXlXcukLQcbkyxh
VH3LqC0/l0WLy3HSmYZng2Bon+xiD4weLSSlgYsheVDDyDjmRR3PYXUahzuT8+eVuVNqp3+autYq
pZAw6jLKOHU51enqePZr4QPBanG1YS0tdbqkq4aRcQxnFK+mYfljIAGuVv5Vy5NR619Oevxpjz5G
w1NjPeGsp1fBdfIoml7f4okL6AmQT0C8EBPb22hjn5OX8tNpt7yCqo13J5Jr4+MLw3GsIBWt6ofN
FVddkf0AAkRk0NHA/Bs4cCAdyesCT4zHw6XljMKCJUuRP/EejHIbGFlEty3wYcNbRjYoPkmegLoB
eyINPcZ0DFGsBB8lKcXhfW/+L8b73nwVrMSN1lOdT7RoWnQ6rwRIr4qd3GY4zF78fR+wjAdmAfRr
3PJLn3ijAOcVD9fOQ1I0fWCz8T0hdGCh1PdtZjgQbc+/AUaLcT3lyqum2OmlcbzaKOnBqNMZPpiz
547C9BmjBF3GDURTnWZkMNT5CV6kJlMn+PjZiCsylrzLfPgp43xQQghI/EA0ZT4SRpKXdUWG+amF
kWnafGS8fMp0DuvRUKdLHDNPiReIpjpN7dfSl2mSpjZdG9bCyzA/zdLQ0pRhiR+IZij5SDqSvnxq
85Hx8inTOaxHQ50ucXrUk5uvyR7A+Ul5BqLh9m+CiAkQgwxCim6j8/7s9iQyGkk0p0G9DZ7Y4GVU
+pM3GgnEiUl1ifQqpl56MDg1Tiz83FiCNRjmkauDeLLx6GouBJaDvQ+ZLp8dJQr53gK9O/m+5NMs
r4FomqURDlwkMg2GK9PlMxz+ujNOUv/BaHaRojRYPeWNp8YUFIYkZQDDeXBe8XCiQ0Hs8iGxfNKt
jbsefAETb0/3d6wl9DWFukHoVSD5VcppMl2N45+XN4bh1LASX0Ko02ScfGpxZbzZpxpfm68xDX0Z
GcOrUxT5qOWkTo22X5tPIFlq8w5WSrXstLgcDpRXMFw9euo4Nb7596amYOwXn046H0xSltHOT48T
mZdMCyRLCWP2qZadHk6g9EBperS6e9yQ76xAA+nUZhr25+Wp4f94ykAfn2lzHpxXPFw79S5aWhpo
AdBVNNRW0fAU2wo+G4WYCOyo1ai+joM3FG5lwdRM4BwDpXJl9fIQ3Xy8dBUOOK/ALnC6Ft9L33/+
wpsWOMdopGr5UtOMFR8sSm816uj35lNidUD4/eXj5VcrH23Yj1gUI/z58hKPJx/eXC2flED2vV8E
Sjeg8sXlaDn/mYzWeXJdMtIbsp7ppycPGkwG4zmIvHQoRzuqrdVJS25baDKclty66JYf7mnwr80p
9hjr5icrqbex64J1YCQLVwo6MjbUjU6WOzKKrCQV3vzpcY9KSZfKlGEkPD/9cSLjJhg9df6ckzYc
We6E7fOaovfe1ISDlVG/DP68yPegR08vTsJL+jKsBythzD6D0eB0mR/T1IbN5mPBRS4BVuaRKXTZ
SLhOdrxzOptpjwaNSFGPgzmyPTi1QPQyAt0Rrq6MXASukPIni6SFkfHyyfBaxzjyp07TxunhquHV
fi2uOs3rly/FG6Pnk7T4qXYyXh1nxm+Ep5TPOySnLq86bxmvpRMsbIa3UGC0+Ulco3iZLp7+1UBE
m8L1IeQbUL8iSYufaifj1XFevy+sN14x6lpa6nTpN3o/Ml2bf7CwxIvWU5ufmq6Z8qnhpT8QTQlj
Pbu2BJy0epUGymhbhnLclJ1feiutw21RHVioV0SjSsUNJZw0vTwiiQvEhz9dA83lD+iJ4TLq5SEV
hQdQxxMung6pDo3SsfuG/JiRCyPrycaQaJgJenn48adjM0zhBeHJL58g8B2RrG6/ZvnVk01H8G7l
GQcJ0EhUMh2Pbqf7NGykB+0/Xv1jjLhhBI1VXYODzmViJyuRrEAizL2LGPOnzTeU7LS42nAotCxY
8xKQcmYMWV/MYxvUtTBphZJvT4e13ltnrgHyCyZ6GjfQSFIwSSSn0tUUvfqIi5haaKjKPiL/RmT1
ysKVy1fESbLBCHB6OMrBDF1ZkcOhL3G1+YRDS0vDChtLQC33cGStxlfnEg4tNb7lDywBtdzDkbUa
X51TOLTU+JafJcBGI3oGQ8q0vj68g0mTU5Lo6oxm1PAtqcSaPYGORU+kE25T04KcryFzdj+9lUaZ
zNUkhxWMpMJJXOZL+sNioksixaaSmRFFpLKW+D3zvZmRcGxgpNzDpS7xrfcWrgT18GQPQy+t4+Jo
QIqW/9IEOO3RsCelwE6bw5VdfvZE01x5DQaj0GQ2WcXo20XT7PgAysrsExnTQMcpbG+xOov0vRyF
6ov/ewuVQwteTwLWe9OTSrhx3I47n+FISqSd4MRWMl3GlMg397VSt8PRZKd5DPNGI1yRdA889Uvl
l9z1FXb3eC9WKSwJdBMJiO9Q8afTFCiRjBmfdEv7wekfO5odp1Gd4M5APxpEB6fXpSHCLbUZQXdp
wVjMWxKwJBCWBNy6IVzVElaewZFcZB/owiUa9qf9fHw0Ot//yhbDZqanoafvOlkBg4sgEggpgEgK
HQluJLx3BlyWX08uf2d4BxYPnVcC3Dakjuk8XPJ5U3yzK89rsOGwJaekiIljuvc1LC6jMZsReFy0
8wkxLEF1SyR+N2bfj1m4bikoq1CWBExKoPN9VKXSHeGp7j0afL+rnWfEuTnbQ5gIN1l6U2B8m9T/
/d//ibszBgwYgMGDfU9u5GEz2j7IJs4UvdgBhaP0JE64vDN+uLixk4RF2ZKAJYGeI4FE6lDwfRr8
Y3Wk9DlINyWGYTQC9xDMCfXcuXN4++23kUI9ntGjR+ORRx7xQWRboRgOn+gOCLDyDlWJSxwtu+aM
iSi353IsptWZnLkyKByHAtuZymjxYkmgIyTQudp6S0sLGQy6wpZu7RNGI4Ev1+CJDo9yiq+QmmnD
CG86uXr1KhkHqVzUPBgpXjVMvPzBXibzr4XRhplXGacur4zzlsW3c6VH2wsbX5+a7/jmbOVmSaDr
S6AzteXg0nS2NJO9SERyShrdqUFLbvmWDxcdeduuq7CNCUajl8HUuYfBtNhgNDTQxeVkwGzcDVI5
RXmGKej6o1j0UBG8N/NKwlkofXMHkl4rQFFzKfYU3SETVE9vnsomJk5SK3e18uR4dZqKjPBKWDWM
2q+F53CwdD2ceMd5ZRTvnK38LAl0XQl0rXbD9y2107HotmQ73RFOnpZmB2xJZD86wKWnpwuDwYaD
5zSMnDJUY5QaIN5drMmFZfjmuD5ockrYJPTNBBomF6MYvvMoEoKf0lj4q29pBNTQgfxMgXHUeP5U
A1HoHGldnf/OIUWLi54sgS7W7mlYKolWT7GN4E1+dpeLehmksJ0B7tPQvt5o9TKYbp8+fZCZmYna
2lpMnjzZcIhK6W1oOTEXbiSwG0aOQu4Af8N44cxBHHQOxZSxA1C+YxV+WjEYw85swq5jhDRoMkp/
/C+4I4fwmj7F5h8+j037lD5L/uRv4Jl/mYUhznKs+qc3MGnR7di1tBSVs8uwecFYA8ZkZWHFK/0G
oJ062izvloHp1K/RYs6SgAkJ8Mm21M9QRoQI3tZQ3yAWJnGPgx0bBPVPRMbwT69evcSKKf6i79+/
v4HRiIyBdELfv/ttHDy4H/v3828v9h+tBF87VXeRjMb5WpGBs/40ju3ahDNji7FmzUoU1O/D85s+
pLR2HHl5PhmMHBSXrcO60iI07V+Pl96uIH6bcPrkHpSQwWgqmI2vT7xO0Ar8x6zSDUylY1JD4Z1h
5c8st2xo1MbGLJ4FZ0nAkkBMJCCbIzdluhrcfu1qNZJog19TS5MwFtpM2YBIHG1aNMI8pzF+/Hic
PHkSBw4cwMCBA5GcTBsOo+jSiNax7atRvF1FNP9xvPmzWRRBY1RIUhJaqE8ybileXDCFJnto2/yj
I7Dn9WOoKfo8ciYuRfHU8ZgyqjfqrzpwC2Ecu1AnDC4j589ejdWihxGKUlWy7X5/ucaEKgdZy0LF
i5/0+MOmO7hojhR0B3lYZQgsgQTQoba8+Zvmm9t5o9/UwZ/CSVf5Xb7moK9mPWT/SP8YPbzgcbLy
8lLbsWPH4vDhw8jPz8ftt99Os/ThbTbUy7WJImeXvYkFY9lAGDvueWSNGMSrA8THrpONCOiQLooZ
ODgbrz//CFbKGXUSQr7btjHUvROHM5bKSSl1XiWoYjYG3p5e/hiI1CJpSaADJSA0GXUi7M2f/Qm0
DBfNdTQ8pavfVJH6ViXiYqSlpWHKlCngPRvvvPOOWEHFcdeuXcOgQYPE8FVqamrYQ1es1BVLYIJV
OjJeWAxVsYFLWD3/X/DxzGJs+/Fk5Ka6sG3udOzyTKoTCnXbfJ0PAd+kLhWSyp+ZDqVMocCGSrtL
CdBi1pJA15YAHR3CpxQK9U/qQHxUc/OmZbjBHc9Gx8hwDB06FFOnTsWePXuwe/du0dOQRmP48OFi
kjwnJyc4jzoQPKdR/uePUZGWC7ruVjin046hN+YpAZ+/aiXpTnBcxWnyDhnUFylw4Pje17DhPM2T
N7M5YuokFxZit3RcMJZJKAUMBbZbCs0qlAkJdK5LFUww3FNBaAuETRgI9+khvMnPlMGQAouR4eC9
Gbfeeqs4GIvnNsrLy9HY2IgTJ07g1KlTGDlyJMI1GjyncWh9Mf1kIfg5iPZpbAanSScsqFCOitJL
SqZUHtFKHYXCJQV4cm0RHnqJwlnj8MC4LOzZvgr/++gPyGwkIJluJjHvQlXC5inHBtIyArGRaw+n
Ss1AGA7WKZbrtBKwJZJuc78jntdLeP3xge0tzgRcqXWh6I2L5hgXH+Pijzl4Ayg5p6FO5rizZ8/i
2LFjqKiowIULF9DU1IQlS5aAexwd40TtBpwO1NM16pmZdMthggsN9S7hF1VeCJVlotcAjOI7pjTR
y7W7lktfQtZEuL5cwosl5eOuPtE49DQ8HnoWFp/zl52dLYb5uS6///77fgKQdZz18IQJE0T6rbdN
RlJisrLpmvDsJ67Q5j4ajq9toHErs471Ir/wGDhmetiwYejbty8uX74sehlsNHg/R8c4d0G5zPZU
MhJuLtrtdMiiXRpgigwmEJmuZ1Q6pmRWrpYEOk4CMVQinkKF0ubUsOy32qkUIxsQvkfDlpAihqns
Nw9KpInwBFyu0U7kSpSOeWZkZIiTb3kJrosmInhivHO7UCpZd6mUoZS5c789i7v4S4A753xVdPSd
uxfjISwNgicigEfCujkTIwgBwHtAEp83lUDzGHyXBovDTuKlN9dO8xqxeHmRS5RXTXW8Y9nIyuT2
usXFXWxvvVLBBGoMDCYOiOycMu94eVsc9AwJxGZgittkNJxopqLd9+x2yuYzkec1eDCK9BbvEBcn
3kZDyN2HBlcX+ZMVRj59S6lvMHxhtF1dptx9nJRT9ylRKCXRrxWhULBgw5NAfFpRtAxQeGXsHFj2
RNrq7DYUPFRFN2uQtQ9hOqNzFCOWXGgrozqsryL8K5YeHMcp8Sx46Y9lSeJDuzuVJXSJqWtH6NgW
RleQgJwc7gq8xoLHFBrtYZ3lbG1BM51VSDO59E1NNb9nCYabuqLAzQtZpR5CRO0pslWMoXmJWpCW
BLqKBDpbG45nW+M5ZT4ava2tVYxQ2f/3Mxf6pCbgYiebCI99ZQpmOKRlYDiVwfBhTIHxDlH5JPbw
gJSZlGMPF4dV/ChLoGfXKzZi8TIcTU2NsNNkuI2vfSWx212t7Th5pQ2nLrWKb2+1KpXNnt+29hWp
06JcGzoZOVlyWWIZNmJTLUEjmO4eL2XV3ctplc+SQAdKgIeI4vDF2konoCclpdCxru77NO4ankQH
FgK3DGzzfE/rNXn/OLfy1OpQAegPHb5omZY2k/CpeTGNaHK8Hv9G8F6KHjzxMjneDI4a3/JbEoi+
BPiLtLMNr0S/lMYUtS1aGzbCNAsXK3wjujI+VppR0lc/2TYl0AqqJDo+hE8AVxytqOL7uv2cTOcE
lmKoTuCriXgJmOteMW44GXvzia9PW9ZO3mCDiJYXRSrLst1SZHh3EUVFUhVXeZ/yfcmEIBnE9+VE
lFt3Ubzm2l1EoupQZDF006EcxDFzkz2NVr8DVc3zaEuigwnpmKckurIiOSlVObCQ0XktbkpqiqKf
ZXvXoxuuDuCvb43rfpXXv4ws0O6ibDyvz10HhP1QFdnXaEhoBgi30kganePZXd5j92t3mvqho2s0
EN0naNJocIHr6+vDKnd27xykpWfC0dRCK6h49RS3aRIyf0+Ktq1SAro5hKsDtJ+lusTjFWmmEGZg
tPwKNaqNjElYbIuKkS6WypGVi/T7FCKgaLRMSZlo430oWgFLApYEOqkEGhvq4Wx20skcbUjk4Slu
/zwlnsDT4iIQQ847jeEIpsCkIOQzGLxaZhJW4qrTjP3KB4O+khYU3Qo8Hl+J6jzUfubeY0S4vohd
7cZlUiqUlEcgOCvNkkD3kUDtod24uOk5OK98FpNCJfUdjAHzlqPXuAdjQl9L1EHTFk6nUwxNtdNx
InZu0mLMWgvZycLtxHRbYxMSs3t5OGt3ONBGa4gTPacIepIi8KiVvSKd4MpPjRNm1kTC6D0I6u4u
t0dph5lN9NCMyszx0lBon9HLvbNQkjWks/Bj8dGxEmCDcaXsCWTS53hKmnLZQrQ5aq69IPJA0cvo
decD0SbvT4829LXRktv2JK7ttCNcOUeE/GbGAaUO8CdrPkb5pDYP74Z0/PUkrr6yBS2nz4gYNha1
b72N+v/8b7Ty1YMhOa3C47D8SUKysPIp461nYAn0LHlpa1Jg2Vip3V0CF3/xHNISyWCwPuWTNmLw
Y9qcB+cVD8ct2kY9DN7g19rqouEpWjUl9KXZtm4WLsqlaW1oRMOed9F8sgI5Cx6Ds/IcrqzdiKwv
TkFWWIYoUHPXFlIbVheO6ch0NU0Zp4btbn4uo7rM3a18VnksCYQmgZbLnyE5LTHmG++SqdlxXvFw
3iFqPnKqjYwGz2q00Fg6G49gjvVDDHWhlzmFEfVQTNrN+ej92COoIkNxeWUZ2qprkDzyRvR66Euw
JSUF41yTLguhp/BkmgZFN6jFl0o0FBq6hDttpKeEYRnqTlssizFLAtGRgOxZmKSWNm8Z0h9YIKBb
qz5FXdnjaK0oRwJdDdGr+HXYrx+Fqq+O0KcWpzMDuc1LjcY6Wgy6qZWzPneqWKknJRVVknmvVD0K
Bi8Fq6ysxLlz58QtfcxPEhmCfv36IS8vT9w2lUg3TmX9/VTU/vdeNPzqLbRlZeL6pd9E6i0jzWfr
BykLIQvlB6ATIWElrhqE0/Ti1TBd3M/Ggt6P5SwJdFYJdHgrNKkC1AaDZZmYOxRZRetx7VtTkD63
WBgM19njuiolni0wwUZmQmRIf6jt28F3L5EiCJkJRjApHBaIkaupqcHevXtx+vRpVFVViQuX+L5w
tmhZWVniFr9JkyZhSJ8c1P/PPjhpTiP9vsloralF/X+9g+Qb8pAyYniEiowLEkwC2nQjARjFG0mg
a8V7PjDYcLABsZwlAUsCHgm007FMZk8NT39Q6WF4kMkjDMczv6RRlAlwnf0ENc89akiP84qHS7In
IpGHooSdYKMRSRdH6tEwea+rq8O+ffvwxz/+UVzvevvttyu9CjoYi43JqVOncPjwYTTSRPeD/Qeh
fd2rsF83EH0LF8FVcRaXV/0Etpze6Pe9b8GWQhsTDZzLQZM3qYFWMgQqSChGQBqfQPQkjAGzXSXa
Mhhd5U11Qj5DaVOdkP1ALHHzDlMfSrIeg7GCDAbN5Rq6CPMxpKtJcDpb0GpLEqM/9D1PS27ZekRj
uCHEesDb2j/66CO89957uOmmm8Ql5kOHDhXXunJPo7GxEaNHjxYwBz/8ENnnLuILd9yKvjOnI+3O
29B26y1ovXqNSiBOd9cUUxV0HMXXphfh3rI3sWCsvOBble7pYQR7A5werJDSWKjpS389Ni96CJtO
Sjru+KxxKFnzLO4eEt0bCuuPvoSHilLw5p4F0Cu15Cr8ZzBZhE/ZwuzOEgjURqJf7rjX0hDnNPT4
c52hHsazj4KUYGCBRPLBH5iyT6qrzUVnTlH/gmwFjQHRRHi0DIZPNsEDLdR7ePfdd8Vw1H333Yf8
/HwfpGyaw+Bfnz59cObMGRy7dg0THnsMabeMFnC29DT0njsL7bQELJHORAnk0kWi9g50+brMGAtJ
PRishDN4ch0oWIpXH78NaHLCUVeBN54uQcmyX2HH5jnIMkALJzo1zbjnFQ49xvExd1J84RKz8HqQ
BLiysOMaFGEbEnTM/9Hmpldt1XHSL5+cE/vZSVqB0trbaHgqgmEjYTCWk16rb/Tkp+Tu/5fziofj
FVOtID3bziaDNvfJTKVgZDisp1qaQQiw0bhw4QKGDBkifkbgubm5uGH4cOyjIayWtFQaTWsjtpWl
XrbMDCM0n3gfe11zFC89W4rtx84Dg8ahYMhVNN9ViGdnjEL5jh/ipxWDMezMJuw6Ri9k0GSUri7G
HbkkJkclNv/weWzad1LQzp/8OJ4pnoUhlFS++yWsKN0Ooois/AI89Uwhxg9Jo5C/QAYNvgFDcge4
+RuCRx/Nx571LWKUsJ1ezLEda1C6dpegxfwtfbYYD45Q+goXD27D8lXrcbIOyC+YieGn/4Sbv/uv
mEHprqqjWPN8KfHN5ZqMefc6iJkR7nwcOLhtNVat3wNCJbKz8fRTCzAqm4pVvgP/tPE8po74FGu3
HuJUzC55AQsmDSG/C0dV/LQTP9+T/DgvYMeaF/DSbz8WeYyZVoh/KZyGXBGy/lgSYAlERauELUrZ
+tRcSDWrjtNyKtPkUzKgDrNf0lLjJ9DXP/8COcbT0mJ4J/UwGl5ZjrZaRWNJGC28h3aQfDxwEXrY
aLAhbGWG6CgRm5gCD3ocRAi5ypKaROFhKh6K0i63legO2vXd2NQkhOwSm/jUr0pCmX1W4aX5Rdh+
ZgQNCa1DCe3C33PoJMqvci8kAc760/j4t5tw9tZirFnzAxTU78Pzrx0WxI+8PJ8MRg6Ky9ZhXWkh
Gvetx9q3K+Cq3InFZDDuWFqKDetWYvylPSievwX1okr583r+8LvYf/Ag9u/fj907XkLR+pOYXHg/
SH+j+fhWFJHBuKOQaZVhdu4hlH53G9Gid1W5G48Vr0fjPYVYt64Unzu9HXtO0obHJua9Cj9fWIRd
7nKtnJmCTWwA+is9sPJtT6GYDMb4JSUoK12K3ENb8eT8lwiL6DrrcfLQdqz9YChWrlkD0vvYWvIi
ysnmODT8/D8VP8e3LgeximKS45qSeTi2azWe3lFOFC1nSYAloFUE/m3BX06Mo8XzhzITI6nIp8xd
nYOM06OnTdOGGUfS9sEnRS56G9zjMPjROI9IU+OzwajbQEeDfO8V2hBIualw1X41zYjmo32YDhWp
viEAAEAASURBVByQ05ftNEzVyte9tiORSk+KJxrDVDJvloaelGU6PXlYzE7zEdXV1WIyvKCgAOnp
ykCSBGsjC8cT4eXltG7ZDW9jfsN0rsoD2E6f2kv/vQST+hORUc9iyf7peE0y20LGa9xSvLhgiuiC
JT06AnteP4aaos8jZ+JSFE8djyn0eV5f1YRbCP3ji0SM7iJhV1tNt1v1uxOFr76KaecAvRmKZC7e
sa0oKRYonj/V1RfRhDwk5dyGwuI7MXXKKNLYVbhh2CCyB4riP7H31wQ/DauLpouv+RGlK/G7hxVC
rsrDolyFrxZjEnd9Rj2F0vMfY+nvOIsa/IHKMGh2GZ6aMVbk+eKGFkxduBq/PT4XM0RMFlb+6z9i
PHdohhZh464y1FK57AH4AcmKBl1xrRYYN+HL2LLuNtRmDhTUrD+WBHwlEEQZ+ALHJKRW0DIDvTij
tECwEkc8hcL3idENJKhGSYTBKCtE7x+8AVs6HZNktgfBecXFUT5kOfhfoo309r+1/BxfSfg+qWJl
2CWqPEhJ65SN92H0799f7M84cOAAxo8fr2s0/vD/2fsWwKiqM/9fkklISEJ4v5Fg0IKCVQpCEVqR
iFTYXUUtsvwjVKRgKV1oLS2m1ahNpdRu6NIoLeKK1Ea6LbEttJTiUo0vRKhrUKwmEiUSHkYIeU2S
SfL/vnPnzJy5c++8ZzIJ98Dknsf3Ot8593z3vF98USzF5eW3qXTBeTjOTo0zDexgOH3Ws43s7EzF
xBnUMPOYDSnEQb/MnGE0dkdBSne0ccOYQrqxYeiILDz3yG0oVNSUQ+25LXsuilZ9gAeKC7B0K9Oh
4Z38BzGR2n2943Y2kxrv0mVa483pVQeKcE/hBrz5r6WYOYAs2VuPYm7hUTcqiSccIWcu+LJ7+Ccr
G1MpgW9AsZ87QX8nYNxQMhhOd8WcOcAuOl7FfhbllL8vXjtGJsE2NIe0QHs66UYu2PgIlhsxTs6W
25JdE+c2H/KMX/wollc/guL8lShmyjQs96Mf/AfkgBhHWc7SgN+vRw8VyYbCR8PhAR+HAW7w6bXy
5RIy09H30Z0CpK2Kl9UuQ9YD2zSDwbF+8F20AzUuLoTQPFrvhiYGaNltJxmNxDpqhp5qexCvOWhc
IpJOljvTVP1OHkm0rHb48OFiWIqHp7hXoXccx0tv+clzG/qeiB7eX9iW2Z9AKnGex3uEs6P8ZZoD
6KUI2CIrroThtDPYtDQf73w+Hzt378X+/buxnBrzJmpvHXWnkDZlOUr378fzO5/EukUDUFL4EI64
eEg62jND9GHccdmTplCgHifP2vHub+5D0e5++Mmvn8ff/rYfv/tRLjrrW9nIo41+F/b9A/X05HDn
+Sq8Ts8U+iVl9Ke4o6ihxWQijeJq3j6MTjIEnb0ycQmFP64670rrpF7MaYqTsJ2dvXicUglrfm95
ZtOh/GxkqP9yqh5T1xQLXTxLw3LzQMNyq3lYznKWBuT7RJXqInNaA0vvDzVnZr+M7/wUydlXgA3G
+YKvCYPBYXYt77xmiudNLzb65SmEdr7elRoMLlkxo9xGjcYhx40UJwtbyB/VPzw0NXr0aPG77rrr
xEY+Zsh7N9hQsKBsWLgHMmbMGGRnZ4vluOEIlZo9BTOJQMEjO1BFGwnLSzeiuNI19G9OmhrZ45Q6
cthA9IIdxw48ha08693SBPvHf8TKpbdgx8GPYMsaissvHU0J5k1nTfV7qKiqEkNuFceOYNuGAoKf
ianZqXDQcS4gHv3Tk1BbVYYN+TS+lGFHI/WAxkyn0yzrf4OflR6mntdx7HjwfjI1XGk6kZo9mSh0
Ur6eQVVdM2qP/Qk/LC6njPHxKoMxfUEGDm36PnYfO0VDax9g24MPEu4MzB7PJwZrNIye3vLsJ3la
SB4yvaWrcc9thSg/3YIBI8fisuEUaTlLA0IDXKci4WLXHkVCWkGDewn8/Wvyy/juo0i7dq4wGOe+
/VXYcjRj0dF4AY0v7ETdD5eb4nrRDLRHEmbmxEQ4tRPiSZbLNZ7RmaAVEBsOcbdGmIy80Jm8Upd4
L8aECRPEpj4equK5DV5NxXMY7KZPny5WVc2ePRs1NTVIp7NYUvwsrRWIBn94KiGFdjVSs4/8ZwtR
uPIHWPbVp2msaAImZNK0ATfW5FzKID9/hduSCTODPKnjsWZVLlYXr8UtPBZDeytyp2Ri/64NeP+u
Hchf8D4K8+/BdmcG560pwlVyuIcJO13KAPKUFWNlmYyhJ+/TePI7yCbmzbPzkFOyEffcsksATJlC
g0g0Sb1y20wa0srDk/n1NJS1jknQCqhcGmKiRly4kfjOlnU4uZJwb9suYnJExrTUqV/fguVn78Om
1YuxSURNQL6TpzBvpAMjd5mRPG9q8uy6uwi5R9Zi7eKXnahEc+tC19CW1r1UCtyIgRXXgzUQStlH
wkhEgkboxSJ67z7mGtJnL6STut/FubV3iGW1LS/+HR31NERAru3IW0ExZl6xcNxW87UN3Ity0ER4
wlXfPNTZ0dZMK4dO4diOO1wyRMVwMHXOqChXEoJy7aAjzsvLy9HY2IjztBdj7969dF57IvLy8jB5
8mQxAe4SKlyPvQo7nngBV/77UkwawkakDjvybsO+64uwQ5ln8GSjVEKHHQ20qigjg+dW2uj6RIfT
T0GR5kAq3e2hGh+m5bkXxqUATvJw2goyB9G10w72DPAmdjtf0Uh+VB/AUy8Ady2bpTXMpw8gd3Eh
lm95HgudS3J5Vl7F9SBOAYe9AXaHzS2zHsAw7EmzhcqJ5WHZWN72lkYXTbMVcIZku2GkZzl2www4
RY7PclLeMyGn+p6wP1DHH72BwkYe7v+uG4UhKfoWwM0niQ5e7aCP4E7nslpOGXrguAA4NWuMGzAA
36lWBz7/8scBQGogZ86cEXvfuB7z7/XXXxcJ7Jd1QtZxDk+bNk2kjx59JZJt1OaRXhNphMg0d1Hr
ceiyyELyhDgbD37y8BQLzP6Iu9R+wHslWLe4BDPnzcO5l/6Mo/XDUHiLway1wpxE1PoQpDj3fU/c
+Crqs6VROJjKrTDw8DJddzeFjRA7R1oy/lZSgF27/4B5X+qHPXuouzJhOea5DAZDeeJyjOrYELkp
qym+/J40pTyykoVG0xc/K+3i1ICZkYjEOxVDjbK4PkRuf4/Gw50u7c7FNDzlXhSTef8GOCrL0fzc
sxLE99MHH9+InqnyXfaMdYdsZAQTk6i3QRPhCdzrMOtpSJSI9zg4o+JLwG3dJC9+8nwGZ4JXS/Gc
RuSdHRVHXkP5B2fQmj4C111PhyEG1JIKoRVxPEtMs9ac7BnPMdJ6s19L19NyplC+fbqGahw89Baq
zjSiX/YX8KWpYw2X9vqkEWaimhcuJ304TPJxja7mNa4F9SOcv0bCG13WVz/104XI8IHCupAi5unK
cnprKvc0Amu3hpVVGea5Zma2Ybw+8lRrO65+PfyehkpX6o7riOxpjP3cJDIayfSu82VMvJbUj+P5
cmre/UAFkSzrnwkKHx0SXZeKsZNm0S8YLvIlkMJ768Nfe2/MjelImsYQHrEZIzF1Fv08IrsmEHzD
0zVyWlwjoQHv+u6fqnxn/EP2KAhWVYDqqpmRHV7WA+QTHhM2FAlifwa3cUnk92s0hAKCaNfCFTA+
8GWGtVIRw1PCK0spnBdCw5VGhmlbztJAz9KAfE96Vq4CyU3y4BFo+bQGvWg/QzRdC01KM6/YOMoL
NVQ815yYRENVgTCN/FLc6Co0kDz5/8J3V3zNp8rMMTLMT+kPhDMtXXOTVhAkTUlPfSpgceMNJs9x
I7QliKWBqGpg5H0PoZH2lbXQWU18Kmw0fkybeTCvmDhusOh/EpkLHr7y39NwSdXTGgnDltuVWw+P
bM+9UILXibHBYG6+Vn0Ez8dD/qgEvJQRFS4WUUsD3UkDWdffBGx8EtWPPYDWmk+iInrKsBFkMB5G
H+Zl3qBEjjc1P0nUy+AfT1YEbDRkuxk5SeKNEjfM5g2hlqrCSFiOYyfDWqjn/1V10fNza+XQ0kCg
GmDDIYxHoAghwsWsxaFXnec1EmgSnHsaiXfPykSvZNnw+ZA+ZhL6kCHqSVIP3pk1N+gM6w1vJqpc
nWCWbsVbGrA0YGkgnjQgRqe4iUvQVkvabqejTa8Z1YkHnzkbT3IGKEs0v3ZVAxK4UdAEV3E9s6Jf
daQPs1HRDFSwPD35mIf0OqOwS1x/PPW45lysFEsDlgZ6igZ4bqYdnQl0LBE1AXTdK3DwAztOnXeg
pYXPTPXhlPbFB1TASfoGM2DEiAK6WkwdVfccg+9G3Kgh1XAlntq7CCzPUiZVJH8NugobrF/yC55H
8HkLVrb4gVfzGj9SBS9JYHXQiG7o9cSIWrTieko5+dOPeFu1RsYfqDjLzy+QCQAflMgnoyTwEVP0
tD36h3N4ic7OZt69evUyQXNH04dwxFzolTdiIjgJqZniotDCnFd3mXC8kZO4+nSK5ySKjqTOjCSI
l7j4Kc/oaKSnNEb+y8lZcT3UKOs5R+rrugdglwd6Sjn5U6QoBXcD5Q+cjhgyP0jVF7IoeWeR867w
xJffo8OUwnVBCB4uq/DxZeWXT6bIGpE/NV5yc2pMBl1PI1hXovPdMsNV4CyvpYG40oBVZ+OqOLpa
GNqY0UldjA7uZvAlTBGRR3xKc0Xz04hGhFkkiJjJ6RkvckRR7n0q6sukDkFFQiaLhqWBeNaAfL/V
dyA+5e1qCS8c2ofT2x9G26fRWXKbPHAEhi55gA7IpovWYuD4SHT+Au6g8wE7EgM4RkQvk6w6+ngj
gyELz7Mp9sYMJKazrQ0dTc1IyuI7IDTXSfeHc0aSlAP+ZJr500wqbynNY4iGK1HS03N0x/sfDtDj
WmFLA12hAVmp3XXXUwqzeE+org7JXHSFHGwwaovuRaYtAb3SIvNNrs9Hy4VT+JR4dK59An0m36hP
jnhYHFTI+8BJsbzsNqAd4aFKwYUXqQK0v1+Jz556ls6i/0iIw8biwh/2ouGPf0V7q3abXPBySglV
KfnF8PdyqPDBc7UwLA1YGoieBuQb3BXPU//9MFKTEpBCoy/eN+1Ry0If7eH+mDbzOE28YuFoTIV2
g9PIVKJNbPCzXT4sGe993Bw4by4JfZvJcxoiTp8QOFl/kO2NTWjc/xJaKqvQf9litFWfxKfF25B5
0yxkBjynwvJxBlSnZkhNU+PN4NX4WPuN8mIUF2u5LhZ+al2ReY5n/bNsF4/rqty2nf2EehjUxAbc
JoVWJnxD9WfEKxZO7ASnM6dsfOo4nz/108UDMHtCWni8xZyGUkxG71MAHHgYR/2pKGl0eUnfxbej
5R/lOFtYhM82/Qop4y5Dn1tuRiLd/OffKfIJYBZSL6gnDJe7cdlzgn+OviE8efmGNUo1EsAozgjX
irM0YKQBrj89oA5xO+LMScyfQfYkUvPWo/8zFeKXVXQAiZeMFT0RpKWjz4/+JOINeyZ81SudQRUL
l0DGIokuX+JhKna2ZBp7413hR98PcPwt3LbOIJe8FKy6uhonT55Ec3Oz2KrOV8AOGjQI2dnZ4rap
JDoyPfNf5+LCXw+g8X/+gI7MDFyy7ptIvXKcAUV/UZwJVeHs18cxDRWGw57O2KB4wsRHSBaa7/zE
h6zdRQqpU728ZvF6OCscVQ1E9eWUZWzwPnEUzxsLZ5Auk+iZtmQ9eufeTc2MBpfUfyQy1/wK5781
C73z7odt1Dg4PnpX2ySh4MXa20lWiw4Pob0afD94J2wHK1rwX7trceozR+RkkToNgCJfunTgwAEc
P34ctbW14gY/PoKXexx8EdPo0aMxYwZdlNSvPxr+twxtNKfR+4aZaK+7gIa/vICUS7PRa+wYavOD
YCrkkvCyYOUzAKEFSLDwerrh4Otl19PWh8PhpadlhS0NXNwa4KbGzCZ18tc//w/gles9Z5mXIpMG
jELmD39NoyjT4Pj4XdQ9fKfW8/CCJB4x6ml00M4+PnsKtIpKbO576HefoaON+zqBOdlcBQbtG4qv
di0rK8Mrr7yCgQMH4pprrtF6FdQdYmPy4Ycf4vDhw2iiie45g4ehc8vTsA0fioFrVsBR9THObvgv
JPbvi0Hf+xYSfWxM5KtkbdS9ck/GcIk6YLe3013cqcJ6+pZUTVU1YF4zmCcx9VjT7LCTHHy5tuLc
simRltfSgKWBONeA/t3X2gXxl5P0yUHkxmUwHiKDQXO5pi4MHqY0DRI60Y72jjYyHDw81RHd1VMG
/F1R7e3teOutt/Dqq6/i8ssvx80334zZs2dj5syZomcxa9YszJ8/X1w5+N6xYzhIsEmTrsLg+1Yh
fdpkGqr6Cvp//S4kDx3iu3zs5fja3LnYcYx3Q2padpx+GSty52L+8mfxmShl1RC4RPTjsePI7lIc
OW20ObIO2++Yi69tK3fRcFTvxtz5c7GmtMIzjmQ7cNpXL0/PR8oaoxrjktbyWBqwNMAfnj57ETw0
FejPRJ08JFX3ABmMejIY/miZ0IhkNB8h0trWSsNTCWQ8qNcRSeLB0Gql3sNLL70khqNuuOEGTJw4
EX379hVHmfB8Bl/7ysaEjcdQmts42kRHnSxegLTJVws2ib3T0Peuhcha+G9ISknxybo3pbY6tN6U
veoAvra4AJUTlmPnjrsxOIy29x+bivHiGSPWWZjwpUzU/P1dyI371W+9IgCPvlgOaWZOibhcXDHE
s/ehp+jmYxkMvW6scDgakPUpHBoXGy43GOaNRgcNGYlhI2pc+enrp2mOy8BdDm1kMM4/sBAd9Y0+
cQVdbs1j4BJpQ18SrZ5KSGALFqzRcOctbFHZaJw6dQoDBgzAyJEjTelx+qVjxuBCUxNa01LJ8LLg
mkukTX1JWX39zmdwBy+FViM4qvZh0T2FaMhdh+c3LcQAQYYU3/ABtq3PQ25uLv1WYMfL1SLFXlGK
FesfR+m29c60PGx7+QRg/wAb8uahhKD2rJ2P9TuPCXj1z7gv06abmtdwQlgIO/6x/xCGTZkCHH0R
dD4kOQfefeUQkDsDQ8hfXlqEPMGfZKAVFfsqyNzYK4jPfE8+jtMoLVrjlCcXa4p2o1ZUOiqchgrD
fMBBdFY8hH0Hdrp4rCC8OlVgy38RaiA2jU7PV6zSMFLzJFc7+e4lMI6CR342GI1PPYDOCwH0MGQP
JAbKpYW2SBRVRZM5uJ4GIapLYsP1c355mKqJDALTMnJ22vXdxCuqKNEhNvEZwxnhyjjuaRzetxmr
7tmIeizAju/PQYZMpKZzx70rUVI9CYWbNyN/UX9sL1iK3VV2ONoaUHloF4rfGCXS1swDSgp+hgoM
xrwVa0AmABMWrMIdXxjsoiY9WTlfAK1Jw9vVNPTkOI69R4G7Vy1DLsW98QH3P07hANmMebPGw36s
BGuL/4xJazbiyS1FWDTgEDZ+dycaUgd58TlW8gCK9yQgf/MvsblgCY7u2YT7xZDXedN8wN6M45Vl
2Fi4G/MLilCUvwiVhPdHMWQnJbae/jQQbn2PF3x/+bTSg9WAs02iRoonijtlL8NlQKjHwXG6n8qF
DUbDkw+gz/ee8oLT48mw8v2skoqCXzMTSXwJEw1OBWc0fHTLgpWUT6Lkyelz586JyXBeaqt3HTRb
zxPhFRUVYhkuw9Olg3owv2HehXJ0159Rmcmgu7BHaSztFXuxvQZYfv9d+PyoUfjiwhVYQHA7X/jA
STcThT/7BqaOH09zIGvJENTiQnsWJs64EVcQ3MRZX8GksVqfxYmgPbLG4UZKf+29U3BUv4lKMhdX
jRyLGTOB3W9Qb6X2XRwiatPHDYCt/9VYk78Zq+d/gXpdw3Hp6GFABg+5MR8avlL5tHK/qRbnLwCj
pt2BZ8nIfHf6EOqU+MiHc/Qrt2ATFs6YSDIvxhKiWe8csvOQ2wpYGrA0EJIGRL+BDAOP4rDx4J/W
26AU2TNwPhN686esZmzYYNQX/Qey1j+FxN50TJIO1jys4YckbJBIZPK0zFDmfA+mB0k4GHCetxg8
eLDYn/Haa69h6tSp6C0U6abCRuPFF18US3F5+W0qrXQKxbE5yllUiF8uuwI7V9yCrasLcdXuRzGe
yDmatSNItq5eiK0K8Rzh57QbMU52S2zJSg+lDZza4uC/RnJlYRpZjV2H38Lhcy/TMFSeGA677Esz
Uf/Umyi/lHdzEu0sWmSVTj2Vtx7F3MJ3KM5ZEchuaM6h8EnD+MWPYnn1IyjOX4lihs3JReEP12Co
z3wAbGoGZcmj7zWakoP1tDRgaSB8DYjBEm7wlcWobEj0gygJmeno++hOwbCt6h1aVrsMWQ9s0wwG
xyr4AsjsD/OKgUtJTkFiEvcvKDc0Gd5lRiOJltUOHz4cJ06cEMNTbCD0juN46S0/eW5Db1T08GZh
bjDnTL+C/mZg4Y8LsXthPlY/tBu7H52P1H79KD4TBTv/BzPSHXCQRk69/SbO9L8EaH6D0nrp+jbU
UDvbdUokZ95Zy5k2H1i3CfllwILC8QJ6yFWzkVlTgAcK2ZAVUV8COFZyHzbtGYuNz5Zi0pAM1B3c
gNs2aMZMIInBuSThrTtVj6lrirHwwTacrvg//Oan+chfPQi/3zyE0k3ygY81MgHXRie49bA0YGkg
QA1wo5BAbRUPQ3mjaCdlaw1H5nd+iuTsK9BWRZPeBV9D34L/FmHGannnNUN8b4rUDBGvWLgU2s6g
Da0yt6AmwiMrIA818cY9/l133XViIx+LxHs32FDwXAcbFu6BjBkzBtnZ2UhLC/24E7l6CgOm4rF8
mpw4tAmb9lXDNvJq0Lc/Cn7xJ/DK10YaSlq/rgDPvF/P4hg4/nZgx88EnKj4ALUNcj2USHD9ybr8
Gmg9lhxMu9I5hDVgvBi2Yuozpo8RsKKzMmwQ+qfbUFv1Mjbk7yf71oJGFyUQn/cFn8rS1bjnth+h
/HQLBtBw12XDNaCkoPOhELe8F4kGZN2V2dWHZbz1DFkD3Etgo6H7aUNVCcj47qNIu3auMBjnvv1V
2HL4Y5aMTeMFNL6wE3U/XO6Fq6flCgfaIwk5MxKRDaG2BKmDjEaAPY3IGgwWhXd9T5gwQWzq46Eq
ntvg1VQ8h8Fu+vTpYlUV792oqalBeno6UjyW1lKF5zofgGg8ephi077UmfaQWfdi3cGXsHHjI5g1
9Zf4zpP5OEmrqhaXPc7JGJa7Cj+cQyu6eFEUjf27nXaHBk3HEO9UfO7GCSgpXod7av4Tpd+Y6AaT
vowczCCrUYkZuFwOcdEg1bT5OdhVkobJY7TIy2bnIadkI+65ZZfAnDKFkGgCfuW2mSilITU3nyKU
3v2fyD2yFmsXlzm5TED+kwupD5Wh5KNYpLnyYa+HXgcpxNrP5b4yF9azx2hAfVksgxGNYuWhKF89
gPTZd9JJ3e/g3No70NnQhJYX/07La3kdYyfajrwVlEj6Ya+gkIMAbm1toVEpnk2mOzUIL+Gqbx7q
7GhrRlvDKRzbcYcJKbWymYCEGM07osvLy9HY2Ijz589j7969wqDk5eVh8uTJYgLcmLTzEiROjIj2
HHQdIjWjtlRkiF3bRnnWeKos2YC42RvhGEvvHcv87cQ+A2nJCWiupxVWqelIpbPBPJ3Gw2FvgJ3G
0jIy9PMpGh13PjyxrZClAU0DxvXK0k6oGiB90v+3rxuFISnG3+L85iZdnoOOmpPaslonq6EHqsjX
iVOzxjhjAnucbnXg86+cCAyYoM6cOSP2v/EiJP69/vrrXrjyqlwejpo2bZpIv+qaL1PeaFiK5jOS
aX7DOHcepMJpCD0IGQZYSJ4QZ+PBTx6eYoHZ788JySImHjfAyU6WZkSpm6ZL4rFKzXDoEvwJ75XO
/LWeB/NIFX6myT/1BWc/dRHJuLg6Lx603HQ8oq2ApQGXBtT6xJHh1l0X4YvQ49QlPYRPvrJGmqC0
9vcqXfpOu3MxDU/xCIWm/8z7N8BRWY7m5541wvaOi1Gxtbe3EW9q52i6gBs7P0Yj+lLxvMWIESNc
ChkyhI4FoVaTV0tJq+dK1HvCEo+LOCwCTmnYkDAtUWUiRlMjLmk6WbkeMj4S8ruIkofp6mlGi5fK
1/LHTgOyPCVHfXnLeOtprAH1HXHqkh5Sq500zyB2hBsguz84NZ1nrfyRB1T6jQtpQeVCND37a494
swDzionjCXf+Mqb7wRPoIiY/RiMmInkw4eNDup+L1ovni66spr60pYfxRY/p6NMlvj7eF08rLX41
IMtTSmiVq9REcE+dHlmNMor99JMGgttalxPqFn9EVM2MbFdSSB43qZDQA0VKpK0G/AHPq8I4Oybr
RVmaGEkUqOQRh+tu+ePi8qqBvrWiggddnhK5u+nJt0ou3lRZnlIDVrlKTQT3ZL2Z6y558Ajau0Ub
/BjEuYJKHCvCvQLdiqpwwsyDecXCpfCmajIaHbQZ2NHuUIyGa82vuUJiIWBgPPQvQGBYAUFFkXRA
/A2BQhRKFCX/CbZMJb9g8QyFtyK7VANclrI8WZBQ6kOXZiDKzFXdhM9q5H0PoZGWp7bwYYX0j0+F
5b0bfIGR9mN/eD+mzTyYVyxcEm3so34GHHQ8ektLs3N4igbHmmt4qavZ6qlYiBYMD9mYhVPgjCvp
6Hn7StPD6sPh4OppyTDLGUpezfIn6Zo9Q8Uzo2fFx4cGrHINvxyM30P5hmZdfxOw8UlUP/YAWk5+
4mQXWb2nDBtBBuNhCF7hZ8g/Bc4y/TgXHdTTsPERR18cfQG/P1juHzkACDH2JXQUmqLk5DdPhkfX
GdGnOKNoP4JImd1gWsWKbB5CEMwtkKnPW3ZSgVP3Mk2GTYmYJISLb0I2otFSRpVoqPlVaUTVT0MF
Rk2XlFvmSSvG4OuNGz943KjmO0TiMj969OD14611OWchaHHDSirr8+WbcAX9ZBrzlWWjl6E7hLUd
7rxKlHoclKnEOdkf43Oj+mAJ3VURKacqK1I0zelEq2J7VxBzGYxTzCqrMXTsY1X51Eqtxsdeqthx
VPPZnfKv1kyt4dN0puYndlrsvpzCa6e43fFse9xl4Z3WfbVEvQunReR5jQS6WyPxqa1bUfNJFe2Y
9swWV0D5U1NknPqU6RwnnfSrcDKOYcziJb7/p5uXf9hQIYLjwQ2P/Ok5muVXHy91pI/3pOcuGw1e
k1OPI8OeuN4h2WDqnxJS0pFPGc9PGSefMo3D0ql+GRdPT32+ZZhllPmSTym3DKtPX/BGeEZxenoS
xuipyanVOaN0LgIzemo8+6Uz88v07vxkfcmfzIc+v6peJAxp0alH1qf2c6e5fTJN0nCnaOUgwzJd
Ps3i9ekSLtbPdpo/4RqSxJcx0Uketo7WZvz8P4vQZq/Dt+/9f0IeFlbv5ItklMawnK5PCzRO8lLh
JT+Z5vmU8nlaek+YcEJMn2nLp29a+nwztCq/UbqEMUsz4ihpGuGouvOFq6aZ0ZEwRumc5ksOma7H
lTiSdjw89TJK2aVsRukSxixN4qpPmXcjHKvcVE1Fxy/1LsuBucg49vsqg1DSJB+VRzh8JC4/Q3V8
ll+ort3RRrej9oKNN/dRs2hL6HTQmSIOsduvF51mKDMqM84Np7QhqgJluh7eX5gFZxiJHyh9xnPj
cCiaLjBjoUog863Gsd+fzlQ8mT8Z5x1m3Wkc9Gm++Eo59DAclrzUND1to7CKZ5Su0pbpKo948av5
UGVimWWalF8NSz/jGKVzvITxRYvhVCdoUSE7i9lFW4Vhv6Stj/fFi7JEeG6MQOR2Q3dfn9SVzC/n
RMax37fO3PVAwvJTOpUOx6k8iItL3zJewhuFZZpKR8ZJeMk3lGdDA1/+FoqjikOVx0E9Dq5DtoSO
Ftz79aXoneY5PiWFDYVFIDiB0NfDcDhw5cm3g3IZtAseR5XLU24ph1sIFVbGGsV50vF84fVpko76
ZJr+4FS+EpafarxKU+8PFE6PFy9hVX6ZfzPZVFgJYxTnTcddB7zTJCXlqW/dlSTpVfkGRFMiOp8q
vi7poguq+lP9UhGsKxkvn5xmpENOl/GqgZa0zJ4qXTOYrornBbdiuTAZDb6mwpaV0QvXffEL+PTT
0x4yyYx7REY4IHmYKUymB8aWX8zgG/vAaJtDqbJLefnpjmeZ3I0GU5JpEt6MulG6C5eRuHFRnExT
oky9Kqzk4ym3KapHAtOR+B4JcR/w/gr0l3+pM3/5NU7X6oBWZFa5dW31cL+Psqz8la0ezpf8Fw7t
w+ntD8NRe9IFpsc3CksZGMkoXRJLHjgCQ5bQ1bBT5sioqD4dNLSl7dTgektG4+f/WUgbUNpx7N33
BGMWloXnn/RzgsyEAAroT2CNuKooX2Q729rQ0dSMpCy6DtHpOun+8A466DDJedCfjNeeni+mZ5pR
SFYkPZ7vfKg68pcXf+l6qfTwzEvyE9IG8ymjIy7pcLSejw7UMKji+6PB9Bk+vhzLo5W5v/z7S9fn
S+ZX4nHepb64yFgVapoe31dY0mEYScMXvD5NxScCus8ZT2iZD8/Y7hsKRF96GFVf7FfDqiZkPBuM
2k3fQAYN/6fqRm8kjIon/fo0rY7IVM/2t+XCKXxadC+w9omYGA5ePdVJNoKWTtFnOa2eSrIl4u3/
exv//fQzbgmdPr0CvQB8RATSngVD3/5+JT576lk6i/4jwZWNxYU/7EXDH/+K9lb1ljsfQkUpiQvc
yMl4+VRhjOJkulGaUZyE56dxutYoqnCq3xjHjJaKqfklvlqOMs4bOv5izGSV8fKpSm4UJ9PVNKkT
NU7CyTQZDvZpUt1M6oCbuv6dVGuHkZxuzJ7pU/Os+mVuZZzUN5ebLDuZJmH5yXGn//thpCUlIJVW
GYmDC3VHhwQa53EMCe0AV48c6UVyMA/mFQvnIIPRzqM4lD/6/IPtq1/9f7TLr12sv5UCGCnELE0P
6y/MdPQwkravtPbGJjTufwktlVXov2wx2qpP4tPibci8aRYyZamqhHz65euia+w5WpxYK5E5XQcj
k3RPX3liULP0YOODo8VfRjpBdUEz/kZ8jGCN4iQLX2kSpquf/mQ0Sw823kifMu9GtIziJDzXSV/l
qsf1F3bT1Xx6eH16dwsHmh9zOHN963FazlSjX1qSODqE9aRPN4vT69QIT4VJobaq9azcca6mRMev
DU9xT4OGp/jMwmS6Ea+Dux9d7PSKkladxUr7XA76Lr4dtWQozhYWoeNcHVLGXYY+t9yMRLr5z7Nx
F62/SW6kwTBIdjaw/EXm+VL6omdAJ+ZRMk9+LETM5bIYWhq4yDQgexYBZjttyXr0vnGZgO74rBr1
RcvRXlWBhN7p6JP/HGyXjEft/xtrTI15xcBxp6IjgY5EpwvhxNHoiRRIpAOpPBvdGEiisOClYNXV
1Th58iSam5tFF5CvgB00aBCys7PFbVNJdGR65r/OxYW/HkDj//wBHZkZuGTdN5F65TiFkvSaNZ6y
cWU4PYw7rN2PIWkF+uxKw8Kyq3kzk7krZTSTyYq3NBALDcSw7rubEp8ZUw0GAyb2H4mMNb/C+W/N
Qvpd+cJgOD6mO6cDpOeTWRiJYnMfTQckJ/cSt6raeE4jkS7XQAcbjti7uro6HDhwAMePH0dtba24
wY/vD+deB1/ENHr0aMyYMQMj+/VHw/+WoY3mNHrfMBPtdRfQ8JcXkHJpNnqNHcOzgn6EV9P9lYI+
XR/2w6pLkgORMRCYLhHeYhq2BoKp32EzIwJ6fhwOt35FgoZR3lRZjdIjF8dzFtpZTf5p9p6j9TBU
yKQBo5D5w1/TKMo0OD5+F3UP32lKz+yyJ5VeJPydvD9DTrJQO2vjO185k3SYbyToB0WDr3YtKyvD
K6+8goEDB+Kaa67RehW085CNyYcffojDhw+jiSa65wwehs4tT8M2fCgGrlkBR9XHOLvhv8g698Wg
730LibQx0bcLt0LrqesreCToy8odCVp6ea1wz9VArOuN5Mca5bqqhsPRcjTrfTRpK3lmNmGychmM
h8hg0FyuqQuTjyldXQKXLn3Hiz0afNNqYq/UNNoi7rmxT4cTlSBva3/rrbfw6quv4vLLL8fNN9+M
2bNnY+bMmaJnMWvWLMyfP19cbv7esWM4SLBJk67C4PtWIX3aZBqq+gr6f/0uJA+l62F9SWgvR15u
LnYcC3U3pJO4oHMrjggyDXg8dzaKjtT54ozybbci9/EjPmE8Eql0tA6T0UvYgB235uLWbcanEQfN
y8XYjiO7S3HktF3ENBzbgdzcPJSHqS4XecsTAw1EoKUKSEqul8666VFFfb6BAVHuMUByTiOQp0mm
HR9RD+MBMhj1ZDD80TGhEdFo0SjxuiltO4YtnfY4pNBX+oXz5yLKxx+xVuo9vPTSS2I46oYbbkBO
To4HCl/7yr9+/frho48+wtHz5zFt8WKkXXmFgEvsnYa+dy2kZW20T4Mm8n253pTYSrdOBe/4zXC+
EHR7FZDhJJGKWfnr4Bid7odkBjLBk/SRcCRLRoJLAo2ilI+fmcjslRYSo39sKsaFoq9g0pCQ0C2k
i0IDXMcUJ14L1ViofgUuLryxk62TLlwKZ9ioTRgMatcafPQwnDplXrFwfEihdLRHA4lDBw9FRlo6
GY7AGze5Xll9SqJGTxVO+ttos97p06cxYMAAjBw50ghNxHH6pWPG4EJTE1rTUsnwuhWVmJFOm/2y
aEZfO+edaUsn+fDTXP0OlJcWiZ5ILvVGcvPWY19Fg5iIT0i4gL8/tR433ngjfXkvwIZf/QE16O1M
a8GHb/wdH5/XhvQq9j3uonHrig1445MWASdl4WdCyyf49cMrBT2mufLh36LaAVTt3oBb1+xEHX/B
UdY6myuw4dY8PF/Z6OSlrQ13Z82dR40+p9N5MClpqH9jL4rW55G8nJeHcKSWGDDvhBa88dufYAHx
Zd533f8U3rtAeC2V2JA3HyUE8+dv/wvu/+17LrnbBKYdrzx1P25c8DDeayQm9k+w46EVGn3iseKh
nSIPAjQO/qhlrtYFFs1XmhRdwsiwEZ6ergprBK9PDyYs5TF6Sjpqmozjp2e8vs6okIH4CZ9JeJBx
v4eBUDCG8SJqDBZGrKoH6ddlJAzq3qgJtGRf/riXoPq9eg06dDYYjU89gM4LAfQwZA9ERyMawaRE
G/cxBGkHtduJaampyOrTB6l0imFXOB6maiKDoF9uK2Wx067vJl5RRREOsYmPteXbceWQzowup9uP
lWBt8R5MWrMRT24pwqIBh/DTdb8Fj8yU71iHwpJDWLCuCL/cdC9O7dovXkRpWk8fPISPm2nTyyd7
sHLjLkxa91Ns++WPMe3sC8hf+qygIWVgeY48sRTby/ojv2gLtmxcg6ayrSjeW4WREyag/uhWHDyt
NfANH7yIFxoGYNxI2auRVPjJL6p8WZ15pIeWR+plVO7BR2PzsHlzIXIbyvDIM3wbI1Cx8/vI37of
U1cVoGjjOgw4VILVSx9HbeogzFuxBlMIZsKCVbjjC4MFPMg49kl14CAt/ysoeQ9rfvodjCdxjjyx
xDAPTqQufahlLgWRcfIp4/mpxrFfDbvh3PXIHRecz5hucDSMoVm28OXTaPii40xTq56xQCHERoWo
Sw4z3SvNgws2Yh5qnkRvg3scfn4qTzYYDU/S0SDfe8ovnqQrjJBKJEp+bnHp9CmxLaOFTkW3fVD5
AUV0ghvnYJ2vBtmIlgrPBWqjIZ9z586JyXD+Ou7dmweS3C80H4515MgRVFZWaku9+IJz2sauwoiA
8kdfUfRhBRS2/ldjTf5kzJ01nixILS4dPQz4jIe6GvCP31fg0rs24xtzeDhsIh7b0oCv3FsK/gLn
fLjyorX1qD/fBNugyVjz9NOYR0fOpKqM6BTh/tPX4f6brsX14/uiobYJVxCNd07XwzZ/Ohbg5/j9
36swZ+FYvLWHvvtzCzCeCEgeMg/yqZF2Gg9pQ1prgSnr8NiyOeIO3+Q7c7D/uaOoWzsOL9Jz2KIi
fP/WiYLmT7e24CvLf44/H7sLeTNvxFuZm9A2i4anxqaigVb4JSR8iF/c9zUcfScBP3j6fzBrJA/N
cR6+h/y512LW+CzKQzOupNh3z2g9M00m91+97O4UzSfTOeSZL+90LSawv5KuL5pqmurXc5CNi6Sp
T9eHJS0JL8P8lHF6nEDDEt9N0xtT8pEw3hDuGG8YzTjo+bgxNJ+2f0mrdN403HVWjxf7sNsQyjxJ
GVhu/nG8zIOEMQtLXD2cjHc9echIfteymqQYzvdU0k+gURJNBqDto3fQsGkt+v74d0jsTcckEb6E
k/p2h52EmGGMhqd4cS0dg06z4TQJTuxt587XIoki+O7XYJ3MCONJZfqiocLzPozBgwfjxIkTeO21
1zB16lSX0ZA02Gi8+OKLYikuL79NpUl7diodCWv29CWXbQB9Wb/1KOYWHnWhJwwnr/0EXq4Hrr16
lCvelj0OZFK8nC17LopWvY8Hih/Ekl+xbMOxKP9BTCQ75HY2DB2RheceuR0/rnTGUqW9VEzF9MfN
q67ErmdeRcPCDLywvxNLfnG1G5V8nAcC9+m49DLHDnNe+k4VsZUH5VKQZD+LcsrLF68d48K3Dc0B
zyDJeR4+hKXVwUNtblN39GiN0POHZ+rIaAygNBuGjaQ8PHwbCmUeKHasyXQSl5Ev3cv0YMqS2Jk6
X7xMkSjBjccNiTGkXkY3jjG8jGU4Pa5Mi9enLBcz+VhH3JDFe77MytI8X9711SiP/vQjDIacPuX2
XdYpRWcJmeno++hOIYqY9H5oGbIe2KYZDI5lfCceP1jfMuwaaKAol3FifxQd39bHjmVJIAuS2MET
xCRVoJd0qIo0enk4Xf4EJ5M/vHRr+PDh4qXl4Sk2EHrHMp2nCXB+8txGerrWE5FwzF8vgxpW/XSD
iERzPY+V3IdNe/ph47PPY//+/fh9YS6tWGhBZ69huDaTRns+VlZH1Z2iOQ1v56D4tCnLUUr4z+98
EusWDUBJIc0neKw+Oo1NS/PxzufzsXP3XuK1G8vJAjVRa826GvPlO5DQ8Dfs/9selGEmfckbDU1J
3j5WunG7r3eptNeF4k58dF6kiLJp/QxnnHBuHan6yUTBzudROC8TJesewTHRCT2NoiXGeZAsmZab
nox1P32l+0pzUwjMx3kM1vlC4XeWf3ondEmIofDT0/IXlrwknC89S5hAn/5074uXP9xAZegqOF95
kzL5y6NMF08xJEXtuXO/Bm9n0P/Sv70RttHj6Ry9d3G+4Gvo++BTSM7mEQ2g5Z3XvOD1+O6wUa2U
UkfuKfbxUT3no0QS6dBCCidpL3qA75mqIBaLw+z0lVrGiUTnHxWXh6Z4497o0dm47rrrxEY+BuO9
G7xHgw0FGxbugYwZMwbZ2dlIS9N6GirNQPxsairefgdVtD2/ooJ/x1BRVQs7f2IPG4T+6TbUVr2M
Dfn7aYVSC5oS+mLil/vg0CaeGK9Fc/1xbHukkIB7e62Fsn/8R6xcegt2HKyic+aH4vJLRxOch8Wg
ye1afEh6GjF0AFI6m3HswFPYShYogcYHhRswGasm1KB4YwmG//ttGKnFGv6tqX6PZK9y5qMCx45V
ocFnJ3EIpi/IFHnZfew0DStVYNuDBagn43TDOPeJwScq3kdtgxyizEDfjExMvffHmICjWL3pABz2
z3CcJBo5bCB6we7KA1q4RxM/Tm3AZd0MVTpZX6mSiw8rlY7Kh+P1YbM4lUaofl/5MpLD9ZUaKkPC
c77mGgVqQHqik7rzyCtllONlmlMBrux7lQX3Evj71+SX8d1HkXbtXLRVvYtz374DthzNWHQ0XkDj
C7Qg5ofLxeS5is+T6Rz2OuxQ9mhc0kTHQ4NSIv/c0vOIGH220tchBbwyb8JfKs8I3ijOhIyYo5hA
k8C8qU/ObZw6dUps5mMe06dPx4gRI8TejZqaGmTw0mA/S2u9eWmVm03Noa359FMgMhfhN0V5yCnZ
iHtu2SUSpkzJQcKbpVi57UsoXb0Zd53+Jn6y4qv4CacOy/R493hUhm1OxsS7kL/gnyjMvwfbKcyy
z1tThKuos/A+hdklpF2Btd+8Ed/8xVrcUkzhPtcid0om/vb7R3E4rxRfyEzF9NvnofjoHnx1zlgN
SfkrdZ7Mo0RlxVhZpiTSoNnG53dAb06TU8hUOjssU7++BcvPUq9q9WIUiTdiAvKf/DayRaclFZ+7
cQKeK16He2qK8Mz1XBvYzJJLHY8f/OhW3PmDQvz+9t1Ys2o2VhdreUDmFJGHF3ZtwJG7SjHJV+dI
oxb1v1JPwdRDX0L5oufJg+uZOhSlhX3RDjbNk583NqdLeTnVI8xFGq7TXiWNCtehiBqO6OhL1YfM
vlGcTHM/PRVmrHtVIQomoYqJaml5nGCCBvnTZy9Ey4fv4NzaO8Sy2pYX/46O+vOivBz/+D83IfJ5
lKEzrAJIFmpcNPwJvKGPRoK0u8Kpnu3Y8WzncNpl/ZuS32Lrr54wr3hOoc2UbqxYLQtmOJzKS2/L
y8vFCioeivrLX/4iehh5eXmYPHmyhzwMr1ckx6lOTdeUyhXAV6V0oIG+sG2pGUilRrSlsZEaS83P
dO10LpaDbGt6uvsqXJUf+0XeHXY02B1Io7kX0RbLeHq68i9gqC3P4LkDB/Wq2px+CuqcC0eJlzqW
acGGHfYGNLclGfJUaUo/s/bUJ+mS8tDYQvtFKA+dnW1obGx30VNh9bgyzE9JXw/PadLJvMmwv6ek
qYcLlIeKL3mrcSpdma7GSb8RjoSXaf7DTM3bCEge7vrMX8BaLNOU9AW2EpbvgUzXw7rpSlpcRu5Y
IS9FyChf+ALWjRqgz9f7GSAJAzCZX4Mk7Z1VElRYmQd9nAyr+ZewktTbMy7BkBRaoqop3VUmEieJ
Dl7toI/gjjptST3jDfnfDwX6qVljXPAcIXFEojMs/fw83erA5185oUb59J85c0bsfeN88O/111/3
glfzOG3aNJH++Wtm0YGFdN1rGx2Q3tkOm4MuDWfAtlZtZb4XFV2EPiOcLBWkAw0oyLx5QpyHo/h5
4cIFgcd+vZN8jGTQw2ph9YtBVnkVktNt1Oi5P5NTFT9DyjDXASO+UiayOkRHe51VDux34TlhtDhu
vNV5BD2WZ9jFxzM6qBAbxoxeqk6CQteAOQ/JUpesO7kI2W0MGDBQeV26CUGUQFGMeAQiX6h4qlyB
8FHhhd9nG6omclnKsvCiElKEs63zxtWxMtKNN1IwMWq+gsEzhzWTMdAyUfHVxtScI6WwnuRPBaQ4
ptf+XqWIZROctnAxDU9NdEFl3r8B7R8eRfNzz2pxTEd1/sIqbAT9zJbzz5v82mmuxvbAgz+GvbmR
vvi1ATK9QvVhlsUozpeMvuB53oKHoaSTxoJXS7EzwzWLN8YR2Rb0KO9EU0CJsP6PL7oCy/St0iiZ
4ZvF6/nLsC94fVqwYclDfao0VD/D+AtLOno4I1x9nP5llGFJM9CnEW8VN9R0f3gqD/b7gtenBRs2
MhAqDdVvJIs+XcpuFO9dzXmRg8RwfyBI3FDLTaOoEHaziIhPyuePmBlcsPEdDrpxIpEnNDSnDf7L
ENUPYVG0cJ8Vj7gTyJd+40L6uxCNv97hilfhXZFOD330x8QlUC+D5zL42tdOmoW39UqmYQbKY0cH
DcvEgeOjQ2QFNCuw0MTkisnL6kLDtrCiqwFZ5tHl0p2pyx5FfFVgq9x0dYqLJ8AiqpmRrUMOMhgg
nyCpeoPzLndaMGWj2wLbO3iw3vnlrZ4v4o0V25jIGgtVdtZy5LvBKoeLzR9uWUl8bnyk/2LTof/8
Rt5ghKtriR9+ufWs9zF58Ai0fFqDXmJHnP+SDRWihT79mVcsHB/TxMtteUKcS4smxambQd0P7SKm
WIjQ1Tykeebsy5exq2Wy+MtGyNKEkQa4zsp6a5TedXH+y019z1S/lDk+8yWlC/Y58r6H0EhtaguN
/XfQsEY0fkybeTCvWDiefxEHFfLBhfSzUbaIL3c/YsG+q3lwJntWJe1qjVr8w9WAVSfD1WA84Wdd
fxOw8UlUP/YAWms+iYpoKcNGkMF4GIJXVDh4EuVOk41udxUzNWQIbbym2Ea7pVtjNKniKU5Xhizj
0ZXat3izBi6GLzX9e6YPx0NNUMshfPm4MY9Vgx4L7SU6V05xz4IGkWlXOHlsNFbF50/Fr+NClQWr
+uNXYksySwM9QwPyvYtEbsJvkCMhhTeNeJXLW9Iui1HmaBJ5fwTbjwTqfsS/k8NooRZyKHiWkYr/
etFdJeT6GEqdjHR+9XVcbyj04Ujzjwd68VAO8aAHbxl4Ipy6FZRAA1SdvHqKKm1rC510RzajhZ9x
6fSVVi1gTlPDkc5AtOlHWl6LnqWBQDXgfK8Mqzi/U850QS6a71ig8kYTrmfnlTsHoTqe7+aBqOSE
FBqhoolwth6OdvrRBUe96NrX+HSyQPUVl+ON4vS50MPo0/VhSdeMrx7eClsaiJQGZJ1jelxvZV2M
FH2VjspLjWe/5C39+vSeFtbrItg2I/710UBHIoXibMkpSO6VgnbaAC6mM9ra6Eam9jZxjEcoBGOH
E2ghSjh9JQhOUvf6c6bDP0k3ODoWtKWBYDXAX3aitvHpphF1kh5TV/3MRB/muIulzsu8c57ZXSz5
1nLr728HbT3n49ETU+jIoDY+Ip0rJv1PSnKfIeSPSPyn6ytBsBJrlYYNh9upfnes5bM0EF0NRKMB
U+uy9DOfaPCKrnbCpy7zHy6lSNEJV47I4/NeHB7e6uQ9feRP5K3hPAWeRM/4dCyXrMyqjNIvn0bS
h/4isKLov8t52A9XrOWxNBCOBrjuyvrr9DuD2kOpgOGwceFGmp6LcA/yBKojZ3mJ8nMWWg/SgpoV
/njmuYxOMhR0ljJv9OPOBp24SNevdi8nC1c+Vek5zihehQnEL2mwAZH+QPAsGEsDvjQgGxxjGFF7
o1bdBHVirD6N5ej5sVQOIbf3RgUUMrG4VjW3ffzRnCisBu3r63/1NLTSsei2jsCORo9t7vwVglHB
RVrCWPCItMwWvfjVgO86zana94lV76JThor+pVc+BUMKBKp6DzyntF7zUIESi05uI0WVj0TnRVMd
pBzb8H9Zgo62VjR/dpasrpEWfLCN8Ne3/mvec06B5Qi1ADhfoeL6yL+VZGkgaA1wPVTfM8966RkK
mriF4EsDgbZvavH4omeU5oVLERFuJ43YRjaOM6HURJoEd1DHgmPaO+gSpvqmFnS2taClOfg9Gu4V
RuGJzEvBqqurcfLkSTQ3N4tlXck0XDZo0GBkZ2fTbVN9RFzoXBQFCCI6pYROOEzMeJEjzGxY6EFq
gOujSdmLqqqvr0GSt8CNNSDV7tQ+A8VC05FqJ40zFY1YT63wddysKD7cln82B509xZPibXzLRpCO
McJVSF1dHQ4cOIDjx4+jtrYWDodD3B/OvY7MzD4YPfoSzJgxA5dcMjrojlCQ2YkxODca7EwaDy3R
+ttjNaB/3/ThHpvxuM+YfDMjVSKRaCe7UmncxqfSHr4W7m3wJUw8VtVJPzYcobpQDUd9fT3Kysrw
yiuvYODAgbjmmmvEHbZ8mx8bkw8//BCHDx+mO7wbcdtttwkY7dsg3IY2UtUhVI0xnqhKzmc4dCxc
SwOWBoLVgHz7ZEsSaUNhJE+o7aQRrVjGsdyJdO95ooMMBm3NEKfcajf3hSaGS/lEWD8n4Ysir/t9
66238Oqrr+Lyyy8HX2I+atQopKWliZ5GU1MTrrjiCgFz8OAbOHjwIHJzc2nXegqRDaLRt5cjb/5a
zNn8PPLGu+8C9yVb0GkN5Vhxy1pU6hBzclfhx9+/FQN08e5gEPlwI1k+SwOWBiKoAWkwmKTqjyAL
1ydidzQc7eLEEAcSaG4jKdFGRoN7GfQD/8J0wSiklY4teemll8Rw1A033ICcnBwP7nzta1ZWX/Tr
1w8fffQx3njjDUyaNAnDhg3zgAvEgPQmjFZH6GevuKuSiY4g0cLWAABAAElEQVRoyI/dzDVF+OaU
fmhuc+DMuy/gkY3FeGzCNXh0frZIt/5YGrA00D00YPKmR0T4YNrJiDAMk0gHfeDbac5b9DjoEKpE
vk+Df+Lm8DCJMzoTDsSx0Th16hQGDBiAkSNHmqIMGDAQY8aMwYULF2iYqp7guDjVnymqK6HJ5fP2
1Jbvxvq8XNGLyc1bg9IjpzUgRxU25K3A7gp5Xkszdq9fgZ3HZNiTFvO4dNx4DBgykvKTjUlzFmNB
JlB9mmVmZ8fBnRtwK/WWuMe05vF9qBPRFdiwYgNePrIP6yk+b1s5UFeOx9fkOWVajw3E96HSY4JK
UHScGNbD0oClgfjSQKDtZDxILUai6E8CLSdOotPQba5+UwRPRg/GkvIwFQ9FpaTwCYo6g0PBlha7
WFHFhiK4kxqZlu/vBcfpfVi4dhMyZy7BxvuvxDu/fQTF6xYj/em9mNO3Hu/UVGJQs5zsceD0e5Vo
MemxcG/m5X17cXltX7S1teH4oeewvX4YCm+fKMq9ovQh5G99D0vyi3B18rt4oGAj1mUOwy/vAI5X
7sf+dfsxIXcR7p6eiseX3otdmImCzQ8Cb25DwfZKDBvrCJLOcAFv/bE0YGnAWAPcOsgWR7YUMmyM
EdnYYNrJyHIOjlo7LU6i/gVsvWloypbC171SJ4Ma7rZWgyW3UpP+eBho2p9COJ2Xcp07d05MhvPX
d+/e3PS6HS/v4onwiooKYVDE0i93ss7n30joEPDBvt9TVC62PJiHIeSb9OAWfJK7GDv+egzUUVCc
f0WkEfTRXZuQv0tBQybOnqT+RBbw4jOHkLNkI2794hgCuAwPL/9frN1ahto7ZgqEnEVF2LRsIhzV
u1FInZN1zz6IGSzU+Aex6uX5eEZA1QVMR4BbfywNWBoISgP+33Qf5Pwhh9BO+uAWsySa0kAvG02A
U3stehrDm46L+zSa7Z95C2GQSQHkTzlOSr4MB+/DGDx4sNif8dprr2Hq1Kk6o5EgjNnfX3yRluJ+
SstvM5GamuotYzgxrTSoNHOGMBgamSGYkQscdNrP3q7vEC2Vp+ANTKtIbKa/i4qex7KJzsl2Ry12
3rcQm+7/Ha7fcS3eIENQuX0dbtmu0ZJ/P2qaCR7aun46GxMafDrHw2M5GEaGRnOpmDiD5nF4lKuB
5nYCpCOxraelAUsD5hoIsCkzJ6CmhNhe+monVfJd5e/s0LZBJCTRCipa2Wpbce0Yuk+jDZ9+mqVr
In2IaKYcAxQzhfCy2uHDh+PEiRNieIp7FXrHcXXn68SGEp770PdE9PCeYV11oHvQ9U4M+JS9TXML
M7gzQK4B/zxIjxvpSBVHimjMU1x47aAVwqZOzJs4J8QFkG0ArricfB/RGoOMS3AtzW8Mv/dpPDhn
KOzE2FH7AQ6968AVsnPlHPayZfYnpErUNdJD2Eg7yl+uAa6lcBB0CNpylgYsDQSggSCaswCoGYAE
wMCsnTSgFvOoDprPEJv6qM1mo5GYyHMJNE6FKB6NzgrRO+7qjB49Wvyuu+460ZNgGN67wXs0eP6C
DcvUqdeKifDs7GyxHFdPRwszfZ2RUAC5Xa54+x1UVVWIoa6KimOoqKrFJdPnUMoubNp5EHUNdThS
+jOUkGFYMJNWclEDfT019C+/eRQNdkqjSWweeTK7pkrP49jBUvyCEaZeinQySRO+lImyjY/h5Sqy
BvZT2PPoahQ+9S4BeLrU7Ck0mwEUPLIDVbTZsbz0JyiuBAZzNycIOp5UrZClAUsDrAFuKfS/eNGM
UTsZF7JR08rHh3Ab20HzGzbeWxHM/opQM6G3pIl07+yECRPEhj0equK5DV5NxXMY7KZPv06sqpo9
ezZqamqQnp4uJsuN+ZsbDIbn+YZDW/Ppp2BnLsLvS5dh85pPsXpTPsqcabmrNiNvYl8C7MRN37oZ
JYX52pBSplwS7N1jYapGPHifxrP3zeLrETF19WYsObMaBffcxuBA5hQUbvk36kwcBxscd49mJPKf
LUThynzcs3A7wU3ABDJeta0CKwg6Grz119KApYHuowF9OxkPknPvooP3atDNfQ46pzDhL3/5Syev
9jl79izuvvvuqMuoN1B8bEh5eTkaGxtx/vx57N27l7o/ScjLy8PkyZNpAtxMJJkgDQaHpd8MxyTe
YafeBFnQ1AykqkNMDG5vQAMNJ2VkRGZjoIPo8fCUKT17FXY88QKu/PclmDSEhanDjrzbsO/6Iuyg
iXLp/NKRgNbT0oClAZcG4vZr3iWh5tG3k7rkkIJnzpwRJ26wDvj3+uuve9GR+mH+vOGa3dTrbqYP
dtp0TXMaCRSvbyK9iEQ6goVSFcJhnhBn48HP+voGkT54yGAnazNjwAZCGg4ppRmsTDd52lKpETdJ
I0NilmSC4TOaDZNPeqn9gPdKsG5xCWbOm4dzL+3BUV66e8t4D7p+6XhAWwFLA5YGvNuL+NWJvp3s
WklppWuyDclkOGhTH2zn6htht9vRSl2PWDlVITxvMWLECBfrIUOGCqPBq6UYTnN6YyDjXWjkkb0M
PawKE6w/krQC5Z2FvF/uxhePvIbyD86gdVkB7rt+Bkb6tDSB0rbgLA1YGuguGlDbya6UmeWw0RQC
X9jXLs6foh1+vejC8DZ7V4rl5s3HoHt+ERj1KBheGgk3buR9seBhJHUqxk6aRT+jNCvO0oClgdA0
YNaWhEbtYsHi+edEMhwOmsbgc6hs/TIz6Oa+VrQ2i0Wj3UQP+sa8K3oEgavK3WMKHKc7QqrDjt1R
fktmSwOWBrw1kJCUoK2e6iDjQfPNNntLK1kPB9pMjsfwJhHLGGkc5JN5GxkINV31x1JWi1dP04Bl
7HtaiVr5CUUDiQmJNAFOYztkPJKo12Grb2imswrbxQUboRCMPU4sjAIbJuliwU/ysp6WBiwNWBqI
Lw3wCEIH/RL4YFuyHrb+/TLF8FR7Kx+EEQ9ONthd2Vgzb6MeTTzox5LB0oClAUsDsdMA7eSj5pCX
6TJPMhrJvHGDJsM/rYuTmfDY6cLiZGngotQANwLUBFyEeb8Y8xx+MfMwrZgMp5NuyQdbY3Mr/nH8
DD45Y3xPRPgsg6Ugv/KDxQsXXlYo2cORz3DpeuL3tMnii2ncvyfk1VX/ZHX3rJ5WyNKAlwbYULDT
WkRaPXWo6lMgORWDBvejuyvMznD1ohN2hKvyhk0pHAL85kjjoHW/aOhOiQuHthtXbWw432rYDWXu
c0uoSmsOH6sU1pXWZdU4xkeZRi73ajmFUm6RkyRylGQZ6fMWOQ7xTUnNd3xLqkknyytcWYO7i8iT
Gy+1ddjoTg266rVDDE+lZyCzdwpOftJA92+bHcfnSSQSoeCVoTbwkZDAiJ5RXPi81IraUxofI634
L9Po6NdIlkjE+So3s7yqOJGQIdI0pNyqnDIu0rzikZ6a73iUTy9TJMumoSG00SQ+e4pP7GhztAij
kZjVp7fYge2gU2W71nGDwr9YODM+8ps+FjJcjDy6sX7NqgwVo9oQRfIlj0oN8ZGP8PlFlXjY4qnl
FDaxi4pAJ23u0066bW1ppjvCKfPtNM6gDcvEsya6cYMTz2q1ZLvINBDNhj1e31HtgL7uWdDRLK/A
NNLSbBcX4qXQySF0ciAZDbYWXNYRvCM8MFHMoCKhJKah/vS8OMP6Ci7h9bBWOHwNRKJMw5ciLAr6
6qIQi/vehSJr5L8Ozco2Xt4nTb74/yhWCym+/HxJn4MuxON6nkgrbRP5/lcemDK4OK+LJPfxdgYt
kZFxMCMSDKwZDSve0sDFpgFf76uvtNjpiRdrqAs2Ysc5Epy6XocddEhhB09f0M7wlF69afkt7fJL
IotxSVbsJsE1VZp9oURK0V2v7EjkxKJhaaB7aiAe3j+5Ia17ajBupOZJDOpl0L5wcXChbXz/ZDru
FjjXGdvxKbb8ssvI3R7fXwJsYOKhEsZNMXYzQXpe2fGkqtGwlDXZqlbNrnxvLYOhlkQ4/gTqYfBw
f0c7GQ6aEbfZ6BCqznae3ojml7+5yHyb1D//+U9xneuQIUM87tYwx7JSLA10vQYsA+GvDLruY0H9
CBVS0B81zp/kVrpbA2R+xSe7dv4Ube6z0cRGO1mPWL8A8ivt5MmTdMXrX2mPSAquuOIK3H777W5p
Xb6uq3wuESyPpQFLA91GA3IUQxNYaz84LtbtXPgK89dbkx/70WsjNV3yClviQdMZNqnIJOpxdIVr
oaPZedPJZ5/RheWiGxR5KRx0MyFdAE4W0pu2g+4HB4zTvKGtGEsD8acBfXNh1Mx0zdvd1brSa6ar
5QmFv788+EsPhacnTgIdh87bMpJ4VoOue01sbXOgrrEZb/NxIl3geqX2EhaMvwAaGxtoFRct5/Jy
YVT5hnKsmj8fc7+2DbU6uo7q3Zg7l9JW7YC/vZLl225F7uNHdBRCDzaUb0Nu7jbUBUnCfmwH4eXh
iD+BYceR3aU4clo7iDJUfkGKFyJ4A3bm5eLWbeUh4jNaAx7PzUXRkWA1GgbLOEWNfjMSpxn3EMvS
goc6wgjwsB4fVcjDUzzGl3iaTrd9+f1afNoa24lwmYfeab1Fl7GTLBjPaRi7MCqA7F3UlOClKs+T
fN/+605jdoaxdNxKL7pYPQJO5Ibk6swEgl2zRmsWhEsOQI5/bCrGi2ecgKyHEPgFwCYCIKkRoTEr
fx1yR6dHgFb3IsGfVP5+3StHkZQ2jA/OSIrRjWlxe8UXMfEHfTt1MhLfPFGPPgP7IaNP17xs/fr1
RUZGOg0d2TBz5syojTnmDAN2lf6fu+gcVfhTSY07zD57NXY8tIK+5HPFb8VDO1HtbKVtKb1R/8Ze
FK3P09LzHsKRWtmE23Fw5wbc6sRb8/g+Vw+iYt/jyHPG37piAw5W211LDhLqq/GHbQ85+eVh28vV
nvIEEmqowDYpU+4K7GAa9gpsyJuPEsLfs3Y+1u88plHywa+h4gDW51FvSsiah6LScnDu7BWlWLH+
cZRuW+9Kc8vpQHlpkSt/uXnrsa9C6wL5xgOqD+7Eilulnguxm4oiw5lfM1ngoHyteAj7Dux08VxR
tNupazsqDx7AR+c8PwycJK3HRauBMD44L1qdeWa8k40F/Tppr0YbDecnDqTTbZNsSWizt3lCxijU
p08fsWKKh6cGDx4cFaPRhAm4c8Ui1OwpQYWzna97uxRlyMWqRRMA59f4kSeWYntZf+QXbcGWjWvQ
VLYVxXurnJqgXkblHnw0Ng+bNxcit6EMjzxzWKRVlD6E/K0HsSC/CEUFy/HRro1Yt4MaXRr+Wrlx
Fyat24gntxRi6pn9yF/6rHMoLIVwy7D1jUEo3LwZa+YBJQWPoSKoNq8OO+5diZLqSYJG/qL+2F6w
FLtP9cG8FWswhThMWLAKd3xhMPl88KPG+AcrC/HelXdh85NPomD5WOwpfgBvU/vvaGtA5aFdKH5j
lJec9mMlWFu8B5PWcP6KsGjAIWz87k6RP194jqrdWJq/FU1T12DLk5sxw14GNt90biYxNJcF9mYc
ryzDxsLdmF9Aus5fREWyCX88phmq0wcP4ePm6J2hxhOB3f1HGr6IndXrCKXweWNfW5tdXAvOI1S2
RJoAb7J3YGh6Uij0wsbhk3WnTp2KyspKvPbaaxg6dChSUrj1iKRrxtCrbyITUYI/Ha7F2qlZKHtm
D4YtL8K4lG1ORg70n74O+XOnYtb4LDTUNuNKSnnndL2W3kozIlPW4bFlc8AjPcl35mD/c0dRt3Yc
XnzmEHKWbMStXxxDKZfh4eX/i7Vby1A78xKBe+FcE2yDJmPN00/j5k86adqdvuBFSiYKf/YNTOVP
7FFrsW1PES7IzotI9/3HXrEX26m1Xb75Lnx+VC9g4Qos2H0IO184jR3LcnFF5ia0zvoKJo1NRYPo
bJjws2Xi31atw2VfmYORNjuq68cR4wqFuTGerf/VWJM/GXNnjacM1eLS0dSdq1XLzhjvgzIeFpyH
x74/HzwgOfbRp/FJ7lK808osfcjCiieXW7AJC2cMIN9lWPJfJagX99tHt/52v1U3QlVB/uFGted+
mfPYvOWC1wBPXNiSkuFo58VK5OdpZ0drGwZnqi978ITDweClthMnTsThw4eRk5ODa665Bkl0HG/k
XBMcqSNx+6JhWFlyGPd+fiC2HQXu/eFEpO1vdrKxYeiILDz3yG0orHRzznGqhdvyzLHDhMHg1LbW
JvqbgqSGj/EG2ZXK7etwy3ZOcbtPBn4dRas+wIOPF2DpVo4fhjvvfwBXXcF+biFvxDg5JmNLdg3P
cKrbNaC66jwGZo8UxsYdT+VGF2ix27p6IQR5Z2KOeDoEhxY6zphXh/nkZxuCUX1PYP38XPHFr5HJ
gTZvYi6nbQD1YN56FHMLSZnkxJI8shuaM8cTgs2bLgyGBtsXIwjvHQ74lAVgrQ9ynV6g5VGjYf0N
XwM912CEr5uLl0In3QvOHxOJCfTVRl0NG39YdNDa266ZBtcKIo0mw2fNmgXes/HCCy+ICZe0tDSc
P38ew4YNE8NXqampYQ1d0fwNJs7PozGgJ/DEpsGoz1yE6fSxekI0/izHaWxamo93FuRj589nYkCq
g1b0zMdurV3WBOX2V+8yLsG1NME8/N6n8eCcobATH0ftBzj0rgOXt5/CqSnLUbr/29RzqcKrz2/C
xh8/jEnX7sDlgk4vWsbmxzW8j6X3rMOSLbuRRz0Gsi3C8WBiar9+9DcTBTv/BzPSHXRRCnDq7Tdx
pr/Ww9EgVQ7G/OwVO7CysASLCp7E4hnZSHWUI2/uRg1d/DXGO1ZyHzbtGYuNzz6PSUMycP71R3Hb
BlVhxnhsgPHSUTSsneo0lO1o1UaYaA7FnyyM3M5/LBdRDfTsXoa2VCCiCosRsa4vF2EdaNktL7ll
R6fcsg1JwOk6+cUdI13o2IwaNYqWv84VhmHfvn3YvXu368fhc+fO6TCCDHJLNWQ6lgyrx579lZh5
702eX/b2z3CcQEYOG0grmuw4duApbOWB9hb+tvXlsjDhS5ko2/gYXq5qpGGaU9jz6GoUPvUuWj/+
I1YuvQU7DlbBljUUl186mgg5W0dfJNU0Wxq45/DyvjdR52jAu4ffpVBvJJOBsI28GjNRj4Jf/Amn
KX+N1W9i/boCPPO+c0iNIE9UvI/aBt8TJbLHMmQoWb+6apQWPiB6HJ+e94PH9mHYIPRPt6G26mVs
yN9Ps9ktIC34dGOmzwHqS/AzmmxvoDwdoUUEJSRyb8IKVRafDENM7O7zF4HKr6lHaxCCUxU3aN3B
dRc541OXvHKKDytMSLLRYYU22Og4EST3SsbxM74biMhnR1pQrUD54vKrrrpKrKJ67bXXUVFRgaam
RnzwwQf48MMPMW7cOPTv3z9MMTIw5+5cbC88jn+ZPtJJi5qqDBqDSh2PNatysbp4LW4ppqTMKcid
kon9uzbgyF2l0C+2TabVVNLqTF29GUvOrEbBPbdpNAm3cMu/of8QB/IXvI8f59+D7U5u89YU4Soa
khLapjbaryO5vrsmFys3FeC2XRp07potmChWqY7Ed57Mx8l7CrG4jIWmNjx3FX44h/PmwOdunICS
4nW4p6YIO2ZRlAm/jPE3YdGEEmxauRCbmMaEKTSQdgiFNGn/m83meJfNzkNOyUbcc4sm2OQpZN5o
0nzltpnYMd0cL2M8rc5a9QlNoq+FU2wCBtIybPAly5Td04VhSaGFG9KlZCRAdgB5JFH6Zbr1jLQG
PN/bSFOPGj2tmYka+agRluqOGoPACPNIVBIZDV76mfDws3/ubHe04uSJT/Cr/G8ERiECUNzDEX0c
mllxegVV/jr6+OOPcPToUVRVVeHUqVNobm7GqlWrMGbMmAhw9kOClpTxh3lGBrfKDtqt7nD6/eAx
tL1BDE9lZMiJCieOoOlAKsWT2kNyDnsdbcJ0oFd6FjJS9VRYThKadr17pwXOzk478x2SBvUAGhyB
0NN421IzwGIxDcqo8Pvl7EMvocnil6MFEDENyFaY317VHzEGESLU/Q8uFHOFEdAGn/OXlZUlRnN4
Ycfrr7/uRVUu+GCe06ZNE+mfv+YGJKekUWeDNvbRx73tupGZaGltxRkbj48bO7VaGEOEHqsZD8YX
pkNkaPTobAwcOBBnz54VvQw2Gv3E+H3ofALG5EbT1ebTly99/QbquOF0oapIHjTVhMD9ttQsmmcx
g2c5DTmbIRjGs1FzORvlJaCse/L2oOEiZuLxoRcPOgHLYsLHig5BA2wItHfSG1kaCSVFgKvxZrgK
TpS9sgGMMpueT1582PMkRiI6+eyp6tp6muCgjRsUMHIcq1YFIxgZFwyshmNOOT09XZx8y0tw+VJz
nhi3XHfUgGhNuqPgF7HMIZSZV/Mh322vhJjotacYjK7RnmcRiaOdOhOcK1rpaPSDH5/F8dPncPvn
BghIfcMvi96TjHEoKFgCFgpx/1GIulXFq6YsZ2nA0kAsNeB+/7y5yrfcF4w3VuxivIej9JLKHLBM
apq/eIaVMKo/dnnrGk4ddN1rB+3R6Oiw0UgQraW6afwoNNI60Vc/rBEKlEqJiXhibEoWm+QswzGR
wGISdQ1Y5Rl1FccdAy5z+YuhcDSMQv8NHUfLn6yR/JRx/JTxkoBMk2H5lHgyHNWnXqioMjMmzj0N
sZ+PdoW3tbYgMSstBXMnjMDfj500xohSrHsuQzLwpR0uPr2TRap/6uGssKUBSwOR14D+neT3V/4i
z80/RZLHVxPin4DfXgTnmFnocx4A6e4PQobDQQum2qnHYbO3OnDy0zo6wdW9jDE+cmhWNPr4MGtK
fGTWksLSQDfTgPreqf5YZ4PaA2eToG8ZgpUkUIMQKFyw/OMantVMGedVVbZj1WfxVlUN7rpuXGxl
5hI2rWtGxa/GmSLGNg8WN0sDF6UGjN4/ny90hLVEvLT/QdPVS85htWVhgjIn+ngJq6cRtBBBIcSW
m7Fo2okhHbzBj5Rie7f6FK6/4hIM7ZduqixjQtGK1ReVnk88KFEvkxXuWg3I17xrpbg4uJu9f2bx
EdYKz1v4IcmS6GGkdGq8rDVGacxCHy9xJZ4M+xGn2ycnJiSRsdAOmkok/dsWXncV+Pa+T2pOicx1
rSJU7p5FzxbOex6k25eHlYGwNaDWmbCJWQRC0gCXgWxiQyIQABLx0P77hyVRaIWoy3CwdGbOLM0s
XtLxly7hesLTRqeOJ9Chd0m09UEcWPjZhQYyGq1oam5ES0vsDmEQVczDCuiLQTUaen9PKAorD5YG
LA0EpgGtbeAPR39OtCsM5PQEguOPZlemR2o3eDvdiRGqE307aqvZECfREem2D45Xic1zdefPge+2
iKVjm+Hdg5DFLmuIDLNkHKcLu6LU+FjmwuJ18WnAVekuvqzHNMeyDVCY6qJ0QQEoWgKv5kCL6G6b
/iJlNFgxDXzETwjOQfs0+NBC1h0f+mS7ZvxldCtTKz49+2kI5MJH8ehseJDzKnVnqq6aMBhHsRn0
MChOcOvRQzXgXpOv1SGz+hKN7MeSVzTk7w40Td5nddyJikG89pQdtVUQfvrj1bZ0925HFxWbjQ8q
FDrmo0RoIrxPem+0ttrQnNYVO6/Vl08Wu3yymGq6DKvpHEdOgOlhtSTrb0/VAF+92lPzFot8yfco
XpUo5ZJyKjrhJF20D2gXog7FFR/fHpZa5q5rJOXeTgfaaMltEh1Y2LV3LwWgge5ZzAFkrAeBWGXU
gwozjrLC9Yp+zoeXYGo7yn7nz/qQ8NJU2BHtHXxHeDs6eHiK79P4yYbH+H4NnKNb8r761a+GzcA3
AWcDw4+QSteJ78VErUFeiVaEpQFLA91RA/S6yzfedPTZ4NU3a1o43j2HaoDYHXUUA5k7aU4jgY5E
7+hoQ6ujg065ra4hK9KGmtN8TV20nbOgAikvYVhYHle1IT8jOmuSi4bLw8CWExpQdWapxNKAkQZ6
yHvjaieM8ijjnO0GBTWD0kPyLrMX5WdHhwNJCcnaoYUOGp4aOLA/WmmpLd9ZEX0nGzM9J7N4Llz5
U3BcZe7yKIkXu9dMl9HSi1UG0dJs7OjGus6EmDMWU4pKz6DntSVuiOwvVrR26mE4Olpo7rsZTXTR
nK03HT3OBoMuZYqy88dANj5cG0gUGXRJpeJ7JbqgLm6Pme4ubq1YufelAfleGb50vhBjkqa+6VJS
dQFVYEI4MV3E4jOvgeUl9lDt7Q60d7bT1gw6Ip3mN8SBhXY67jY5Jdarp1xVgLTgKs0ANBIMbADk
egwI6dPjXeipelLrTY8pvBhlxEh3XE88Kk6MZPHDRooqwUhMUaOlqPp0Ced8uucudAkeQUnMI9IK
6DTQ1mrna/poaI//0pLb5sYmGquiyQ3nWlwdfBSDsrKqLJw1QdQOGe+ndkgw6xmc7e2W+lLrgvXC
B1+ERu8cU1FfOKljGdd1enZxlqIooprlRNMJN3AyHxJJDWtQnvmWcdZTrwEHHTOlDUVpe6MS6+rr
SMG0acN5IJUeIbphtTYYcdIXtD94IxrRiXPUHUPpzgOoJX2yK388F7lFR7RAl/xl3ai/LhEiikzj
ty5EMdMRIq3XnT7si03XvHMsoeCsZ08J3Itw5UCf7jKAaoILWsmoUZySbHkVDdDt4LTUNok6FolJ
SbA11jeKAojetar6wuGwWqCKbF7xKq4ZjoofO7/j5Kso3robY/9tFgbQhsnhM/ORjxGxE+Ci4qTW
A854fNWF+C0Kvd60BtdsSao7H12tX2+53bK5fcb5YFwpPz91tCjogjBdx+vmYfmAtN59kJzaG3zj
Et/hZ+PltrwG12bTtopHVklad0YUoSzHgBnoCttd1AFTYEB7RSn+4xc1mDvxBIpLDgGZE7DqO7fj
s9/9DCVH65E5bCa+/9j3MHUIzenYq7HjJ49ge1ml4JEzczl+mL8QIx0V2PAfv8OMFZOwZ91GnLjx
X9H4tz8KmLXz87BqyxO45qODONg2CrMmDkFF6Qb8omoERn+0HXuOEhjx2LgpH5PYulguTA0EXZHC
5Ndd0bX3R4ztcxaE2vjkIH/OP4Q/CuGlK20GE/Jo5L1MgMZKNhUeostIRRpnlAeYkmx5jTWQlpaJ
BOph8GhUAi2/TWyhc6dsthS6xi/SqjQoNJdMvtIYSKs4GjjLJX9aTDB/HW0NqDy6C8XlY1G0ZSPm
DT6K4oIClE/8FrZsLsDVNWXI/+83BckjTywlg9Ef+UVbsGXjGjSVbUXx3ipKa8bxyv0oIIPRnLsI
S2fNxLIFEwTOvFV3Y8qgVNSfJqNRc0HEtTUcx9E92/HRxHxs3lyI3IYyPPLMYZEWnT+sT/mLDoeu
pSrLn5+W868B5/tl9JoJFXaFHo2EMc+JEbQ0gNzDUHsZnrAGeWMATyBzxn5TIkbIL6d4AeAd4XwS
uoOe7Tz/3UZnpKemplOzbKDsgKVmRar4OsWqSYKmV4QHp8BWPnig+AnkoGjDMkykzsQld8/Dnvxe
eGjZLGQR1uIlOSjb9U/UYRr6T1+H/LlTMWt8Fhpqm3Elpb9zut5FO2dRETYtmyjCjv5HsWlXM+b+
yyyMpA7EOWRQfLIG29oETFmHx4gH9y2S78zB/ueOom7tVMFTA4rUX9K1S/2+9RopjhadeNaA893T
vYLxLLGRbKImO6uzrNX8FG2Dq75rYSN8rT0iQAN1uGlLysYUjGNDwTGm1F1i28lC02e8mPvmU6hs
iYnU7aBNGh20DjeyTlOu5yqGQDioXehIFFArDUldizHOFcVJffoIIeSN6G2gBh4pNF5nw9ARWXju
kdtQqI1OCbicFE1mhrp++hgtQH/tbextgsNOD7YXiuO58cyxw4TB4Og2NiKCB4ei4CKhpiiIZZGM
tQacLaSTrSvkUT88AjESkCRhYYJhbQTrzJAg5fTLDLjJu32cpgPTRDCiLQlZT28NdJDCbGQ2aA6o
gwwITYZr4+wddKZI6E5fCvqwStlXmhMuABCVol+/u7PgA/Q0Ni3Nxzufz8fO3Xuxf/9uLB9GZoFs
jss5DAyrpj4XiMsTk/us1FdCVZoa75LI8lwsGlCKX60VwbXa0VCWIpgJee5JsOOn109L0tIZRgmz
V+JqKVqqmn/hVyN0+FbQWANidS33NNjkkpITaS2VGB+M5GUfxqyNYr2KXQGKcenaP8Nx4j5y2ED0
gh3HDvx/9t4GsKriShw/SV5CAgkoqIgGhYKtKPiBUlDBLYof/4Xfr0Jb0bqILVitFAu1S1epCnap
LnU3dBHXLmBV1iLtKroLXUuxVLEKpfpToWJXqIgoggaBBEjIS/I/Z+499547d+7Xy3vJS8jAy8yc
73Nm7sydO/fjUVhMr+Oqp1WCIaVpNqmF99/dBXX2bbcGqhyDOEacszq9zvCwXG+LMNpOXF5HwG5+
lbl/2tZkp0uG9bMwXALzSQyLQr2k2lEfKEYyBRIdmwicKOgDTBRDNWX8fOki6NevLz68YcVDfZ3J
JpJlGS0J57LEuy3GLefF2po0oKSNbmKNObxaoaFlvaQrXl7Ca1Clg2DGtDGwadFMuGbcNTD9Xz+A
McMqYPczD8Drh1OAVFCS4otayNL/YhjTpwYWzLwJntx6CIpFzLjMWouVDq5lOw+LlYypSa/VGaw2
pJMIq86Uep3hcfOW8sfV0xI6tlHmLZHXWrzSXi6zbmxGNWaaW98MZV7KdXkSl7ys65P9lXBevMQm
12VzkBApiOsSZhROz6vJYyJZ2RJp5mF1LJ/r7SWXz/EVvPzyy82f4Ff7bpt2B3y4610VNJMjvBIh
p4MS07h4QUtF1WjccowLqrtSWrWEmxS1uE9RXk6bIGn8RGLaLgdbIWNCd3XIEPljEiyntTHSbl03
2c34TH1oKb9uU7brbB/Jlf5yPdv6siVP2q3LlH5QX/SOnkzNByPnDLdylp+s3fXjmWUynOt8vHNd
5jTgimECyzq3pDaVXZ8NnAxyTKACAR2A0+fNst1jIg7eNBZkFluTtuSwvXv3Qo8ePZSPZMeGDRt8
QqR9I0aMUPjPnzUCSoq74N1TFCfcCF++/JdQXFyM70mXF++tg0iXyAIJLjuUhOs8Tt1pF245B4MF
hjlEEtm65VQpThKsMoXloE0LpnFzjonVWehuAxenx4hpdThxEE6HMz3hdVwQD8EpSV4L4v0r8SRb
2k2Uuj6dXkpjnOSxZIpgSIY8KLPNlOv+Sz/IVKbV4YzT4UxvuWkNilY5XBbLY1pTLmXreoneOnnh
Y0vqU1hbpIVnWVIOlRluEwdkrg7rWG5hWzM75VJ0gHYG6/2W4U7OchUgXHiQ3wyXcWKYowcLDCOb
VBwlsr2V0YcmnDAKqT9gg6Q+/aQa1v7u99zDHHfCgsIBYWK9znAn54b3NBphVURVZtESoY/IQrWD
v0Exk3B2Q3WkgF6elJ5lBuVhuohH6otsS6FE8jE4ShfT5VMu/ZD+SzjbG+ZfFL01iLMkezAJ6ANE
FaaL8SxN2s2wJHmUrmBZfHCbKBgXdUwznZRBPDRI0d/oZIUxSo+UEy7V1JZJYiz5k/BJC/OmjFsX
6vIUhozuhi2cfvu34YH750IzPrQRlGQAgmgsuGwILNN/K7MaXqIVA555eQQmaXQPY5tWTJ2CYqbH
jehMtGy8jtfrRCdlSlkSTnQSR3VTMtHEslvzzWSnlC3LJjvaCmayK5b/msG6/3qdyLl9dBzDWaSF
55o5Jxo9mewmGkmr0+i26PSSV9cXXPfbFkxLGG0EcNhtONYdUIAgF++VFUCugV1uDZFR1RQzPe4Z
CW5DpgLVBtbYRRFONTY2woABn4PKvt73JpmcD7Jbdny9P1OTkCLVNHb7yDMuG8QUQSryHi7jJeNh
MlzSMt4E0+VE1VkW5yRT52Ec51JvFC3zyENT8jO+PeXS/ij/JS37aILpcmRdllmGP+ejxo9hiNQb
JFPSMF/ucj6SuXdQnWFhWiN8RXEsMVCKT00kh21bMF1LYid5g9om0Jc8RBTS60PsUZxCXfjuu9uU
mZV9T4ltblAgZLBUh6EZxPrvke2ZWFSDqz8emvZSoVjwj232xoGhbq7TuxhvieToP0kRhpN0pjLb
QDmnKLtdOi65Z9AupH2UMvGfeaI81NtFxlUdElq7RsmTeLYhk3aTcrJXpmOXj1+3LyWV73ZDKc8S
zRDPuGFUwHYgMtQUogslMEqPAuZf20RZHA+v/KK7a6mR6D2FAwcOgLq6Otiy+e1ICdT5ubNyHsmk
Zo3sN1C03tahSBKT+DGzbCd6KZ/KdODwASblRR9Q3nhIuVKOlyq4JvmJKkwG+xEsrfUx0v4w26N8
M1nO/rJcq92sY4fazmpD65ggXJKUxG6T3CT87IdJjhmWzBdXBvVriofGzyABpqIVOYtboFxxXGJ+
rqtc5zASGftzVFslia3HpDyvqH4sAl94+PBh+LdHFuOtpbWxTA8KXBDc28SuCjpW9OZzse2rFOQ7
wzmXXplgjJc4OfBY+KCoBcFZqj+XeiQ2CC5pZJltJFhSXimntctBtjKcc2mXCcZ4ieOYSBjTMY7r
SXOTTJIRBI8jP5hXDtG6JMJF4XWeoLq//yrJLN6gSnH42ZQCh5z5FTSAOMikDOBBcQyCZ6Ci1VnI
dvpZl6lwT+Prf/dN9WGNggLrwbU4zsWhieWZ04bcsg4gFns+EUXFJAifFE4+J+EJouXYheF1XFSd
ZXKu0zM8n/IoG4PwSeHkcxKeIFqOXRhex0XVWSbnOj3Dg3M6fuWxy8dzMEdcjJJsi/NJlSqVQEWt
SoTy0fuU+gQEtpHOGhajTHG6jnypq8WwChVGFFeEqWJ8LoFSQZE/gC032m42ty19IvlSS1igfUyd
gA4agZCO0kE9br9uYVtFNlfLxhSHmwqkK1ZyCRW/IyQWcydRQATow670jXBaJafo++CFRYVQUlIK
9fXZfMue23jSDr6ma52Z0CayhVWzmedsRXJ1ljsj0BmB8AjQgdSaIyTq86iUuu2D2jFY4hxgSMGS
LcXrEonZGjM0MSYmR71TQCZJqMnogFW6SzbT1NichuYmnCzwNUqpwmK85bb5KBQ240eYmpqgS5cu
mco18FkTgmomp62o4DaWvLbbudIwhLAT1BmBvIyAfWx7jmtpqD7EO4SSCMuSTtK4J5Mag6eqOCQb
Yd3hxUNrVZiY9XLdQNoBQXH3rX2u4wpDrTLowT5aaRBBQyN+HKKBA+ljiQnwt5bxTMA5G2qpvphm
dZK1kwhwfzi2DuR20jg+M90rA9xukoTa0ASXNDqe6snaXnHobIEiJEKWpU2dZVMEaL+7pKgEinGl
0Yife1UP9zUDLl0KMl++mBTx5ScXJxvK6jAOxCm41J2lYykCVn9IOmgcSxHKH19jj9K2yUEHN8FR
li5Oc9Th5oLdVRw2hvsmHJtQk9dZTR4BumuqsJDWF3gXFf7DEr0+BKcN0weGksvXOOyOoaDczKIx
nQbX2Dqrx1gEOjtC6zc4H4dJYx+XPiYdkfHQwAXbNCXB+cP2Ij3CFBuCFFoFT+B9wXSpfKhOQLwI
YAgb8aWF9OW+lBV9eiOV+62IaCnUQLIh+Bqk1XBx9id4A5x0mS9jRVuRKwq512LZ5/oahmN7mEbG
gWFMo8uVcCrr9O7lAJ0yuq7LkhyWjdx+FibIbgmXMvKlrPsp7Q3Dsf1ME8ZHtBLPvJyzDK6H0TJN
UK7LknQkV8dLXWE4V47br11Ya5ZIvzvyW2OCO/irEqHVg390TNi2KZgYNwjOrsiyImeEzRuQcbxk
DANIMwKzfMkcR5fki0Mv5WerjKMDNNP0gKEkewppMCrCCaOstCyBDtkQ3gEnXAi3uuQnDr0eLiWX
WNlIrIdhnDOccgmjsqwznQnGuLi5c8DEZYhN5zvKYnPmE6EpxgzjXNorYVSWdaYzwRgXN8+GDJOu
lsltizbnY9/kjZgQDGi977snUGLcCBdvkGoGtSyuZpnB0CwZHawgKxiKSQEGvYk2xHECST39n7+A
pY8+AX/ZtlMpCAsazXQSHz3zeYPiNr4Xzp5J2QTT5Zvx7qSV3D7W7M9Zt65T2iVxsuyXZkFYZhCe
4SyL6blOOcOYNmnO/K5MirNXShI9LMcrwW27KDzxmWjYTl1uVJ35wmRKnCwHyWaZQXiGsyym5zrl
DGPapDnzs0wTP+sJo8FoK9Ygmig9jCchJhnugG60EIFaZ1NkBLPskvIJZdJhjSPuGMISnfHFRWHc
qeIdt0guJ9Kn66C6CU48bJ/Ow/IcGpQhzFBonZfs1Y89IgyTbcKzXKXEwM94ksuyZZnxzO/LlZ0Y
ZTS2qJA++Iqufevmb8CA/v19tASIEkiOW3RWHvSX6YLxtiBBwA4SSJaZxIJxl/HSRNnNMky5qSFN
dBJG+qJ0ckNxLvnDypnYEyYvLs4fc38bBcny83opGc+5F5tZLSr+JqncbmG8ZKP8meSYYGEyTfRJ
YZn3C/eY0XVGtQfjOdf5ccTwgxSE4CYcwWS/ojL/rPEnKo6K2ySaJEnRWNeTyY8AUTqrp67zsFru
Xx7ikIrJHkluwkuYLDOfDpP1qNiSDKKhKbCosAivSuGm+H8+/TTujBfCBRcMZh0qj3JWCbJbhDpv
YONw9GzpceQSjUy6kzo+qi5lRZUtWZZ+qTeKryV40sM/7wHUEqlmXlePhddjZ+aKByVZYfKicGH4
KAskbybtlimPHs8oOzPF63osf73HSTzZfh6SJeOny4nCefHaAa8LM9QDxw4Prddur04PYaQvxCv5
fWXEy/4g8RJOWh1ZyBOWWIbkZ5iJz5FrQiLMhNdl6/Kj6gGqrMEdVxgpfAic2qpw8o2TFG1ZaUkg
j4swdwi90aXx1slFeEBd+f6SlCWdNgXNz50pxF3GkQSpN5bEdC1U79kFe6oPQF3abWCTzdI/kq3H
MggWy44IojC/dLssUZm3I5vi1WnuT0ybSS7t9upKLo3bi3MpQeohuF63aLPvH8kN88tsh2VNS/56
dWbLL0uOVzZbafU18kf3yUzPfEFt4eLDS37fdP3h/MH6pZwoH1hHXLog2cQfVwbr1HP6CJMVFWwL
ejX6zbfcBj179sKGKYIZ371dp1d1UkpG8YCWbOhIRq0bwLoJTjZwADhIXNf5nHrtZrjlmpmw3QFY
hYrBY+G+u6fDkF76N8CFn+j35qXjYWb93bD2tqGaBHN166oqmL5gtUJatlXAt36yFCYO7QU1by0B
NAWeeWEq9LDZXfstvVRn36ymaobarcvgmulroOrZZTC4m1fv5ofHoH3zYe3MePa5+rxyuObVbw1Q
rj1M1ZJcHpTUN2S9ZXKd/okxzEZiv00xM8GYntuN7cmGLSZ9Um7u282jDStB7day2FPMuPnceErd
5rKMNccqCb8jldzSXGB5Dk1AIaw3S1viyiM1ki9ArQLL9ice1sH8XJcyJJ2E62WaKOhJcPrkayHO
E6lp374FBg06E3784/k6bXDdblXdEGkgl6lzcScggS7cLN6ElwEhedxBWL/OQ3XGWc+8A4yaUQXf
GXY8HGkohvRnb8KCmfNh5uJhsPYfRnoMYdlsa0FBBXQv7arRmA+Yum0r1IQxdlYV3HzpIChq2A1r
H5oOP511F5yz6mfQtxht7w5gflkLnRFYathfyxZXF/vE/lL9lFGz4YcFlSquJrzH8CxVpH6vSLdt
vPDoGsuMpjRT6O3GVBwTqmeqIy4f6SLaOO0m7WEbWQ/X2Yfg3O0bwTTuGBgkn+FhMoJwmfMG267H
L0h3GDzIriA4yyKrsBXVsch9SucJbB86gJmJ5NgHtM4v65KF6ckWopF1gskkZTCc6F0498NgO5gv
Tk4TR0FRSskvPOusQbD2hXWw6U//Lw5vCE1wJyCmsAAE4U08ok2ULW6QvDok/DBSfm7AGdCrdyVU
VvaGfkOuhO/cPABg7V/gAEmp3QZL77wFxowZg7/xMHfZy1CnpOO740u6Qs0fn4MHZoyHyy+/HMZM
mgGrtiouRSFtTB+hb5JUwLALhkB5aQpKyyth3Iwfw/iRw8C5oblmFzy3dK4la8wkWPryLlsTmbEO
7pw03rZjElSt3Ax4dUsl0oMve8FUBy8vvRPGjJ8LW1FdzfsbYeO2GoXZtvIBtH0VLJs7Ce1cavmm
MK3zR7aNjEuY9rh0YTKicCYdJpgux0Rjgul8sk6DQvIUfiwllpfAhmD/vDYF08W1joxyDQuTF4Zj
bZJGHvuMD8qZT7aT1Y9d2yQv00tYy8pePVK+yQ+JZ70mmDwWiU7KkvQSzvJ8OQorwE3wwiLMcV+j
8Ctf+zr8bPGj0NRkvUaEBEqhLIDhJpxFY/Ex3ktvBUbCZNmkg+UE4Rivy9HrxE/rhA8//hjqag9A
dXU17Ni8Cn6yeDsMuP6LeJmoGpZ++1ZYvqkMZsyvgn+8bRS89Ni9cPtTb6s4NDeXQvO238KfT58C
jzxSBTeeuhmqvjMNNuz3x6n8lMHwueaDcO+1l8N3718Cq15+HXbVnwG33TsFTu9C9MX4ewn+feMJ
MG/hQpgxFmD5nAdhG81Q6W3ww1vnwTtn3wgLlyyBe6cOgFUP3Q1v1rCerrjiScPGqpvh3l9she/O
/x4MKsdJY89G2PDRAWVrQ+17sP7xBfDYhwNg6jcuAr6SZYoJxUUmpiEYlymXdVUReK5zrvMR3A/z
9hPutEzHspLmzK/nLCcIbsIzjPIoPklrpncHBZbFPMF1b9yJzpy8sWR5TM91Hpzdulcaw5mPsH6Y
V1e22k1aInXKMtMwTK8TnBLj9ZzpTTQuzvUvTB7Tsw6uc85wlkFwCdPLEm+SIemD8AyXsnS+qLqU
oZdplYGzBk48RdaeRhe89HL0aB1OGkEdUxfBdWshx7XwXJ6lJNUTLjkOls7y186bCms9xANg4eQh
QJeUlu8GmLbkARjXD78tMnQILKx9B6YvXgcHJg5CjiO4eLgeHpo5Tu1DDMTJ4O0xU2Hd5j0wfGRv
j0ToNRx+9uwSWLNyJfx6zXJYsHa5wvcZNQ0W3DvevixVAfP++TYYjgM+9J0JS1dXwUFaTqQq4MvT
ZsEZ/9+VUJmqg101ZyJwm+K3/myHh77/DdiyBWD2Y7+C0ZW8F0OCigXdWHjyZzNBs0zg87PIg1B+
WpevViU5BnPjQ2btZrLbBMuNzZ1Sk0WgkFYZ+I9WL7jWgBQ+5KdSUVHC14i0ozbGYR/GzF6i9jTo
tfI125+H6bMWwy9/twPu6HsUsYNhSKX1MSoKRv+LLgN4/CnYXnsbFB89DBXjLnY2rgFOhkvw7uSl
b30IoE0addW74NNUJVw5aab6peuq4a3/eQJmLVoED646H2YPIF1XwJk0zlNKFQMXIdUb+h73Adw5
bgzgHGanAZ7pYMsWC/PXvQdw0ujFRE6eJlsnjGnVCYPOYFqSmJ8GH0tUy+S1xJb85uUDjnKZuJ4s
bhx3KSlJmfl50uB6fBnsTxQH+0d0yXyUkpPbJ7mP7TJNGviQBhTxnkYTvuq2CN9gWFQc55ZbCh42
oq+9ZcO6AbY6lL0ho0gyb3RXavIS7WmceMIJUF7eA3r06AGVQ78MN+KWxhsfWHsBAFvgY3ebAj79
6zvIcSmciiN6CsNS88d3nL0FgEPwLp7tn35aT58hb6+4CW76yuNAOxuUUqW9YOj46XBzH4B3du6z
gLjeME3PdduWwa3zlsOX5uBlrbVrYe3zVdAHyHJOFTBnxbMwb2wFLJ/1I9jKmy6Mbue5dVC3Tf9o
H6ETsTEfbm3iBrVbZgOy8EdZrtcJmEeOtkl080MpXZ4qwkmjuLgYSvCbS3ixyppBSor5cke0ofGa
0qJyNmRMfSJaVRYprD0bS2ApnPnFPlDzyQEoP2MUjELgnLuWwjZ8rmLP1jVw5/z1UDH2YvuMHc/o
t9NKYSs+c1ELr694EOiG2jHnVfpsO/2CCQhbDnc8vAZ2oaza2mp4fdWDsBgXCFeMON1HLwHpI7QK
Aeh9cgXAgV2wct49asXx6X6eHcqhR7dyGP7tH+O6aAvepbVOTGRSUme5Y0XAf7QRRB1XflQHcl13
rs0HkA4U24Su4IkBrTLoalQqlcKH/PAPXa8q6erc3xMgkRoxqOFMcDoDsVcZSqKJJkBVlsG0EV6C
HxCRqbgcJ4Plq2Hb9++HHyyZDZ9NnQe3TrT2ICqGTYZHpg+3yfHiVp9h8N7S6TBugQUaM2MhjHP2
FFypvYbfBgtnAdw1fz7c9IwLHzttPnwLn9Oo24ownBNMqXzQVXD9YNwHuXUikJo+g4fhSmMTzLvp
SfjFQloF2rf9lg6Cu+dNgImz58HTX70IzhHCaNov7yIAncUOEoGAY08dUrk8rgL0tjiqcW2OS9di
gzoFhEUAu0FxSTFejSpWbw8pqDztzOY0Xug/uc+p8Pof1yFrUENRB8KEmepKRjIj0OJrB3/ramsh
nSpVt8v6zU3jyqEOLzmVA95NG5GI9hA0NhZBtx7l/KhIBI+F9tiAK5vadJA9scR1ErXrCFjHHK/W
rT0fe5WBfln1lhxz9jEdeMznMnhStyznUuexLXvv3r3q8jxtG9Bvw4YNvoDIPaoRI0Yo/PnDr4IT
TjgRefDdU3hFKqUe2sDvg3fv4b9G75VInZMbV2AYpPqupyKI2kextNzZljYYnMI9kTC8ZCFafuZb
wqPLHhtS5VAeOUFFy+ykaG8R4OMI7baLcmrgycN8gkcMkjqJ7y3hTaKHaNlG62qEVUP9rnNJBXbS
5ygCqgviJFNSivuxuMmbKijAa1WpAlx+0OjEDWnSjqzWfy/Sw+KpeOk6a3kQAdX8aEdnO+VBY4Sa
QKsLNX5iU9lv99boZRuKA1OBqZ0lXmP1VCUdlYN4g+AeYRlUrMvYFqO0JQNRnSw5iQDtZTTTIxn4
a0wfhcLGRnzOmGYRvF5ldRjqHHpy9yacZnXICMI/na+z3r4j4DRy+3YjsfXkd2v6ruuzjjKaOFRy
DjqTWUhk/beJk2RSMPOZYGwI50ybnVz5qUTTn9zoyI6lx6YUeudUGq9GNeKPhvpC+jZ4Md5ue+gQ
Pc0QkEztqPqWqYMFyOgEt3EEuBGTtFkS2jZ2r0Oo5zYSzhhAvnEVm8nbUt6akKYVSbj8aWinSvL4
5wANBZOxBjIHZNGTZLcU13ZHSBsXZPyS+t/GpsdWj3dP4cxOK9/GdBpfJ0IPImD68IOd+De4Y3BT
Uli4THydqT1EoKN25lzGPg97OTaj25JuSUUhsbkaf1aO6qRG2PQ4GmX2rEcu2z9MNsXOjZ+7Ugrj
ab84ujxFv0L8pkZTYzPtaRRCU7oJ6vBp4qjkhimKshOfnxFIelDnpxe5t6rt40QWqONNmoJltb8R
FABJG0Sj4B3tSJb+xA5CSIRIXpAcqUuWQ8S1c1QhvaSQ3nKL7uJ0ga9Hxz/0VDg0y4ff/F56whMU
Tz9bJ6RVI+BpJU1zZ6NpAcmjKrUN/+w2xKqxxZhMWS/bm6k5N7nH9CxE0jKO+fQ6w/MtRzvJVJ+5
PkCI4SyA8yBSxBvE8g0LQVztHa5WGjRRYGpCZ1P0eDg0FUDaBsZ3UO9wsh5fSidlNiMQ1AZB8Gzq
7pSVnQhwW2Fuvm1KqKERjOkJLMuCzCma8AQzjISKh+EmPkdoGxbQPuu/ssGykm1uiVnsL8nicpA8
ic+G7iA9bQenZzca8SWFzXhFKt3QgK/MS3UB+pxf3ZGQy1OIp/7rhkQGipyhepwAt53jnZo7IxAd
Ae7hbv/mh52ieXNFwTYFyY/CB/HhUatOkYPx0QNmGG/r4Mzeu+0XzwqmJ2lcJk5ZtuuhE7lOTzzt
PzXjPsbRhqNqP6MZ76DCt9w2QzG+hIrcra+vD/GQm6djBibE8U7UMRMBfx9v+0kjd8F3Jw19sMyW
zlzJZfvcRwEIokYm/KM2ppmkA+du+0U72Uiv984wNeMqg16OniqmfQ3M0034sEYDvrQQ383UBScP
c/IfTGa6TmhnBNpzBPz9JY1bxgAAQABJREFUvONPGn6fs9OCuZLrtU62T+ek4Y2NXqvF1yRlko4e
xTehp+hW20LoUloKhRToo/iUX7F9622wUNUkwehOTJ5GgA5ePoBbw8TW1tcaPnV0Hbk4tklmLuRG
tUVb6IyyqX3j8TlwvJTZhKNIAa441EeY8BoVThhNoWs6U0PQ4GCCt+8AdTzrW7ONWnNyylVLtWa8
cuVDErkdyF+DK2GXcFRv9XVZHyBJMFtAazC+VU/2gk0vxBcVqo/1oYnNNGnQBUD6YHhpF/vV24qX
AmdyggVH4ZmuM+9YEYh7QIX1nXyOSHu1O59jmsS2oHElqN/RQ4G2/CASTb0i89H6ABpXa1TzwQaz
n0X0jAai1B1UOHvgZSrc4sAPbJR04c+d5q/xZpc6oW0VAfPilI/itrKqU2/HiQCNRVHjkd3fWtTt
WsTcccId4Ekjzsz0+QxcXuBDfvT9JVxRlJZFfYBJSqNG7AyyjMixWnbO8o7VAHT6ncUI4LjizA9U
cCoxdCQcj4g8IUsMI1pIwkaxYVyXYhknYbkv0222dMMBLjjwDipcZNTX1+FX7YrxRVT4tluVTMZK
w7JveNh1R6m5s9zWEeC+oedkF8Pa2sZO/e0vAvLW2XiThbXKlbTxxiVPL/WweCqtHEJdt6xT2fq1
1UlaQ0NaTRr0jXB6Ojy19Gf/Ag34lN8nn3yiEEmilY3Bnr4m9Ze//AW6desGvXv3hlNPPTWJCe2C
Vt4W2C4MzshIegum7OwZCelkOuYiIAZ+0X1oUkjenYSAiDgSpdLsFIjBU4mQkEM0uyFC05YrI3qz
bQG+rDCFkwblhTSg8S+TMLSEl/R99NFH8Pzzz8OqVavg1VdfzcSETp7OCHRGoF1GwBoVrVUDOsCD
pJ0rOMOEf0zPuUAlKvLY7F0kO9BEsjIntvVRxj8WxnWbhMGtnXM7FOGlqVQKP/dKf+hpQXqLYSap
pWeX9BQ6PXSyb9++xCudTOzNWx6czevQuFJsDychDF8lqRrKC6OGcyCdhc4ItCACPCq38chke6BP
BGSdYxlW2FrXYQ+FC45ZItmOTE8lpoCWkAUspRx/WyI7i7yF+OA3LQ7oofKmdDPNFfhYOI5AdK0q
aSJBlHi1YdWdJogljp5Cp4mHeA8dOoRv3MWvQ2Uz1W6GW8aMgTHab/yMKthcTUNyeNq8dDyMefj1
cKKY2D2b18B/v/axWneryZY6jf3b+oubYNxVP4NPHdin8PBXr4KrbnoM9iPMov8U/uWqq+C2/3wb
3lp0OVz+L68p+FtLroHLF1nlhv1vwzNP/Q4+bbB4iC/uj2zRaSWMyrKubIrpe0cg02PTHuvmdmi7
YUqfJMz2IRSHFdPIEps/ULA1KTkRoILq5yEMSVFKJsnVfppHjE4qPtf0xUXF0KWkC5TR113p8pT1
cQ18jUjCSYMPGDKYy5RTI/JkEseZrl27KnripT2NrCf7jHwUThIrnnwMHnvsSVhSNQtO37IaZi7e
EENdOVR0SXJ3WbDIfevnw09f3KsI9AOg/4XjMHC/he0Hbf7qrfDbGgTt/j38BWGKHmG/RvTVw/vD
KaNmw+wxvP+DNgJ9rhcg/dErsGjxv8JH0fOhkkly+Uf8XOZcwqhMSeIsSOff9hsBGqraIlEv8iY/
xMYjIhDnFZHdGo/iUSGSdKZyoFV4koY4/gWStTkC30+IX3ct7lJCr0V39zRo0I5KcnLQaXm1wXLi
ThzHH388lJeXq9XOqFGjEk04ug1BdXp/7+cGnAG9eldCZWVv6DfkSvjOzQMA1v4FDhBT7TZYeuct
9mpkPMxd9rK6VESoVElXqPnjc/DADFxx0Gpl0gxYtVVxEdrmnWTz3gLLXt6lwHXbVsKMuctg3aoq
xN0Czy2fC9OfQdTqmTD+zpVQqx0Fpf3PgQHNNfDatmrFv2fzy1DTfRgMLtgNr2y1YNXbNiFuGJxf
WQo172+EjdtwVhGJdF4/fTlCamDmuEmwcpv1rpnqzavgzkn2agvtX/n6HsXVnN4G998yF9asWwGT
7JXYLVWrrJgIuZ1FjgCNXu38x660aW53fu0YCDKJyaJHqCAJ8eA8eHPu4WKgKfcQxqvQdEGi2kMi
O6nb06fB0/S519/97nfw+9//Hh588EFlP08MQc4ETQYmviBaKbt79+7qjimiPemkk3IyadCz7h9+
/DHU1R6A6upq2IGD6E8Wb4cB138RekA1LP32rbB8UxnMmF8F86ZdCusfnwPfXbHVNhNXGdvXwp9P
nwKPPFIFkyu3wILp34GNat44AMuId9dQmLdwIcy+vic8PucmWLWjDt87Xwtb1j8O8xa8DmMnXwfn
fPFqmDAYRQ6eALd/bQioRyn5aCBNpX3hMpzHfrvhfaX3zd+shcHfnAJTrquA1essW9595SVoHjwa
KnH1VLMHJ43dvCxRLJA68XyYopQAjJ32TRh2Yimk96yBiTMXwDsDJ8P8hfNh8sD3YdGsG2DNLlyK
1B2B97avh3+atwrGzqmCqtnXw/bVC+C/tppfbMadnHNL6zH0V7bXMeR2TlzFWCYNp4k+d31Rk2xS
LgMTgZfSZFmKyNcyPaehntXAS1M0exQOHjwYzjrrLNi5c6e6zESGhw32vJKI62CYLJJBexrDhw/H
5U+xunvq6NGjcUXHpqOLS2vnTYVx13wFJk6cCFNxEMUpA2ZMHgJ129bC8t0A05Y8AOOGDoHh42fC
wskDYPvidfYZ9xGAiuvhoZnjYODAITDp/iV4rr8b1m3eg7zPw+PIe/NdN8K5ffvCRRNvgQkVACte
eNexbdoji2HmpNHQf8BwuPKCPlAxZDSMHjoQirDneBZ3BeVwAc4aNb/9M65y9sA6XFT8zfkD4Ywv
XgHNazfBfrTmtdU1MOxvz8J3v1Aqx591SUpV8U+qRz+4+soLsDQArv4/OLn0SMG7a57Gg3MMPHLv
JBg6aChMuvcRrAEs+w1ORJYgGDNnAUwcOQQGj74BbkT7D+IZBXVs/Ycg5+yovXV8sj1bicYH/pFM
Hi8YFpUzTxgd0VBiGqvmrzMN4/M/R4+s/7FMjexnkQSx1EQTRekReFFUcvW6exRFq207Cup5Viop
7QL05hB6YSHZnnrppZfUkqMUX3nLiSYG02DPMJ44qM5l5jXlUXQ0aQ0ZMgRee+01GDBgAJx//vmJ
91hMehmGwz6Mmb0EvjPseHUHQM3252H6rMXwy9/tgDv60iQ1GIbgJR9O/S+6DODxp2B77W1QjN9O
rxh3Ma5IOJ0Ml+CKYelbH0K6hzXBLZ4+ERYzGnNcMGAi3Bi4eKAr9wiB6tPOwKuaxW0bqLwQ9S55
Fd7cXA6bcGr6Fm5ZdOkxAvcrfgQbNw8DuiF50rkn49/gVNdAuMOQpluxaF6hb7+PGgm9CaxSbxiJ
s8ZG+9MpdOnuxB5dbFxaWW1XVOa1kY3Fw8D6L0mPmbI+CHCd8ziBiEtrotNhej2O/ng01N7Zks59
x51k49jgclmW6PXs2ee3Rnqu9NIfAnKusUh6JpMkEi/h+V7u2bMXVJRX4F1TKfwqeBpS1157LdDZ
fc+ePY0TBTvEE4mcJGSZJxSm1/OwiaMMX2MyevRo9czGCy+8oO6gItj+/fuhT58+6vIVTWphOngW
NDWMGhhPOEHtnZBdPYZ+GW4csBie+AD3BPoSZAt8jJebBvaiMsCnf30H/14Kp+Kgu68ELwW9/A6k
pwyyT8wPwbtbAE4f0xNKcT8GlyEwZ8WvYGQ3vD0Wz9w/futPsLfnaQBH/oioE6EbCZSJx2eCOT3R
IijtdyFOFUtg9r1boOLS2ZZp5Z+HCQNqYP49c5BoLJzb214eWCzBf20ytR++/i1cp4y0J75a+MtG
VH1FA6rnlYr7gRYySf2UbSyeKhRZEV0GMckxlHtCI6Ii4RQpWefwiAgyqMU568mFbMuLLEpmYxN4
7WjHgiqzDAeRQFhLSDV9ssomSfESL+FZj6lXeNZr3Su6Qw/cRjhSh2ea6KjzcAZdpopKPHHIwZvK
YROClCn5JJzKffHyztVXX61krVmzRj3sRw/80Y/qn332mc7irVOroS0ysW0WzB0YcQMBzvxiH6j5
5ACUnzEKRiHBnLuWwrbqA7Bn6xq4c/56qBh7sX12jjPJ9kXw4KqtUJeuhddXPAirkX7MeZWQqjwP
eWtgzkP/DXtwdD60609w56w58MT/4mREyc6sivW3ZvMbSo8Lo65ld69UJVwyDKs1BTD8UrwMhe4U
4HLhwsuwbVCWa5PL7Svht1Fwdx7ef3cX2os3AFx8JdafgQUrNsIB3NN5feU/w1Moa8Ioaz2kwoYU
nCt5Thg9UMdMRRN8RCh0+/vjOB1suu0ztxjnzMB1m8yZZnU40yfKbaEsW/KyfAkzlk3MHkLZ3jHi
4eENqkiZQTTBcKPJsR0OlpsU47HDU7EkGUBJVeQZvetRuhFPMPGLfUX4Ylu6iyrmaSuNx95OxBOF
XG1wWaeV0WA+CaMyPS9yzjnnqLuo6Mnwbdu2weHDh+Hdd9+Fv/71r3DmmWeq1ZDOF1ZX9uClNtoI
L8EHVGQqLu8FsHw1bPv+/fCDJbPhs6k/hlsnLlckFcMmwyPTh9vkeHGrzzB4b+l0GLfAAo2ZsRDG
0W40VMIdyPvR1Hlww/pFCtlnzDS4+8pKgK1Yxf0BmU45/0qo+MVjcOvUo/D0yilwnNsuGGCqlMLg
S3AK27QNRp6DF5QQRND+F/wNwOItcMXFAx1xsuFkubz/xTCmz3JYMPMm2FP1LEwdMgn+dcanMH3B
bFiP19CoFcdMWwiThuAFt7qUExvSQ6kEV1fWlSvZ3rYhFollFKGZieGdebuOAB/izfQdbG5+1cYt
bGzBzmITBSrP+5lwL5Fb7YW4Dh/ArjtaDync1yhK4WvSX3755Wa6PEXvgKJN4qjEE0MYXdikwXxB
cghOm/JbtmyBHTt2wMd419ORI0dg2rRp0L9/f2b35awzSK6PwQCowyfT06lSKC+VwzATpvHJ9TpI
lZbjU9sM49zCIdLIy7Ypanv3m48Dz0HER61F6N0oZ1UReWAHxk2OQ7j0MNsvhDoGOQUbSRbb0m3j
FUTY3JLYCwvyqijbTjWdHhaDtXaUDJgWgrgJdDFBcAOdaC7/fiQidffs7mpLshtelxtW9yjEHqQr
COFV2kJVmpHeNjPTeNXGM0qniiPZq0evJZeQ3DdXJ43xPXr0UAsAkrNhwwYXaZdYPh3LI0aMUNDR
V1wLx/U8QW0bpHC14Rv+fFIMABZMKDlQEJzq9JM0BhEKL3mZhvhOP/10OAH3IOglirTKoEmDnucI
S3F0mvmpK1iNV4rPiwSnlLMn4qcJw/mpJYQ0qwOJCnSEuuZIMmPZRGp54icvoAmN3NOZqG5MyjKB
EYS6DEF1TBQDg4zeI45O1LOauCmC5AbBExnBu4JWFyHWIDejxbJBlgSnxoVoARZF5gbE1eDQSdOC
1BJc0jnMbVogi4Iszo5hjbj5XVt7EOrrG/ClhRlMGvpkEFUPM5t4TRMH8dBbb+l38sknq7u7aGM8
SQqT7crhLpD7wLs6rZJHI/dGzGneSJI8cgIYnUnJxrMKBQ/gsfohUnKI5GzDAoJ4OzrciYnB0TCc
gTwbIDyKDGLMUAOhD2T1QZYpHeIy43RWG0+ZImF6i85bc3mJlHHqvIkrLknelII8bzsDc29RY2MT
HMUJox5P3psbE+xp5CooUYO7vBU4ygY5AcUbfGXAqafKepS27OFJqzrPo32NJCYIk0XRYBhiNdnW
hBHC5UFRRSQPTsCPhaLVWPnjKXd0rYmsVasODDIb6fC/6nruH5tYdkiWR7mEu3L5RISxzOFS+EtM
w64Qr4J51CSR6NcRDqGns9mKcEqmYmvCqVsDm3uL9u/fh58DL8N3TpWok/yMLk9xKOQgra84klwu
ipo4WF+yPKhZg4LsdFVbTRB/MivCqMkS1mLFK4zaj1NnZQLMngmQffTZEJuAD2yHjo0ggBQiy2yp
HiZHSHsvsLMyGAE+cQxikDoSWLwDCChImZKH4RKmRNCKApGMd8QiIcN8PA4RFiwk/bUGbWby0ygI
y1LX4DRaxknWDMrBYoIxGahJzJJ97SRRi2Fiq3LPQHdOAeDDfXizUmMTPtzXEpX6RCFlheEkHZdz
M3Gw9Lg5N6Cpe2S/gVmbY50P4GA8BY910ixZ9nBQxcOFdVSGo4RPJQK8k4rGx9VQXT7l7QOgfApx
DFGEdZKn4kBbVjDJNMFYi8KFETAhNreRjHoAXSZ26aySkVihCOMjRxnBHLrseHWlR/3xa4snITdU
+WUN+Zhbi/B+KevttvgaERoxnOc0chPefJFKPY9+cZOpEUywuPLi0SXWoFzCg5VGeTXSaz5qVcsK
0oI/67/ZMMcQFuAA3P4pQGYh7Q0aFhDLF45Ge/OM7TXbL6HcqBLG3JgjOAATghD8CYreScyklW1N
IDSClLSYNAWxxaGNQxMkPx48+3Hw6aWxpbkJ757Ci3h45pFo0qBLKPLnE24ASHoqh6Wkq5MwWcE4
siHcjmDe7GFaYoGX11tTkwf1VKe3coHo8CcyJuOcvXMl2sQ6gsAslnHtMfdNtJq/7dGnRDbLRuRW
p5MQFCJ+Tj1QdtAqg2UGMiqETsXDBOeWfpOt4XIzwZItynWpTgpCONmj0JwLvLJV1IlQ0dowWZZk
+V1uhiZqDHxxoXo1elJjaWBPOrhnwpPUrnB6vVuGU7cHLHmkDirlmqoRxDXdKdo4b6bobJDDxQeD
6tgOvy2W6u2zx7sx0Urkju8g12g6dlU2MnmKEbHbWMXGgqgQcF1VEvzhgT+Ixe3DkoJ7pguzzXIB
WS/RhRdbr0GZAkm4LNu2cF+SKN1/PeJWwImDuTjPuoMZC1Qf6sPvaKTU514xZ0nvv/8+F0PzqNWC
iTkTHpOclsH8zdUyeTo3N3a4nnCsLjO6TvLUw+SkXgkXGkSRJbGVVGe0gkmEjVNymZFzpmNmhre7
nB1pd4Zn2WDRkBiS5FGxVyaBVpH8aKnW4KrT6nWpRMoUPkiSjMq2XFuko8Up2Cdr5JUNEyhLIwL4
ZkWmcQ62jGxqWyZ6dUhJcRcoKcHbbek1Im+88QY0NDTAE088AbfffruyLmglYRr8g2jZTZ0nip74
dB6WlZ3c18SksYWiSWawDI/PeHQEU2ZmhvII/8izGp+XPoCtyzZG2kSkXPexMRJz0id9y227ZRIb
NtbE6w52frtdPumfSUp7hnn9duMR1yfub87AKBgtnNWLgmKosNzRPD2OgNQGVmaXVNW12QNVOP4j
9bn0jI3KMQ5MQgW2zwG6x5njt4GG+BywLYfrLN6f042/FnEQbaa+NdIHvjNMxfg58BS+PqQYJw26
gypFQaXfF77wBfVtC5YrjWOYqQFMdEzPOfPFoSUepmf+7Oai9ZXgoOZJotXuFQEs0u9s+aa80F1B
/XwgS1MsWs1G6bbd+9k2g1jrGCYeIUZVnSMn1+0mPYpbFsZ6WFwPyXz22yVx+WTbufh4JQ6xq83M
J9tMhNNMnEWo67fXwrg2kN1htK58Mto/Kan4OH+8NrCbunxLpts+TCdz2WZeGyRVcFkN3GyOoRG5
vZRthGdaLDoxsfkkO5dJs+uBhBLGm8gWeZrZEt9q8TVJmSS6664A3zvVgK+boldOpejbFVQ45ZRT
PGeNcYRLB4LoZaNROQ5PkKzswMMbKTMduZBptkT1T+6kUq0No47MndqRwPSGrioPStU2PmZHilsg
eVK3i8mzUpSRdMKUO5OdsEeokG0QQdoqaBUTzXit6sSNwqfj2Eg+1q0xgGMdRM1cVs4xUc3jtBEX
OPfyZKtG0n1W2ipZs8JzhRSLsuxTRKcGfXTIumRlEQpy4g5J8SlDhLQI1VB/FCeMRqhvqMebqFr4
nEaLLOlkThQBpxNzAfsSdycGcVenA05O1gy3FBK1xckHtccQF+2SSwJidRVKTDsqsxO6s+wCR5br
HT1nf+2G1drXEyUmVSHBCp6GKhDz2Hge9ImM+pk1kBLSJlD8CuuUVIHlYEVROiMwITyWePmyWFMe
Kb/4chFbzbbbPts69b2/g5vWwN4n7oOGTz8UVvGk6YKivHFiiGodzQgsPuFU6D35Hqi48ApXWA5L
9Q1HcU+jDJ8K74ZvIxcb4WE6eQCyGt8ynwecoNWDCW7iD9Mrcc2479J0+AgU9ejugJvr6qAJP3Re
FPqiQYe8lQvc+7m5s6keZfNOG4lVqlifpYdj7YXaNqBJToe0QVYmbGVGBlGdYR6e9ljpMI5kOfjU
2BgbbnNbOl2eUMkD91RsAsosuDPWR3YaW46mw9Gpd9QgtcKClhZtD2zLTQoJpi5iKW8lxcFNv4FP
q74N3fBjOF1KvZ9jiGuXCoXy2zDRILz+4MdKR/OMh6H7MPpeTq4SWdIMxfhZiSK8e6qkC26C455G
4uc02DyaFHgyYVgu87r/3Q77Hn0Sjr73vlJDk8XB556H2v/6DTTi5bX8S9SVZHfKgoV8YClRVqel
onuACh0SKMtEojqkR5hgJLy36qln2SVNUxtUdWfbwIS8UmloYE9XlngROw+NdIgRko/wxCv4CSRI
GKvnPh7iS5g0rYHcQZYTAx9CKnckNMOen98HZUU4YRCiCREZ/pobcXylvWsDP8kmHaQrt8lqkNKy
brgJXox3TxVDYarYveU2TDmvKsJodBzzcM54vc7wqLzx0GE4tPYlqN++A3pOuQEadn0Eny5aChVX
jYYKfVCMEtbGeOq04viIZQ3Rq2Ww7PHYeWihTO6rlZ2UhHTutCIRYWVhmVKo0UqYINWo8qiafSNb
80Qp24HM9Njz2kExNSXqHJkmr0wab1maxFiHOWMy1eXKzlwCcqIZeOSJY8yy6+gnH0JJWVGLT6ij
vCzBwJCu1khlXbvi3VP4nWp6jUi+7WnwAcm57ORlXxgAx93wVajGieKTeVXQ9NkBKDnzDOh+zd9C
YTF/67o1QtgyHfIgSCpJdST7j5Jj/6GDzDoUWig9qKfqcKq3RFVSx7NOH8cBclB3POuGtGOBsgME
xSmMRuPBqtWP7ZDYaJfKLeVD0GjCoMS5YxOvDBxAeKFs8p3Q9Yopiqix+gOorboZGndsgwL8LET3
2U9B6rRBUP13A10hMqSkqxVSEz4JXoSXpZrxxYUFKdwIP3jwICR5/XgubKRbwXbt2gUfffSR+uAS
6SjGieDEE0+Efv36qa9NFeEXpyr+79Vw8Dfr4NCvnoOminI4bdZ3oPTsM0NMogi3VWfj1vXq99ZC
TI9AKTn4R23JsaoInkA0nsJJuxxxBOQQck5CHIJAie0HIf3yWC0j4kF08ErSxjXFKTCohth59Slp
PpE+gEFOHoFimisnDLK+qFdfKJ+5GA7cPhq63jhbTRjpnfjd6JjychWBI3iVp7AQvw9eUqq+E576
3ve+BxUVFep73Ndeey3O9lYj8tk+G0Jw+mb3008/7QzsEkdlornuuuucL9yRDJbHtHp+4MABWLdu
Hbz33ntQXV2tPrhEPMRLdtFX/EaOHAmVx/eE2t+thwbc0+h62ShoPHAQav/nBSj5XD/oMrA/KddE
63UNnfNqcEuTZcHYZIaRHOfuDd/1qziyIixhNOdxRLYLGhU5e06M3yJR/blduG40MpvHC3cWzo0K
EejVaV1+MtEyXZQ8E2/uYbL3qL2ImCuArldaKwxpoZo47v4PvIoyAtI734YD911H7wp0E4cCIaSr
NdJRvHuqoqgQunbrii1WAKkLLrgApkyZor4RrhvABwhPIPTZ1Y0bN6qJgJYsMhEtvaPkmmuucSYN
5pd0slxTUwPr16+HP/zhD+rzrvTMCH3DluTQZEKfen3ttdfgMG50X3lSH2h+5DFInXIynDDjFkjv
2AmfPPCvUNjzODjxB7dDYRe85uZJWkDTtTgp7cdvgFcoHf7vfHuYs1hJQ11dAa7mnDe2KNmyo7VU
GXlq9SXRo2ILRR5xJ5aSQH+08ClxmYiPbUcuCIOcMMFzob89yMyXRuU2se0x9EEaT6yJhWnbJr4G
09Txp6yiPwnMM8nqghNGA00Yc3HCwLP8wJRAT6CMGIhC3MugJ8rrjxy2vhMueYIGeauxLAvp1qvz
zjsPaFUi0y9/+Ut48803I1cWzENG0CtMXnnlFfj85z+vPmLet29foM+6kj5a1Zx11lmKZuOf/gQ9
PtoDFw09B06YMA7KLjwPms45Gxr37QfcoYlso62rqmD6gtWsGvMKuHn+Epg4tJeA5ab4ctU3YO6v
P4ZpS1bB+H6l9uBeC0vHXAP1VU/Dbecc5yjmybl288Nwzcwu8OzaKeD/anktPEy885+GmUPxI/HE
rf44YhIWqF1F13UEih7JaCaV9Am1tT258At7TvDZbdtb2rEtsDst9y29T6lmkm1l0dMFhbZuM2kV
tZGnTufS3vNpYzOSN5ZHfnTD+zhh3IsTBo6BviSZYujx8WcAwL1vXNU04clvHT7kl4YUnc0vW7YM
9u3bpyaCoIlD6qKVQFfcUafE9DSZJEn0FPpLL72kLkdddtllMGDAAIedBk9acdDv+OOPB3qZ4pb9
+2HEDTdA2dlnKbrCrmVw3I0T0Rl8TgPfiRKU6ratUBPG2FlVcPOlgyCV/hjWPjQdFsy6C85Z9TMY
VBrEmQV43Vb4z9W7KUjwzMo3YfzM4Y7Q4gqAervGkwVV6aAoLXNXTfIgoTI0l8Lo2bOgsV83RRvc
9WzhsTKr2yv5fPBy5+Qjguux5HVcItlW7c1LPlbb3m7Rmah/qX6tW8Udj+FMyPX8zOnuojiXjcgb
3UPySE0Y9+C4VmuYMIhAho5G81ZIRXhpigYbej16ET6zkerVq5c6y6fLQXE7FdFJWnkgyTL7QzCm
ZzxNGh9//DFUVlbCqaeeyqS+nOz7XP/+sB4vYR0tK8VJvAkfLrEeLyks7+aj1wHpI/S+lQoYdsEQ
KFcTRCWMm/Fj2Fn/CpQp4jRsXrkQ5i9aDTi8A/QZBrPunQ1XDiyHum0r4bsP7Yarh3wAi5ZvQjGD
YdodX4V9//nPsHxLDVT0GQX/8OAPYHhv88yz59VfwhYYCz+Z1wNmzV4OW789HAbZ8wE9WcJNnq7e
DAt/NB9Wb9kNBadcCpO/VAcF3QeomJEN//BkDXz5gmqYt+AdmP/sP8NHf1wHcNolMLj7Dvin7/wC
hl53Jiyb9+9ofwEMGDsD5s8cC9YahDRwLwsqk9PUnhJvweiv9z5foqHEuVVrP39lLKTVxlFLEnT8
clAIgkKWcURYYHIBtMLwnNgkF5F7jpgrDZMhNGEcevQeaD4YMGEQkwxfK6006PkM2o4oKy3Dt9zi
sxq0YujTp49aepgciYLxJMB0PDlw3ZRLGrpMRXsluhzmoyXRYcRTrNLqIb5kA1b5KYNhANTAnIlj
YMYDS2HVy6/Drvoz4LZ7pwBeLYK6rcthJk4YQ2fMhyWPVMH1vTbB/L9fATTVpBtqYfuWZ2DR5oFQ
9ch8GHvSFlg0Zw5sHnI7PLJwDpy3ez3M/vmf2FQtr4U1j66HPpP/DwwdfjkMxunjuVf3KBqvB9Xw
71Nnwur3B8Lchx6BfxxfAo8v/yPASdbqqeFoDWxZ/zhOGK/B2MnXwelo856Nm2DnkTQafwTe274e
5s9bBWPvrYKq2dfB9tVV8Nzb0S8ms+KtX54hy9g6vay51+6qNDG2O6PbzmCKFceLu4RjDQM4Z2Jm
cAhFgWkEiIssxlHICD23CPO6HXEgV6sNWnFE/KR3NGHULrkHuv/g0Ug+lhvnMpjUkXEZb7UtxT3j
Bryq09CQhsL9eNnn1VdfVT9dKA0s/JMDPdPxQG/CMQ3lEs9lylO4H/HZZ5+pzXCaOPREsxtthG/b
hvct2/SF+IHzRKnXcPjZs0tg1uSxAH9eDgvmzIKbvnI1TJq7EqpRUKrneTBj9kKYPm4ornpOgc+d
3gegXF7uGgBVD0yBIQOHwje/iTJgAsydMhoGDhoJN0zGS2ob/wIHDAald70Cj+8ugImjKhFbCV8e
A7D20TVqMpKHVnrXa7CytgBmPvRDuOTMgTBiwp0wf8Ip0GzNL47k2/5tMcyc9CXoJfbTC+zHU8bM
WQATRw6BwV+6ASZXFECt8xpk0uQckY4sF6QPpPLAllbKsiumPZbMA44hRu3RuZbYrIeA65z7ZAci
fJRq9nG6EPHpvCaYQQxx6qxmsraD0iUjXm2E5AVd3askNGHUVM2AHnc+imfx+JqkED4vrnWCQU2X
wtUGTVbpdAOk6A4mujS1d+9eT6B5cPcAsSLhsqzTRdXpOYyTTjpJPZ9Bk9bw4cOdfRLmpUnjxRdf
VLfi0u23mTxPUle9Cz5NVcKVk2aqX7quGt76nydg1qJF8OCq8+H+q08CeON+uHreFlaLl6i4iBeR
Kr4I/e2rT0Xdrfde8bTVALSMLDFOY1t/84wSsmDqOPipM1I9A6/sug6uoHnETkf27cQD4Wz4Qm9L
Kk3Eg67AF5E9fdRefVE+Bi4eyJfArNUBHTz0O4R/TuiO77lHedikUI91Cyc7FJc5t5UTLRbp0hTx
kAQylcs2lYK7ZaL3gSQ6P8tkc2fyR4DjojoCorUu4jv5V3jJpIvUOwfWrf+aaF2RLieoTn2VdOh6
guhbGU4DfsSnKwoqusFx969QhjXsoNtqp0CPe5ZaEwZBw/jJbU6kqxUSjfONNCig7qJi/LbGN7/5
TfURJno1emsm2jgnnR988IG6U0q/hZdsIRhNaJTT3gZvviex8+0VN8GsZ6537kRKlfaCoeOnw83P
rIandu6DrcurYMHqgTD/yWdhaO9yOLDxAfjKA7TjYKcaLiTI0+/DL5Zvh8GT58CMUb3xdjVcVeG6
5vFbZ8OyNZvhyimfV5MvNUZxRS8s/xn2HCyAM+ybufZseR33NIYoGhqhC7qfBOVqpCYbaHWg/7D3
EEzDxbGY+6AjnjQwMEwA0sQh84qQHJkOGl6JmdXIjsz0t+REKTNbc8/liYanIsIkm84xSScmhIyr
xWRkdWRkUmAdJv2ZyMsej3XpKFxexR0/geJ+ZwFNGPvnfAOOm/NzVSeu+j+/imf0IfwimKSrNRJ+
IRwa8YWx9MLCUtzXKBw0aBCceeaZMHDgwNj6TXdKmWBhAunSFD24R79LLrlEPchH9Lzyob0Okkkr
kP79+0O/fv3U7bhhMk240y+YgODlcMfDa2BX9QGora2G11c9CItx1/uKEafjPgmi+5wIPbvhsL7j
ZXhg9lq8PFUPh0zCYsKqX/s1bMLlyo3jR6LdA1Vs+w0cDtfi5azdy38FO3A7glNpv2EwCitzfrQM
dhyog+qtq+DuRbjqsfc0FF0mExcryIucejr+RIdvS7MKlB3SGFluS8vaQDeOO2ro4RBQhcpcZ5MI
rggZwDkRMpIJvALoJJUxzJWdPDdSW2QbrRJo0A/4lf/9/VD2xavVhPHZ966F1ADrbtCmQwfh0Asr
4MDdNwfy+mSGrUha5ISXmU6UaDO8Cz4RXoJXiFITvvp1nEXSuOlb73v2wsuKDY+tT5+Gpecx9uzZ
o1YAREO34NKdUITjPRCdV6+TIWeffbZaQdClKrrld/fu3WoPg2gvvvhidWfV5ZdfruDd8F0s9I3a
pKnX8Ntg4SyAu+bPh5usK0ZKxNhp8+Fb+JxGuuckGLB8Pky9xkIOG4b7FJuegVuXjoJlFyMp3hrr
SbJe0lXb/yDKOnh1OcoaNQvOKfd26jNGfwXg8fnwwtbDeFGLb7mthDsemQUf3Yo2fOVxpWrAYFRC
Gy6cpE6EubwpQAugBG+D41SCD3bwrbwMa9vcGn2sgRr7EI8xrWoUKqWmsEwxaPa2k4Gg44NkCOxY
mZsqLJCmANuCVWbCm0Jr85hQeQ5TE2TICqDb5RPxTd1vw2czv6Zuq61/8ffQVIPPm2FqeP2NaO9E
CElXa6SupXg5rcfx+IxGgzqRL+jX/6zmI/ikXxpfNf7J3p2hNnz66adw7733qsmCLhlNmzZN0S/C
/QGaOOg3d+5c9XR3qCCBJL2bN2+GQ4cOAW3KP//880rOpEmT4MILL1SXYgR5C4ppXGUcwktFRdCt
RzleLpKJcHWQKi0HenC7jj6LaJclVbyyaNVE51deG+LpyncqGQscs7FqdfRW6u1OeFw7lA0Ej3nE
dcTLURwW60YWjA2FR28SButwh5BjKgkY5mjgQsyc+aXMmKyCTLaZ5aNA5rj45iV9oXeJd3SRKovw
xatNeHIsb6s9ed17iuTj0f0lqbEsffu4vgHO/cMHRjoTkPat6dk3kkG/DRs2+MhYPsVtxIgRCj/2
mm9Cj+494RA+vtDU1Eg3MOEtONhGdLYflYiGNqTpEhJdOqIBnhLzkkF02SlJIiNpQ5wmD8pJNhlM
5eymFL7epEeASMK5z16XinIAQw7AXhtyoKANRMqDv+1eAUETBSWaJ5yB0gJ1/lWB8YeBh28vRran
LBMVc+hwrwS3FkQfl9+VlFclMj/EhcZ3tjvmll13A16eGuLUK+56ANLbN8ORp550YKGFED2hfAmR
DXgV6iCuhugqAS0W8B0cBTgBFAPfvhkmjyaFqVOnqltkaZAnAZTOPfdcNVlcgXf9HHec+1qMMFmM
o8lHPtzXu3dvdWDT5MSzHtPmf84HAlnaSi2al0GhOOj+63XdcBOPTtPCulLRCnpaaGa+sLuLMVPb
6XEkGoLFSUwn5TJMlxtHXv7Q0IeT4jwRThb3uPUfPYZ3u2IibrROhMNP/ocH7qlwmBCoPtLkQeam
0oTHckGqED92l8YrNThpNOJWfUFxUezmpg3zJJvmSd2gial9JtGa7dOBLFmdf3Hg4ax9D0dZah6f
GDlwM1K2oY6XOC4zDecs5xjMKQQxw7B7ZL+WBSimnpYpoYeqG+BQw0Hc98a3ceAXAwvpLqVUUSrZ
d19bakWH4OcDhpyRZaq3UmuSqlhJty8WUwuIMvE/E55kJlpnzrnXk8yqtqamvsE/15bcxaq1+6Lr
U2uUik86FerT2McC7p7KFpx0kK7WSIV4NagO3z5xpO4g3ux0FAqb8RJTAT4mjguQ1tDfAXT4D7Bk
TrWUX2rLpiwptyXl/BuUO3t2Ju0Z1Y6E5182IxylN5kvdIm7NX99//4+OIwz7lGcNDg62czppYH1
+B2NQzhuV35/brJgZEiN3+tTnLQlUVd3CFIFeMeT+nWuNRKGlDt3Ng+YJCbE1RuXLonuTtqOGYE4
fYX7vYyACSbxQWXSR7xSL8OCePIb3uNLVwHgZxd2PXgPHN39YU6MLelzKk4Y90H3v7kyJ/J1oU24
eYKf1FB7zUfxsYoUbUQX4YTRJNtN5+qsaxHggyRp0Jie+TWxsaosIxYxErVEV1wdnXQdKwKt2WeS
9uf8jzRNHGryyLGprXU7cTNuYeBOBs7teAck3XJbVGg/GGZdxMyxm+1dPHXwTA+ojndwtJfWpK7N
t90mtbm1DsykduWOPtP+HWQR9/sguQRnmiAZyeDHXpsli09SavUJW2wi+iRFIW5lpPDalPq4RsZH
VVILOgx9Bh2dWNSx4xQSRiMDnQk1dExyfsld0MDV2l7LdmSbTDC2y9RfJD3TBeU8MLMuptNl6Him
y1Xe2vpy5UfHltvQ1IAO4seX8C7bwsIS2tMowvt98fUfCK6vz68XUORnU+gHGlsZdgAgj/VfPWDG
HMGrFtKhy9P16nhXavsosT+t4YcpnrmOUph/tDlr6bcW+DIGuq1Y10FsOsMp5yRFMczXlxyEXWBB
OjwbdWmclCcNlTQSLumP1XJ22obuks00FeNzfHSjVFMTPs9Hkwc9Fk69sgD3NrrghzY6U1QEZAeX
tEGdPSk9yZQdxcQfpEvak89l6VN798UUZ2tSCL5MIicN6T/HhWGyzmVbH1WZzGcCI0KJfFytB2Bf
2M7W09x+NHGMyOLsxKmWXo+UQSouLcE3duBqHT+IV4TPaaSa6eE+fCo8VZT8ZYAZ6G+HLPLAkw0p
XYloVGZzyJyCFCLKOl6vC9J2U+QgSIM7gl/sj9tPeBXhnfyZjnLyOygeAu6KtHmI107Omx+RKJCO
9XBOvKaYs04TjhVmM28tPdm02RPkbArOe1m0Sula1hUK8EWMtDLGh8NxRxzjUUT3VHUmfwQwLHhe
qF1WkmRhB4AdUyJxwhtGL+VyOSk98+Vb7glCKxjHAW/b+MlX4egrD8syslPayGW2PyhUTIe5mkBi
0AWRdMKzGoGDm9bAnsfvg4ZPM73lNqjtrTYvPuFU6D0ZPw07LNNbboPkm8PQgJ/ZLinugtvfdPcU
vkaEHuyjQZEeGsnn1Iz3BzcdPgJFPbo7ZtJyqQkfOCnK4QsGObx09mgOEVOY4kcwG29mdnxJXmC9
xGnSnVxi9jnIxiDbguDZsiLX8oPttJqa9Ms28tO70ZF0bDfmqihxugyWwDw6Pk6dZcShjaJhW032
ROmJwkfpzg88TRifVn0bylMF0KUs2ctbvR5wLBnqxrT+4MdKB8z8txZMHCw3Oqe7p+iuKbo01Uiv
EiEWerjPfvdgtIQ2oqj73+2w79En8V307ysLaLI4+NzzUPtfv8EXaYkv7WXZPhoA+OcV7TaiFx5U
0zuBXg/iiwMnWdmUF0dnDJpAk5LGLoauvCKx/HMvU1Ef8vrMdUmT3AWvzOT8gQ2UXJTiIHvCbArT
F8aXoTlZYwuz26tkz8/vgzIcXLtQw8Z+lUgSWlCySQfpSp7Il2Sxpk9e0LfBm5vxzSF0yy1tgONb
qHBPPJmg5Ma2jKPx0GE4tPYlqN++A3pOuQEadn0Eny5aChVXjYYK7YBsmSadm+MS1HEIH4QjWcwf
JFeHx61H6Y0rJ4d0Ptd9gBwqb2vRbp+I7J6e45j5ch0r1tNaccq1P63lR7ieo598CCVlOJpGNrou
Jyo+XnwJNh/papWEuugBP7xbSq0yUkXFJdY3aVNeo1rFGE2JHmh5PbgMP15y3A1fhWqcKD6ZVwVN
nx2AkjPPgO7X/C0UxvgWiKYqC1U+6DjPgshAEaxDbyOqMy6QuQ0Rur1taErOVXt9jbOCoHGF6KgF
XW4qyTZ1MdlzQconqV4LsqfnGJTEq4uYrpdNvgu6XjEFqZuhsfoDqKm6GRp3bIcC/FJp99lPQeq0
M6H67waapZGuxEnvX/EENOCkQc+BN+GNU3jRjV5WiN/jbsONcLoVbNeuXfDRRx/BkSNH8EAqUB92
OvHEE6Ffv37qa1NF+Mr0iv97NRz8zTo49KvnoKmiHE6b9R0oPfvMeF53CCrTwc2dIBeDS4cIWps4
YZ1oBrWJvx1p8nBPToP4suEK3w6cDVmZyvD7n6mk3PC10L6YzVc2+U5nwiA/inr1hYqZi2H/7aOh
642z1YSR3rlVnlHkxt0IqXhFCueIArxE1aj6KE4aOIMgKOSzthEiW4Y+cOAArFu3Dt577z2orq5W
X/Cja2i06qAPMZ1++ukwcuRIqDy+J9T+bj004J5G18tGQeOBg1D7Py9Ayef6QZeB/a1TtpaZkqfc
1IHDUhQ+jLcTl7sIxBk5rCfVacJorcS63Ekqjp1oINmoSOPQR3mTDRlROtoGr165EXMF0PXKqT4j
1cRx93/gVZQRkN75Nhy47zrrSpCPEpsDN6hbIxXh11ibm3BMple+Yz9I0VeZinAqKSxoHQOkk/Rp
1/Xr18Mf/vAH9V3x888/31pV4D4LTSZ//etf4bXXXoPDuNF95Ul9oPmRxyB1yslwwoxbIL1jJ3zy
wL9CYc/j4MQf3A6FOX0wkY9qU4ycowldw7Kqmuik50nKJIv163wMz4I+dxTRlbTTumqIPLWd25Ry
fsUJmZqsHfnybfiqxg0B07uQuCW0K5lpAYIzaZMs9vEAq/xgk7MmmJ9TxSkmqYFbgZwJYy5OGLiX
G5gy0sPxDJTqQxzFb5EXFeD6gvc0CvG2qdKuXeAo3r5qSkEdjfcfJJ5gXGe8SSbB6IGRN954A155
5RX4/Oc/jx8xvwhOO60vlJWV4ftNCuHw4cNw9tlnK5oNmzZBj4/2wEVDz4ETJoyDsgvPg6ZzzobG
fftx2sNZMEhJBHzP5jWwqeFcGDe0dwSlSYMbfPbZEWKfzkXFgOlrty6Da6avgapnl8EQ91PlNroW
Hh5zDdTPfxpmDpVfNWT9tm11W+GWcdPhi1XPwhS/EFblyz22a3YzLq4fuvCW8uvysl93n8yWsjP1
V8qIKltzNLUh9y3OTZyyrf02W81GzxJZMoxxt9uWpLua3JLUauSXBL4y24cIxyWTbBPMJ0wALLke
/7AitDk+ExPbzQL0eDCcc8ZzPSxn2ToPwx1esaeh45iX4W6TWB4xPv0+rjDuxQkDx0CmZZyjhwox
VzQuj4ycC40q1eMHmFLFpfhQHz4Ijh/sS3XBQbq8vAL248fDkyRyhhyhH5eT8B/F1cNLL72kLkdd
dtllMGDAACdAJIc++0q/448/Ht5//33Y8tlnMOKGG6Ds7LOUmsKuZXDcjRNxiYbPaZRk9jT7vvXz
YUF9VYxJI8wzOhDMjZFJXPyaSmH07FmQPr2bhtIPwDTQOUkJTqJxE3dInT47dutSW7uux8ev3z1o
cSBFcq63hv/2+O43ygiRvlA5g/6msyUzwGiVEShNNRIkAbIw4a9sqBiigvo4scZp5yh+nwloMl02
UrLF9Mx0avAX7jCc8waaMO7Bca3WXmHYtKZJoznxngLFk34hBrAhIi/r0hW3vumxDOTFve/CE/Dy
Dj3ld9GIocpRcpZ/gs+ZIHTjOaicSx6WI3EMa8CH9fbs2QO9evWCyspKyebRRfjP9e8PB3HWPVpW
ipMrfWnQsrEIN8NTxx3nHu22FMarvHEvrKyaAWPGjFG/GVWroBrptq2cC9OfwcLqmTD+zpWg3spS
uw2W3jnJpr0Flr28CwlqYSXC5q7ahmUKdgHUbv0lTJr0MOxKYxXqYOOKB2A8yr/88svhu4t+A/sN
B2T99mfh1pnPwiHbdsCVwdxJc+GdejfeZC/RzZi7DH6/egFcccWt8P8O1cNf//h7eP8zeyV4YCs8
PPNGxF2BvwnwT89ugUbko9QN89/+6qcwcwLhroBbF6yGgzZOEQT8oTbln4nEE08hT4dT3UqWTyzL
hTMkv3KrT1sxIMtk8+k+suU6nH3U4Uxv5bKtudsSjMoS542fV4Zb4zaz7HfhXPLKZKjdizV9jGU/
qC7LjPfndptz0zsEPoCDyWaBbeScZdPQKJOMVVC8JH2Sskc27TPwagNztceBMM4Jx2VpB5Vpwjj0
6D3QfBAnDCGDy/S6J9/POeYsiykOpl8Sf3TaErwSVUDvnMKT8xTebVs487tT4TB+wo/2NcKSNITo
pMNhfJJWb1jCNeGERZeiTPKIvg4vmx2mO6qQNo2rEy1GJMLTuXUdW5ffAw//ugBmL3wEFs6ZDFtw
ML5r5TY48fyrYcJgZB48AW7/2hAohQOw7Nu3wvJdQ2HewoUw+/qe8Picm2DVjhQMHAiwfsEapLDS
G88tht0DB8HJeFJPk8/sxRthwuwqWDD3W7Bz5U/gB/+xxTMIk03pI/tg+5Z9tgSyuRG27X4DjqiJ
xwHjx9tr4c8vPwHzFrwOYydfB6eXAuzZuAk+qKNeVA0P3zQdVm4ZqPyZP+NSWLtoJjz48h4loAz/
7l6/ES66owqqZl8P29HX/9pa64mPq8ktkX38o3YwtYVLHV6y4q8fsuE8bY1l3ym3fLfst3zxWmeC
MYUJJ2Hmvsvc/lzy+rFWvyca+mWn3UxawmDWxGDyC0eIMMbc4yLUR8eLfAuOq2wbbgMFo8MUddMq
QK0EyA77xzDOZRBowqhdgq8G+cGjDi/TBeVqMiEr7QbgXMrNRvloHV6FQh/wi334UlucNLrjHUqV
uLlM999yig6oayjz6Dk7YB2EXizDUngp5TO87ESb4XSrLSfipR9NKLQR/u6776p6MT6PgQ+zKzKT
jayTCBz8UVrmVcP+gwB9R3wNnnykCv7+4pOhR7/hcOUFfaBiyGgYPXQgpLc9D4/vBrj5rhvh3L59
4aKJt8CECoAVL7wLg8ZNQhnPwMY91Prvweq1ANdPGIb3Kx+AF5/YBJ+78Ycw/qL+0P/CL8N9Nw+A
7Y+vh322D8hgJZxgHJsYBt4NDImf9shimPF3X4KeRaTTSuk9b8HK2gKY8dhsGD1oIJw/9jsw/+YJ
0L+4QcWHIjh2zhKYOHIIDP7S12Ey2l+Dt8kFJdKnJ469hBOZpNVppN3MJ+llmfH5kJvs0n0jO03+
Sft1vF4nWpLLyaQ3Di6MxmQ30Ufp0vGyLsus25ezW/6u5CPNBwDHifNom9jBaEqiUPcT0VBq+NEq
geEFXbs5feLojj/j8xkzoMedj0JhV3xNkoFXh1mrFSL0J2q3WG3nZzVCilLFuHWcgmKcMEq7lNG7
pwqg94m91ABt5LCB0gjiiZ+I1tujiL8ElzonnXSSej5jw4YNMHz4cOiGD7TIRJPGiy++CPv27cN9
l3IoLcXTbkzSFknPZTkWnvn1H8PUD34Ei2bfCouIYMAYmHf3DMDFAxyht4/UW6f6aVUBWDx9Iiwm
OjsNwDzVezhcjwPw06/sgsvO3wibYBjcMggH/Nq34I81gJPELPjy48xBEx7A+3i9q5d3TmACy35p
JGJcn8ioMXDxwFK1usJu6PDVf/IelgfA6SfgDISpoKAYhk68DYZSpe4ztafRvQe/3j4N9ZoOItOT
q9c7sHnpvO0nccEYSZW/5Xj+W/ZLWvbIBNOPj6g6y+KcZOo8jONc6g2ilTTMl4s8RjfLhVpHZpD/
DkFGBerZ7rEXJoLjrOygcVycp3lwJATFFlR0g+PuX6FENuzAPYy5U6DHPUutCYOggt8xQTeH6uY5
Q8nN5p8i+vgS3j1ViHdPNWJjp354zz/C3r374OKLLsymHkcWDaB6p6JA0h1Sffr0gZ07d8KhQ4c8
kxYHmu6woltvafKgvY2uXXFDBhM1DtM4ikRB6jy4pxZGzHwYJt6Leyjb3oRf/GQ2zJ5+Ijy7corF
YY+xpbjhDlABc1b8CkZ2S0Max+WP3/oT7O15GsJ7wFVThsHyFf8Fz+94FSrGfg/60RP05afB8O4F
cOq3H4N7rzwZjjQ0Q7r6Xdj0dhrO0icMNTfVq/5A9qerdwIubMyp4kSg6dPy0TproHKzemp/Lxym
exZw/iTY68segBd7fxVmXkq9iJLscRbE9FceaBxLyiXcxKfD6LBizToun+vSz7j+Mw/TB/lnwjMv
8eh4iQuSyXBJy3Iol3CmzX2OLR/6ht3cWqD7rdeldooP4emHwXLGYknjLwf3bFuMj4UuJTXZG+GE
JDqV7PmH6hV3/ASK+50FNGHsn/MN6HHvo6pOdPV/fhUvT1ksOp80muSQrtZIXfDOqS54wt6QboKG
o/VQ+MO7vg/pRtpcDldPQedfOKWFVY1jE+odmuopvNTUr18/9bvkkkvUg3xETs9u0ERBE0YRXkOj
FUj//v0VHa80bLG+A0XXSXq2r5wOUybMg8176qFX5UA44xTmtvKazW/AtuoDkKo8D0ZBDcx56L9h
Dw7wh3b9Ce6cNQee+F9cSmCqHHUN9Nn9DCxYvRtuHD/IYsbJ5OxR5bB+/oPw8o5DUFC/B379wO3w
45/jU5xaSpWVo70r4Tdb9kLdgW3w+I8WIEVXKBZ09FFFlSyVTrw57uX9/wYubK6B2Q+shD2417N3
y7PwgydegILjejJn7NwUK72dwoSZ+IPok8gNkhEfHtGRbUEm+4Ps5PjHtYHpOSe+JPrC9GRLDumQ
9pl0Et6fCGaC+ynbFGKb6AzaZDX6o35ZMcwdsFmuEkvnbDTo2z/euOZ6+d/fD2VfvBrS72+Fz753
LaQGWHeDNh06CIdeWAEH7/mWs9nNPKZcyW0yt4PHniz4WoKTRteyblCMl6kwgJBa+NDP1CLRW9QA
AEAASURBVABdaOwgwRq581KjBLESDTnASdaLcKUxePBgtYKgvQra26C7qWgPg+guvvhidVcV3ZG0
e/dutcqgS1qsT5fLOvR86DerYMxrM2DmDS/ZqMEwe8lEtZtwyvlXQsXyx+HWqUfhaVx53LFkNnw0
dR7csJ4uZBVAnzHT4O4rKy2+HufBxGEFsOCd8XBpP+syGSGGT18IN+69HeZM/YpFVzEM5j3yZVoI
OAMF+VM6cCzMGPUULJh5g7r8dfKFZyOFu4+jJhDrqhM0l7sdkoTSDcV15HjpQPiHhd+F6bf/FG4Y
py624T7+LLh5eC8UtQenILrl1trzUXzlBUAXu4ISx1LHk72ZppbwZqozUz6yVfYjlsM+mPCMY1qZ
J6WXvEnKJj3EH2Yby6eWdY9IhobxEnXS/pCU3rUjumSyPowryOMwnng4UzvQbalq4xpjpvctou92
+UR8UzeuMHDCoNtq61/8PTQe/EwpbHj9DQ+Pak/bXVlm6/gwVTgEUq7rZNrMc+uVTnj7FBTj+NuI
X3otGDjw3OYu+FWmGjR8BzrT2imNrzjfvHmzukS1f/9+eP7559Wlq0mTJsGFF16YtSCk62qhDq85
lZe7A77Z1zTU1uLtrSl8fqWUB2BsOefYMR8Qlny8YhXxbY86fM9WOlWKsu0ZwmxEBJRtbKmcCDWd
6A4WATrTDpsgMnXXHtkcdvMx4qDzssAHuPQluR9vXtIXepcEH9tF+OLVJjwJVrfV2nE4ed17qvTx
6P6eyMgJQJ8QqL7naBrO/cMHDg/T8yTi1IkC6ffu3auefSM4/WgvWU8OD9LTA9eUvvb1aXjnVBfc
z2iEerw8leqCu/i0M55KZfaAnK40aZ2MpA1xmjwop8tT5DSVs5lSpeXavUpB0mlikRsSfKARfXAn
iiu/1CM7yIYouG5jFH0nvuNEgAe14L7o9ZXpg68IeOkzqZEtrCeuXZnoIR3Zl88DpeuDZVuz2q8x
6Quxg8hNLLa7je9st0sFUHbdDXh5arBdx72Oux6A9PbNcOSpJx2YU9BlGvTwxOL6Y3PjeBo/+X07
dKgG75xK4weYGnClgW+5pUtDtKSiDzG1RaJ9i1NPPdVR3bt3bzVp0MsKfc47VK1bsGKeJPCta1+0
Nn9HiObppMi/CFA7UkrSF4mW+ZAzCavSFfdPzgR77I9rTRI6PjP387hx8+KCfcWTcfXwnpfeXOtx
6488iG5XXAeAv8NP0qSBl7m0dvbVDfe88MRBgoP9kmqDfFQSFGE9Ph9XiK8PSeM+czPu0qcKcZXR
cOSwc2eSFNcWZXp1SP4kucoIsgqDTnFX/Si4MwVxJ4M7ipKxdVJ30Ahwf6BcJnM/tKBmnOTOrMw2
ZEs+yvOJzJbsMA9ZKdJQ0bk7LKZuIotF2gy7R/ZDYpmEbndQkQTecoCeeJOFFBUgyCahh6obcNKg
D/YV4OY7rjRwcxmfSGmoT/buKamy45eDgmo1stO3gsgyDpCSnDG3y5h1w1zRnaVWiAD3A0M7qk0K
2wQkI0r6a1wdG9htzjbMLIstA9hA62SNYO7KiHG5MlXagTrsWLpaCe/WgqwoPulUqP90N3SJ9X0i
XWa0fNZbj1eHSFfLU7RO2gBXrxApxNUG3lpT2Ii32+KL0ePEo+X25Z0EraOE2meitQKuOrbbu0Ol
JENyg5Ju1s95Mkmd1PkYgbhtyf1A+mDxeiRIMoVgrERIGdkuJ9FDtrF9bIe1QUvzoDclkevljFez
FJJe5+djjGdD5ffnwiG87l+Pz2o04ZgQ/cO7cx06KvMvmJdkkw7S1RqJ7pjqUtwFKsq7w3H4XaMU
PomCGxzpVntQpDWcjKtDnaSF9gW8iugsT4OkhgoIYsoQ3pq6MjSxk01EwDf6CVw2iv7+aT53YTuy
1X9YHvmQiUzklyJQilZVwTH7olBZ/kM+2KszzTT/GMGWmv3u8aWrAOYvgV0P3gNHd38YYSfLMpGZ
5RNlSZ9TccK4D5QuE2uWYU24l0EPYzekG6AEr0ype8MaPY8gtlwjb2DztTWuk2SGtVxL7iRIey2b
1V+l0I/TG1curV2czmfJdfFKuPhjphcEGRSlTL0dgnASTip1vgzMyBmL31ZlsdLnx/ljzzTSR4ZJ
oyVewqlsptepZJ0GDr8tRGGSxZxkg46Xdrk4a2DK7QAcNvixxZwjrfVfeR3E6dprjg1Ly15u68GT
RJ9GMtIHDNZMg3m8AT3Ie5KdQGGwKVnB4IiGT4Lji2PxqlRZKX7viCaMIvpieCuk/AmD5azbMV3n
3YPNDwvD0ZFAeDoz0ZOJT6eR9aT0kjduOUxHGC6u/NamM9nMbWHGuQ1F+CiaOP6YZMThy4SGdJn6
byaykvPwkcy5LsGNrYshGP6s/wpsoiKE61eQfMWeoz+kU/t5zPBUcmhDjkRnIDZVVAxHG/CKFF2V
wl+KXtdxxeWj4LwhX/AcOOazFq/GODTyQKJO0hoh91oZVtOtcbsx+ybtZ0kmHA9QTGPKFR8RukeF
icyB6XqsgUK32SFvs4I5RmSO/2yYjWTfqG7mz8xPlhsmU+JkmW3Tc5apw4PqTM+yrSYnf9z+FcQb
BNdlWnRemaSP6FivV5Y3nmYa6poWXRTe3LZyItOOdqzG8d5S77XV60db1HR79HqmNpEcjkq2ZGZq
SzBfSSneLIX/SvGB5674OqQUvU+kBN9iSM9r1NJ70+3EnYeqgR2IkIGd1OqAOq+US+z5lshe10Z3
5UAw9oXxbp28sBqdYQoS+wD0RoFl6HqkTC9HdI1lSkqWTzAdL/0N4mG4zsvwIBlx8NI2pg/L2Qbm
k3VZJhl6XcnFdncO31ZpN9ZG2s0DBtupKAw2meJrgkl+KlOSsi2I+zdIBlOE4W0zkdTrU5g+Vy6V
vHyMa185tS37IcsmL/R+wHXmN/EkhxXgCiHT1NBwVD38nW5qwGc1GiDVv39faLS/udCMT4VTh/Al
OlXCJHHcCRRMw0scSZN1JSiP/7D3js3Sb81PdMzxxIlNBMxhsOWyHoab4mnUwwxxc2G71Gmym0Vy
LLhOuUMvgUI2gT3yBR3xenDU1wJ4jXqELL0obSUdXFdyNB26TpLl47GAuhpVZ9uifGE9xMQ8XoHc
f9haL1byM4YpHXm2bw5exJRhlDv0DBR8jGN/VF3DM86RpcWU8e7wwZbaCoU8NkHmFh/xRMREMcWh
kdKTlHXZVNd8CRVnnWgGxsHES7HxqfABTJwGmNleS5r6PqmBJxxUc7AWuuMXUpsK8O3f+OaO1Mm9
T8CnwcOZwrDcWcJo2htO+sQHVJgPUTQ6nuVzHiY727gonWRrFE1LbMqlfN1uPe5J7db5pXxZJrl6
3a/LGox47HQHFcUtyOnwNh/4TKTbxXDKo+2Q1PHL3nazfDFzJx/sLI64fOGxMduUBCrtCPMzSCbd
0RaEC4AnpQ8QY4FJWHZjlMa7pqj9y7uW47eXTobUhg2b4LLRI0PNCEN6O1MYZfvAyYMu7OBM4g3L
1OVZdfcSmC6T+HQenSZOnfWbaLOlwyS7NWHSx2zEjGxnmSZ5ettRnekDY4rH8v/P3pcAaFFc+b+Z
+eZkBlCUQ1BBSBRFs7IadINRFJGNJitqgsaMmiDx9g8x4kFUUIlKNLAhKllFY4ir7CZgNpBVojGK
xgN1TUAxcisCIw4wzAxzfTPzf6+qX/fr6urj++abAQkF33TVO37v1avqqu7qi3dpdXAZOliwlBdB
mw96cNAy0j5RzLKHlG1ODqBB/6JRpa4nqaofGoOwgS9UwQPuUM7uayaQDW8thR2/vgtaP4u75ZZQ
w+yF17PgoP5wwHdug9ITxoS4Fa4bohBJLsOP43XrVg5l+P4++hCT+qyPeWrEnZ+QZGflnUHypbUw
upTZu/P+BpT1MeOQTT0knqcfPDKRO7zUYR+YlrTMtlieyozBvLCt9IVlpG4Upk2XMcytxDR5mZYl
VpR/SXElnl/H33ayvlJH+yCumRAI7tfmWYcu88Vk2vH9/dFv2wGJlfG02CcZE+Iy3ZM0c9EHNqZ0
oGxUw38kntsBLmA7UwL6yu4qzzJ0jyaMup9dDd1TeVBcGv62W79bmRlt2rVV2YDrH4qYOPwWOlIq
wY/f5eUXQktrMzTirbf5Lfh6XTdKCZBlB+POx9sE6nu1CO/EYU7a6mmjmfo2GRvN1MtFWbaXxIuy
H8WTGLnId74t+9laErs2GRstPg48DDmS1tEow9Ep3mhWEsnqZ49pmEGuPdXQP2GEaRC9q+NBA7f2
lC2z31Femrwdv7oLSgtwwiAs8TGmJPm8hPKETTbIVlekNF4Ih7ZmvJ7RAg2NDfrdU3949gVY8F8L
4V/P+6byIazjhNFJKVteV1Q6qY2oOjBGnEwYP4zOuOY2St7kRZVNnrQjeTJPMrIs8yYvDI/ppq6p
z5May3GZ9ZNuWT9MPlt+nJ5pzy7vDEbuiEnl4MBr6ppl0xaVpYzMmzxbmWiUTL0gTZ79EJfOPPx1
4jJxbcmtujsZaH19xNqRYdpmLQmN7SeRTS6T3vYJFJUWWGMaiYIh4CjIXJhOEbpPtroi0aRB39Eo
wbMNeiN6fil+gKm8W3fokcUnQ3PlsK3TSuy23fiFq1deh9bt+gtXxGur2gaNb74DbfjZ065JndPJ
usb3bK10XZ1p0IkbeLKtxZ7VkzGkvCyTZ0zj7Z71Nmhd+ss+esNbfLvxhEPIrCcxic64lOfENFOW
+Z2zZatZoyc8W+Azj9LKW6DXr9aoX89ZL0LBYYPVGUoefl61x92/V3SWtW4D/Slrz0MVC/BN6PRO
rPyCfPzkK17TKMBX3tKHNejdImHJHNSb8Y249LEk2lIqKsaXWeH3L2ibadpW9SmsXf13oIstvXv3
gb7i2xqM1bZjJ+x88FEoPnE4dJ9YCfh4ItQ88ito27YNio6Ygp9BjfsaHyPZttRNuDOH8W30KFoc
JukmkYmy0dk88i9ZMvtHMi0txbo0+Oij0ai2yARZykbVJVf2bO0ZZVf6J/M2HMnPTZ7jHo2GvnAV
jDCxPk/0XI7GIy4Dxkv6JTo/Ltl65vcTS0asAnyHUHrpLVB25gRdQuMFvQ6FismPwM7rR0HZJVMh
ddhQSH+0KgIvZx6HuajoNK4XF5fg83yFUFxUDHi5Jo/ecZso0Yur1q1bC1vxc4X1+NnSFvySEyV6
MLAbfpGu3yGHwKBBR+CMlPy1JFVbN8Oflj6rJpwjhx4NXz/vgoAveXghpvCw/rD7N7/DyOZDOz6E
2LjkWSj7Ni6nFRcG5DMjRLVwNo1COlGY7F0SGZbtqm1S33PvT/JBJ3PbzkqKbpXIsHN7s1DyeJAN
7+WWrO/4asK6VWCGS8CMoeuykvviqnQog/b0f2My9/ucWbv5dZO7l61emAUDD4sGRSlmcxDTjm+g
Tfoqv7IxzoRBbe68GFVNHLf9GoqOOgknjPeh5s4LQ/Ha8V1Q4f0lrO6Z0ykO9DXTInyOr7CoEF9Y
iDMGfVOjoDl6oKcJY+WKv8GWzZvVAx50ZtG3b1+g15Bs374davD73nV49kGTybBjj0s8cTTh2cru
+nrYuWNH6PJEwQE9oftVE6CtZhfU/+w/1PtPys49Gyoqx0M++hGVWhvTUGD7Hjc+pIJvUQE80YpI
GC01GpCIbWfmrkY8zkfARbLQH1ppE/7QaWHuEvlnqwNbYL6tHp3tG/vQGVtRH2v1Rb1ZVO3AjrCe
DWId89bs/aKR3ccnanXOJxEssMPEkfpMl7Sgtp2Cuvq/YgcHThtmEnukx3J2y4pKIgETAUIEQBzL
7wO1j0zB+hKXlk7RrbBG9gFgISt3PSV3wpiOE0b9bonuz3sqfnqOS3RSQeN9I14K2FZVBam0ehoc
Z8eYBl29+kM1YdAy1rBhw+Dwww9XS1p0etqA1xzeXL5cLVnRpFJSWgpfPPKoRK4X46lPGy6PEQ5N
HpS3LpXRGQY+hdjeind7YbBofQ1vGo620bgGbjv3KoDvPQw//tYQTza9BqafcxU0XfkADJ57AzTd
8xu4+njbFwOppwC89/g4+FHTj2DRlcMRw2ZT0rJryQ//60a46bGVno8q1w8uvPPHMP7LAwx6NsU4
vyRf5gHsvlXAOTfMhAlnirhm41ZWOhRvv492GL2z23mSinj6v3NU7fGSWgr6Q5pBqoccz42XDYtB
GN2PGCx5cVDeKZgwLF0/P4aMlo3vl/ZHR9v2JMLsehLZ5QhX+xY9YbD/JE+3VnM5xipf04gRi2Kn
N+IZxh04YeC4GpnIVhckGs+79+wB/UoOwROHd/U3wpta8NoEDtZhqa52F2z55BM1oB9zzDEwcOBA
nyhdj+jVqxfU4VkGDfqbUfYQXKoqr+juk7MV6EK8Xs9uh4PxmoYtte2sgV1zH4eWd/8G5dd+X138
blr8HNQ9+Rsor/wW5OOpkzWVDIFvnAFw33+/BDU4afC0sHvVS/AuVMBNpxwNB/a8EVoO62ZV9zp1
OZQXl6GM2XG4A8ptCFQcuaUBp/Oz4b45F0E5vt8F0rXw+n/dA/NvvxuOf2YufLEjl23ibMfxLb6t
+N9/h7kPTIEvfXkhnMCBjcPJCZ/agOIdn3hQUNJxKsi3ieiDy+Q2fX3E7C4+l23WfAKiYNo3y0I0
66w3wSrPkhxVsxu8NW1b6TH11sZNpByWvXpKUK+66LTrt/RV5qWmP9+OV4xpiSrzpP1q3oATxu3j
ob0uZsJAA2SrKxJdu95RvR0K+xRC/wGH4nMauExDl8ZpmSgsffrpp4pP3++mMwxb4usbxCMj2/Ai
dZLU44AD1PWQArwOctLIU9QEYuq14xlIy5r1UPpvuCQ14TvQc+JlUDz2DGh+/wMA8ZJFU4/Kx339
EoDap+HtrVhPJ/3t2acBjhgPx/VqhPXL/wybdug7sNb98WG4cuyZMG7sGKi8+j546xNNLyzqBnXL
n4OHfnQJ8pB/2XT4azXh5cG6Z+6DW3/2a3joBtKTPIzDmkUw+YZF4DZ/4yq4D3U/1LDsjrMlqV4w
oG8fOKT/ADjk8KFwHi6/AayFTWSrcRMsuOtKbQPtTL5rAWwmF6rfgFu/ORleF/V7a+5kmP5feAEN
P8743jOznTqRb7fCn9bo989ov+c7fo9B3p1Yp7CXmmnfBgvfzvrmeYhfi0uVuMG0/YMl6IeOQeXV
s534RPPIh/ueXIL1wrheNg9qIvzVsZwLix+/VbXPOKzz4ldfgfk3nKdiUolxfWurDCzt+c5EELpv
ESPs52pTJrNEprV5paeyopwMjEFMRT248AXoIJbU43xQyk/xbKjB0xtB/WJuyZMPkoRNHw7r8JY1
pTzRQhuLFbLcOnYM8+SiXnYy7ZrlhGb5TCPJ1oBswTOM+sduh/ZdeACZRJ9kuiDtrNkBm7dsgnVr
10BNTQ3k02xFD/jtrg1/mVXtrl3qOgZdw7B11saGBtiFMpSITxMI6SRJ3bt3h76H9Fd6B/fubcXP
w5dl9bh6AvSYUAl0fSMf35fV4/vfhYpvf4uu0ESaKTtqFJyEEs+/vkHL4dLU/7wAcNK3TgM6d/j0
zeWwqQHfE//JErjhgYVwHC65/PvP74Z/3vYCzJjwnzjgUy8rBVi3BDYN/g7cN/tuOLX+Fbj/ybcV
Xrp+Paz6w69g07BbgryG7bDhve3arpaG9Vv/CmguJOEH3F1OI/z15Vex1A/69EzBX//ju/D0qwfC
D37yMDxwzyRoePVReGTpBpxnBsKA2pWw4OXVWhPrt/CZlTDgC72h+YOn4Edzl8Bx19+HdfopnNdr
Ocy5ZYGaxLTf89Hvqej3Xb46uS64GYxU7Sp46c034HUcqF//8xK474af4MR7CQztBdC69UWYMGk2
wNduVDE4DZbAtIt/Dp+ifhSPfHh9/mx4estgqLzsX6Awyt90HcZyIcxbORju/vl9cObBK2HeXdNh
1bDr4IHZd8Cwra/AjPlvuR5Ts6ndPnTfD2M4g4uLRHJhsizEOrilLCam6FJH/7J9Dc4lO2o0N6jj
OazH+CT6JCPkMOugCHjmm1sWsUWIZVmGt0F05kRv2YbQRxN6otBbrx5+mXjcEAkcyNXZBp1xxPwk
Qgte9K579HboftNjjl48jppYJEgn5dvwEkZTQz3sqtkJ2z77FFJt7Thg4sXsZnw8PC7ZJgzSqcEL
1LQ0xYlmblqmSpLodq5//vII2Ih3ZS1//TXo3acvXqEv8qnmdyuDklO/4qMVHNIH6BefBsDYcytg
2pO4RHXuECjEpalVOBDffSLpej7jQa5KtTt2Q+rLJ8DVjz4OZ27Bm7OI2lwNcMKNcNd3xwDdLpD6
5mB46b9XQs31I5CHR+GKdzry2n08vKnMksImORx98YzosrF4FiTSwHPvhqO6peGTk26EH4wZAacc
1QN2VzcAXTH6oKoW/w6Esd8bDH987C+4BDcUStdQ/U6EK4/tBQWf/RNcefMJMPq0oXimUg0DD++H
ZyZObJvxaEb5PSpQp+BqE06agBPO7cuFZ5itqIMa7DZVLzyOhdFw+be+Cn0xd8EProbF1z4Er6y5
Eoa9EcFTaGfDLx6aBL0x34pnS6H+KlmcMGZMgGNwqW7AZefAH28vgpu+O0otO36zcjC8/szf8Wxl
pLsMKcc1pe7+CRucSCCK5wIEMrQUpgZdVnfGIDEU6ZGV+QEESSCtCEE0FMF1dH2WJbjICxkFGI0q
FHUWxVW9seTX9JcCepYpJigjKXF4Upbzom5MUluJRTI2OSnjU3YKEXycKJIM5nnl3pI4nWHUzZ4M
PX/8G8grxSV9wkiSksolwYqQoW+Yt+P42JJqgyK8rpyiV9ym081Go/sRivE5CLo4zWcTkktnGevW
r5MkoKUm0kma6FbbocOOhb++8zYMPGIwHPdPxye++yqJjaH/WgnwzEOwquZSKKWlKRwsj1Jt5nWa
gsPPgruvXA33zp0O1zxOqP3gvJtvh2NwdKaj//LB/dTgSpx0Cy3X4O1n+DeKZ++QhGBLOIjjwDt1
9vnQHVFb8LvtpQceBkf010N4X9wunHEB/FSEeqAz/h9xxniAx36s6lexdAnAGTfBYXTj1UE4FP/t
Xrjg3pWeQRrVcUfRfve11MnWYXHSrLgEnvzvSnV2RgjNW9+Amy77Ecx99ky4DJfV8FwObjj/eWK5
qb6BljzDeS044Zafe4aaMEipINRf4qLHFSfCIKdbFXavQFq7agPi4rky/tVtouLuVoMzPDhwmbRy
lQiT8TVmkOJIoJjywOeGX9ccgj0vfUoeOZCTeEl1ksqxMWmDabS14dhorGPjMbaNx3pRW9Y3ZbLF
M3EiynSsHLqSoPXyKrpBz3sWqEILXcO4cwL0vOMxPWFQ/GL0XevJjstd8WwzdGsvzU8FeK2mNb8N
zzRa03hZoAlK8bW3YenAA3rBJ0UfA13b2Im31vbE5SJKtAz19w8/hOpqHFScRGcZ9NwG6SRNdHX+
K6eOwuc/NsOyF19QZylE24W2+vTtB/3wgT+ahMLOdOLsFB3+L3AmPATPLf4twAsAZ97zz+5gqXXz
oLWmCkpPnAi/HjcZ6qs3wOu/+3eYc8+dcNwJv9J3wYZf8gFwebKzYp5GZuAlJ7RR/TFUhTqLg17F
IXDcUUNw6DNTFTw04Ufwwbm3wryfngIHlqRh4WVfh6X4ShiVep0IF+Jk8Nxzz0GPP9TChT8/RpE/
XHAjzP3DYJj2y0Xwpb7lUPPmfXDZT1gJRZqkvxoq6d+ivl+CU9Dmoq27oKUY2/+Iy+GXD42HUrrF
Garh/5athkOO6AE73ori+a1F+4u9tjZTf+UgIfN+u7ko0VmGe7ZBgFj23XAjy5GuRDIzdDUKS8Yy
Ss5m0tMlTS4FUYgjqL6ioLsIZIvpvCWamdgi0UlOlp2iT91XICVMQoezNjEtnPivXpKKFq/Apd3C
gUcDTRg7p30Xek57HFJYpqo0vfcaLk9F6zOXbHVFwqtoQI9c0I9SfmNDozodKsO7mMLSQb0Phl4H
HaSua7z11luwYcMGqNpaBW+//TZ8/PHHAbWDDj4YDu6DR7kZpP6HHgqnjxmrJoY/P78U/viHxbDU
+b2I5R34HEfyxL2ANfrA6O8Ng3fnP4p3TZ0IY3Hpxks68E0f/R5umDAOFry5AVLd+8KQQYejiFi+
8hQwZzaWLJNt+uFSFb4KAOC38MKKKmiuWQP/OQPX/fFYPerpC2eVDOVEatwOG7HYr+9BUAKN8OGf
H4f5W5HQREfXlMph1GWj4d3HZsNLcDaMGqIPAOg9Y9C3NxxQkYLtG1+B2bfjmUC3lpBaUR1kPQiX
E/aN2s2weuMGWLdmjfote/I+5cM5p30RvnDK2XjN51F48o+rcO0uDWuX/RJmPDBdXaiP4jE6b+3+
Njv+mm1KWjYao4XVhfm53hr22DUZVpl3zdsEXaYlw/IWlooH8a2GhILEMPwWUvas1LVLaKopR0MP
p0xtsh4heCiaKsoBdlgchI4FMWiD7SfY0rhKg37Ir/zGe6D0y2PVhLHjB9+C1GCcLEi8Hp9Be2EB
1Nw2MVQ3gJn0jERZ6MiffJww2vAyBn6ECU8UUvTARhE+Ip6XCn8unJamvnjkkeo5DHqA77333sPP
/6XcJ8LZHTrLKMeHQEjW+qwFC1q2JH8MPhRID7S9hdc2NuCV+gZc+lqP2424/PUFfO7jwAMPtGgG
Sb4jPoc9+KvfgHJ8DqLb186FI8SoTUf1NLaWHVsJN4z7EH56+0R4yunTZ17/UxiG4/5aw0SqEIk0
H2DyLltopVQhrv930/miIWfDlV9ZAHNvrIT5KNvnhGNwcKVlqGBKFYZP2lAyFK66cjTcNPcHcPFc
1MVlmlNPqICX8O6jv1YuhC+hL71PPBMG4hJRaeVZ7nLPF07/Dgxc8BP4f+cvVAb/6YTBAG8thBse
Hwm3uS6w32jfqZPLcjKpQor78zDtCrn8RM9p/AzGH0UT1Hhc2tsAP3rgevjjA1rpnBse1rfi9gjn
fYii3cSbZzx/FyGnHTx/T4FfnIykCo3t/pVlil83PkdzGtAV7MIMjUdsnrcB8ybDLAcUkCAHOmlE
0m16Jk3KZ2rXwXIggkgmHpdREv/rEtMISyKwn/E02r/NpFAltNsIpqRRtmD5JcIEfMZQheRw7R/J
UWcA3XApuXn9+7Bj8jfVbbVNL/0Z2mp3Kv2Wd951TJvYDtnYkK2uSPSJ14I23Lfw9U1tWMe8444/
rZ0G6lb8/uuy1/4U6UN9XS2sev99qP7sM3WbGj+UR8tG9KOzkaFHH4230Mq9ORIywKSJ5xM8e1m1
cgV8vHEDfFq1VU0e37vyGjh80KCAfG4IomOkG2F3UxqK8aMjdGFbJ+TrPoFFQVNMLjuigU0eNNfX
QbqgGD9iImargFwCgvINJ7hutLCPq/j1aScfpUtyjZAqptcAaF9A5eP8jsIM4Tmx07YMmSieT7TV
8bcb+ov9FG+31v76hFR7qCZxq+FmDMGuLIp+5PYXm332NVJIKApct/8RW9KFuMqyDUmX8ja+lJV5
Ty9+wJa4fj09yNn50lpY3mabZP2Dp8QPRfIY6CJ56cfw2DrHmF59PDoDEKUd1p16GPShjhuSCo4c
DG34Gqb2XbxKgIsBL65H6TzYOmqQo8X2QkAcchXe9XrESx9FCwluw/ZtQI9N8Hj9+uuvC67O8iUA
GodPOukkRfzS8NOhDC9f0IlCK55x4ApKOQYsDYVt4WcajEyTwfATToTteA1j8yeboB53aDJShu+G
6tevP04avTp8AZvwBhx2GByIDwt+hs960FkGXWyn5zm6JKVKoCzQ5tiIvgVqs/NEe1aEMcavr0cL
JeH6fEvhhBFw1IJCcny9qh2K8EFM6tydknz+GRaieEqUYkp+FQh/8dK28tfAcvZTn5ohsseLkSGO
6z8Gn4s+TCZSTYmBZSb55DgSzGR5piffhg3adgSy5/jl5IJyHt/lhVRDes+yqppuXd0Msy1bCwqq
RWtKrswzvAFAIjYxR7z1A2/dovTCi3F56lgGgopb74H02hXQ8PSTLi0yE2EnUi9DJq0C0YttC1K0
roLfCC/CO53y8UVUSW65JVsEQNcs6NeZiZ4yPwx/fdT7rdL4Ilu67TPDRL3cDaybcUCoA5k0YhFN
di7OsyyXWZa2YYllWTdMbj/d3hYUF4qh1yb2gWsvjC+6za3Prau89LnqK+i6spJkybyDynHwjpBR
KHBgw4o2UPYqbqsrwghSWqGzCcXwFRxRoqF2UFhCeXlHnAjZ2uSjZQ+0IzmbFxF4bSif8EJ2z6tm
+IDKx1yI5Quh4T+TTRr4tESXpHy8w7YAX4lOV6Xa8Sq9+txrPn4FSj0Z3iUuZGYkk1t3/chOY9PG
1pdNoivn6BGYu2f6kf0lV9FPphAjy9upDfb+YtYRUDHF2KqWsrZt1tA5UHRGPdzQGK58dFBVHv8E
+4SWcrtboE5M8NDsGNq2vd8xRiZV1H3YpqHQvD+GCPtJWxKy2WYZR5VFHWnJ9WmH2nRw9vQmrLoW
v7aMHGihZkDyBSYDvQxF87EX0122eThPFBTgW25xEsGZET9PiG+63acS97qEnUyJ4x/fzhjQZVCK
FDFlWUYvfGeTUvvzcRGQewVegMPRUFLitDuHT22ewIuwroHaalAn5/jMwJD1DfrKnLQZb9vXh8lO
En+VnPwT3oeVB64bhvPKFjFNOmHbaJqsOPhH+Y7qLjypfY5SQe/+0PTZFiiOe5lqB+vUhLfbkq2u
SAVFuBqFK1I0aRTiElWquKQY3yWSD63pgq6w30U2sMOjJb3zRHU/JeWdUISKqi4tfDcFDb5T1FKm
rIDZnw2JgC1mvqCqUcWTIp5XCgE1yKaOg2/FkbJxdlCWxRnS8I7IioV/GE2IKj954nDleIIxatE5
RbRqOuQYUv6y0wHjNkYIkKPLE2hwomNwGybz4rd0QTcqcXzdRkPxaI0oNHyedtIdUH3LRLyDCr9y
F3+ZOBrMwqUDpxZc/qrHZaKDJ0+zSOSelJ9foB7YTuGEQdc2cKWqAB9ATOMA25FQ5d7RjiLGTxhk
Qdc5WHWOBXd4KnM+3jOSVAgME6+yXyIqAjSyYAq2U5RSFM9tIUcoqm2ZZ+qY+CyHdNHuIusqMI00
IlEFJE8i4Roa1ZNjK67ZhBk0qv/75F00NyPZVqIUCN19lGZAPUDwY7klGT2ZdwW6PNPt1LMA7nkE
ts26A9JbPsm5fZo0UnjT0cGTp0PZV8fkHN8GWFiM31vCyYL6Bd1+m2rBJ6ro3ttm5yt8NqXc0ahh
KSXtFFo68782fGk7qoPZdKUHkk95xnVksOgNblJWYuzPJ4+Ac9YoFaKaT8qF5mW7cPtJmk0xji90
hH9WdIZymCxDCMxiNFX2EX0FR8wzmOxgidHNbXBJyrXmZoRJypp0hhSVElnFdVVUxi2xZoZbie7F
ISkIWc9z/yTVipajiUNNHtFiWXHlRf6uOtDHb4JjkPLwwT59coEfYcJnkHH9rRXfP9W5STZu51rK
PTr7HtPBWUw5ECObeyf3QUQ9iKlIcjgxxirMTqw7NkjGhczXoHHCHp999SheLoLnHWx44l4uTNH0
MUzOQwrNIZRV20oMRUGGnuhDJVw8NxMq6mdQXVnH6Rtc9AtmVCIINXEI9IwA9nFhelsJvg4dI0/X
FemFhZihtxi24NXxzkuyY+eglQOOys4UYFoIpg9m2VSx8b06qSUBVFFeuKKeT/LowETel8q5O/Jx
YosbFU43pv5oRQ+yftnwUgi4TyGJjE8htkB9Jjzl3l64LeZwsJ0y+xfnCsmZ11tYl6HFtuOTvDKo
EHPT/tq5uGqKKoRmudq5wAo1sgcYBdhZ6UJ4Id45lY95dSG8CR8Pb8dXmRe1dtbZBoeTapzrkCbB
Zplc2kZMCesUbTvF/kkjaU/ngGJonaxvYHBirHqRasqw9iTlMF4mvoRh2PCZRlsnYVaUmOouX3Id
mWHrO8xzDkm8ospJ9DBfDRVrkXEIw8lLkk2H+cSTpg11VlUi3h8mJ9yGGbOry/0tdwcydluSyu3p
67NSIAf5bOtGn7/INuHHuKGiWwXeYVuM317CaxqlBxwMtR+vUy+kou91d07iRpe9q6OWGFPiJMUn
3aSyEp/ypl3CMZdR/NiyoU20fancsR1UxFVkVXw4nA6dNuEDLCuzUiYRZl3SCdNnmRg+irGk6YHn
u5bgwUZZDR1xwtAYPcwf5odtGdfUZ7pFz2RJVeRJtmJ5fwwwlpQAJEJ0prEM0ZlGeTN5OnJ/61if
NG3Elz0v4mWzkehI3eQ3jzKx3dzcDE34jsICvIsqjU8Upr541nn45bdqqKv+DNtKN5BspkzA42Xj
kb0dKgrNwaGN24/cTJRiB3nSf88ehc0rkQmfYz6bXd2JfcY7oSA7cfbwGC8OLQWSg2mEkUWytxOn
yYZtchlaRyh31UbBSmzG0rTQecLnBuuzro/ZgQLjMkQCfFIhMVPVIRNSsv1YAph22YBpjOWkrrJI
f/Z4Mr1K4hDXNInsnpAh/+jlsc1NzepNt6mi8mIoKDkIr3TQScieT3oARk9C9yThpdtCbgYrQHxZ
5jqxno3HMnFbqct4WkdZddluJg7Q4OszFoMYWqQJKMmgzTswy0o9mQ8z1LkTnRPHDELG9QnzNzO6
arkIFX87a8EoZ4nnYFrFbHgR5gMsxg8wckBI6FuEmO4rUoDy1kAE/HUPviLFo5jJbQWM55Cwa/lS
qHriTmj5LNktt6reUdUSvtE+XHhQf+hz6e1QccKZgpPLrD+OdLMUXtXAN6HjtW+82zZFH/xow2vg
nXodPMP6+F3Wyu14S3Db7gYo6IGfQ3RSO54ytWGFCgLfCTcRqCyTbCHmSZqUtfEdGm4opzRDJzmJ
FZcnJLbnl7UP7nZZvyaVkk0uQT0bRdoMi5lNz0aTWAbfZPnKYXZZKIxv2AiJtV9KYhG+LPslvVKc
TBzfQ7LnOqpvQ+XYmTxpS8u4kk4mOImzDglw3sQNlv27UHI9jeR6FQTuQgpNGJ/NugrK8Y3SxaVJ
XiiamXM0aTTt2qpstE96CLqfmOtnNYJtRndNFRYVq4WotiZ891RVHQ7GeP9tfQPeg5uZ/4mlg26I
wRZRmB/V7I0froW6pS9Cj3O/BkX4gSSaLGp/9yzOdq1QfsHXoUB9V1wiyHwSV6O8sEQGxdkCa2or
/lISy0lk+Cwhiawp0xFdjcV10jX2jgh12bQXXvbjuAE0w8uwkk55pPsHFpslqWTj22jsl59njxs7
55fNrJQLjMwsRkm7Z5LslhtCN+OoO40gSnrQMOVIgMEcYbVhmk1eyjGf5SUvLM86YfyuoVc9fieU
4+s2imknSfjiwow8Q1iFjY9OkK3cTRrhsS7Ba90lZSX4RdV2+mofpJrwonorfvuVtp2VbM0paZzn
rc391vrdUP/8y9C0dgMcOOFiaNm0GT57cB5UnDUKKtRIYtMyayQtcJ62rOtsxcbdoUyoQJmUCItx
AwKJCVQd6nNxScrwmQhv1eiqMOjNlHimQWBCwZVDcjJ72iGGoJK7Zk/YsUnru7FWALFKPoH4yMZL
eIDsj0fZn8MIuCF0M4GwKI73J8D3E2xxNhtfyoTZNXX8VvaWUvO2T6CoFL/Eo8akzvOqCMNBtjqW
ZNwZKRj/Ipo0ikvVR/fy8/E1IqTGP1bbU1sOtO6P/iWVUvx4Sc+LL4BqnCi2zZgFbTtqoOioL0B3
PPPIx2+SxycZDMpTrZnGZQ/FFk6P66iiECNonsT0SScuuDEwRmQerE0glic653mrndMeqr9GR3bl
UNBgmWawHIxIkGJRUySLpD9wfsUwnq6EX9aHLxUzbQuUZzdD7VhM7zMkrLTb52QcuYIcHCxb4+Px
bX3V6182bLYRxWOZvXxLZxcZnGGUXnoLlJ05QVWqtfpjqJ01EVo3rIE8/CxE96lPQ+qwoVD9nSFe
pb0wZ2THA5A5ijcByrhLA1o2Re+bKkypJ8LpDir1anTFknpatsv+0q1gmzZtgs2bN6ur9LQsUIhf
iToYv9kxcOBA9bWpAvziVMU3xsKu516E+v/+HbRVlMNhU66FkmOOQj+DFY133l5h6vB2jh+R5FTy
CfsKfgWjZF/68IRoJ3NteORAjnFoAuB8QCgBoaP6CUzEi1BMk4fQj+fT9RX8cm6JDKEcizpZYmfr
ggv9uc2E1ZyCJJMp5wXPlJRa0ZE1Mf2awRJZylQniNIplIRuyQmD/CjodShUTH4Edl4/Csoumaom
jPRHqzq5mvHO0rhC75emC+J0fUOdaajARbd2p8SWQGtqauDFF1+E9evXQzV+EZAcow890cOGFfi9
8cMPPxxGjhwJAw44EOr+tAxa1m+EstNPgdaaXVD3vy9A0RGDoHjIIPUqFLcPBfoTB8aspJ/OgzRL
eUdHUdX3Y3ijUJgOo4fxc0xPOvvk2KwfjmIUX2+SUNF0Mw6KWfaBS1yZ9wmFFxzXpCb1g3b3qDtc
dd/miIhQlru5l9HVVwOKw0YZVywQnHCOAxTQCBKET4rpcywovgco7bjUTzcXJUllY/QZhpRVE8dt
v8ZVlJMg/dH7UHPnhX48EQKy1RWJJg06qGxJN2ED44VwdbDFo2VXeCBs1NbWwrJly+DVV1+Fg/D7
4scff7w+q8BH1mt27oR169bB22+/Dbvx4ZIxvftB+9wnIHVIX3z98BWQ3vARbLv3Z5B/4AFw8M3X
Qz5e3belNN5hhQtyqqJcTRpH03hBB/ATpCmeNmVjuG1BmTTU1dRDqlsPkJ/41hOKK+iYzrwTE4Iw
7VXBSvTYiXNc6cQKnSXo1DQsRLK+Zlhdl0yGUHJZbsbVissIFCFKOHaOENoHs1hnqrYMo8pLAlcb
BZFs42iJcI7msyGSo3w2ifXibGWDnYUOudFBV9wJYzpOGHgtNzR10E4orsGgCLfiwXxrSyvk4fIU
HtPvmUSPtb/77rvwl7/8Bb74xS/C1772NTjjjDPglFNOUWcWo0aNgnPOOUd93PyDVavgDZQtGH4c
9P7hNdDtpBNwqepf4cDvXwqFffv41+O5D6lqNcKzN58DY0ffCmtxkqREcd6weBqMRexnt+KEwgkZ
XhtQDn/pTTBr3Fg49/zz4eG/1bCk5glpby/zEIRwdNanUgfzx42GcfNWWHTq4KHRo2HWO9IPT8xX
bY+89+Xc+lLGLUQPGZ6YqI+txlZBoSOzNn3N1wcEUrYz8zafbbTO9IGxvZh4xxrkC/tDfHqWSP9Y
K7OtZ0PraUydl7YyQ81GOkk9WEZ56QUl3Bxf00iyDUFJb8QzjNtxwqjFCSMOJwQjl+R8eqEtnmGk
6VUkGAN1I7Fstlwai8KiR9NffvlltRx1+umnw+DBg33iPfAaBv0OwGWpjRs3wko88zjp4ouh9Jij
lVx+WSn0vGQ8tOMDJvp2W0+d6qO7eQmcc/dM+P25U+CKWS/C8zefhvep/Rkun70Mhk2cA+cMML47
jkq0ZscpvWk5LKmtgGlPPgUj+5Qw2diStQwTqpAVFXdTvRwA/1sG0RIYNXUKpA/v5jOmrkUQhXBw
tGPvFayi+cRdvqZK43QK6tiVZL96x0sWn3z7YgjfP5DbHOSas4sWIGYZW24Lg9xFRVtdbLQucgfN
BK0LCmbdeGGeOG7k3UyUr1KI8wI/SjWS5/MkUtJk8vKLSfeVnU5Kspxo36Mk9dvxttSOLBu1qAkD
x7W6kDMMzzyuFHH82KNcbsmQF9Nm9X7CVvVyW32igTwRi1xaDsWiSWPr1q3Qq1cvGDBgQKgc8Y8Y
NAh27d4NzaV4r7B7awI+o1jeDR/26+F3HuPIoaQ65VUMhx/POA/g+bth3hvvwLwf3g3Q71KYPl5P
PmufmQ63LMCLTSq1w4al90Ll9MWwfc0i+OblDyK1FqZdPBEWranDfCO8seBeGIdH/KPxN+mhP4I6
7k+vhnuvmA5LX1wAlQ7vilmLNY9wa1bAQ5Mqlc7oS26Be2+5AqYvYpskkCQ1wto3XoSNO/DsKL0B
7q28AhajT9SskNcIixFzwSpd1jQPk+LhxsQjezml4BRl3pPIMkdgFkBF9njKP/zjTlrCmr9fMhbX
RggGsklkHCXHth+Cbfmp+3JJ7S+i2jr2msA8VcKGkm1FNEXXojpELoG55jYqkknbjuSSykbZQ/+x
gnJC4DxPDFrbb0/rkAv6JhRVjjszkHzDJZow6h+7Hdp3JTjDYBwDozOKLfj0d1u6RS1NFZWUqDfd
ajuywTvDcggmLVPtxgnB3ziecCNek9iN7z0h99I40egU46zRj3qN+D5MO7sfPIVH6k9tGQwzZlcC
TjWqp+/e/i58UI3XN5zU8PF7sOXdKmjveyJMOFuf/Zx9zffgxL4lsGbRdJj6yBtw3tRZMGva92Hj
wpkwZf7fcC5pgPVrl8HMGYvhnGnIm3oRrF0yG/4HB3GAanjossmwcOMQmDZnLkzDBzhfWL4W1m73
XkVvuMuuBLZVbyyHjxrwFLGxFt7bshaqKK9CkYaqD9ZCtTp9RDW9t2t95JNIIGJqFNAMyUvqiwYP
+2tYVP44VqQBFhM0kbU4zVzpMfkQRo/yz+GxDwJShi8MYd+iY+VDKq26iYiNqreS5Zh7kVChdKBk
3u2AJo6naskF8S1CBikjA4auLqqB3+G4k4JTpomSfl5/ozxVmLZOwhso1NkGnXHE/FiFtjRh1D16
O3S/6bFYPcZ1j58lUM7zWLlW/AATXtNI4aMNZfj2DVytUm8VQVOy5jm3HACkBknhbbU7duxQF8Pp
hVhmasM7qOhC+Jo1eN+yI5+P70AJprgOloJjTz1Zqw0+HY7pRUcVDko7LQbRKp2DUUT0IiguHwBj
v3465gfjdhQMKK+Hl361HAZfehuMO3kQDDrhG3DnxCNg7RPLoFot8gGMnjYbxo88Fo4ddTFcWoHn
KGn8kO6m12BhLcCUuXfAyKFDYGTlHXANzkU0nXBiV7gcu3XsaTnSZgTOG/GgyjLLkWYN15bgu7Ss
MgFkjcJk3oZhs+txcq4+KxBB5l0BI+MBc1iUGqryoBAcGAyIfa2IIfGiEl85LavvqHFjhmoUfbMF
VCyRSDrq5xpyMyGaSLYiEj1XyfTWwXUHByp7ftIYREnXSep6Mrh+oz/oxGcCIdu8Mm+ZmSaM2lmT
oMctj0F+Gb4mKUQnSJc+KNdy+MfDLiqkb4QXQmEx/nDicIcfX5xyaDoMioz37t1bPZ/x2muvwYgR
I6CsrEw1EbtLk8ZLL/1Z3YpLt9+W4KmRTiTBDcXSuKVKcFEablwD905ZCHgPL8DaR+GnfzwJ7hgz
0JG1KWjlRnw5F8BuvNOKyh/Bmzj4r31iCpz7hObz3427T0EpgIN78B1caeBzosYdVcgZDP3UqQ15
XQLHjuxHq14dSmU+7Xac5gCca/2aw9XiMLG8KmuiZFGeVCSNVTq0RUDG9oGzfxZw2ReVmPfHIp0J
yaldbCUjnMvE3OdENjYclnqoXc1tF0TgkJlgWDZJwQ7ByhZDikT8AEoILQwjSKfBX/Y1n4QyGbTr
TRzIQwAuU56k1cCOR+Y4perJxQeqC3kV3aDnPQtUoWUD3VY7AXrcPk9PGESNejuHDANNLp2aVI2g
Fe3kF+RDAR7k0+MQKQoafsHP2iSd6U8B3lZ7yCGHwMcff6yWp2iCMBPR6DkO2tK1DZpUvKQr5JUx
J0lOcKljvDL7RlgOx8LcRbOh9uFKmDLzNlg2fD6M7OUoFLtzJz6b70N0CghWfjh8GeecQ676JU44
faERV5fS1ath+ftpONp1K9jaqYoDEWMt4F27eOsvwTXCile2AHyZ8mFJ+GMTQds0SRWlChxuK+Dd
y5iwPlRhJ1FOf/9YEpgb3Mr+GORmRyFM1yM3Q1jKuyBorBNSwAcYxLJRhEP2RzGywLTZ+YegcTBF
W2JWlZxmkq3FIVFarMrE2C23iw0xVjlzATRDu1LYpEKThW9JnQRRoQ1H2LaY5ycqbvgJFA48GmjC
2Dntu9Bz2uOqTE42vfcaLk9FuCuq37kXwj0fmprwqBknC3ppISX6el/Y7utpdUKOlqbowT36feUr
X1EP8pEZenaDJgq61kETC52BDBo0CAYOHAilpcbdTgG/nI6FdaLYUqPXrZgP056vhfNm3AZfQOLw
7+MyUfsWmHbr02qJKIWH6LVPPQtrauqgatVi+PFTOKDTipVIFCPAqyDDvloBy2beD69swBmgcSss
uec6mPHY+0IymC0ZeCKcguRpd82HDfjw4opF98GDawF6q2WwoDxRtmz6ANZs2KCW5WhpbtWqDVDn
XQJB/w6D03ACe+Wt96CusQbeefpeWIh1LcafEwEXWJXFROIyuijj+uNmyDAVVFCtXgTdZeVwHSuQ
Iho6DBWu0CFOpvAkb/7IAaZJZzLFlrrZ5G0+hONkJu3HMdrIzzRKuY2Cb+A3LFExim9OHOqsg44b
adAP+ZXfeA+UfnmsmjB2/OBbkBqsb8hpq98F9S8sgJrbJobqBjCDx6jkcs5TC14ET+NSO8WiDe9W
xUfb6JoGzaiZNFzH/aLTnGHDhqmH+mipiq5tVOHdVHQNg7rFv5x8srqrip7d2LJlC3TDd7EUqTfZ
xtnGU0YekFo3wM9/8ATkfRVvuT2pl1ZMDYFJMy+FZVMegZ+/+BX44deuhWFPTIUrz1+C/Aq8w2kY
bFnviBbSyO6tPY64bg5c+ul1MO3y87VAxYkwY+6/4QnEeqCTDe/IH/M48ejlogEw9ckZMOPKqXD5
+CfQxDAYhgN+tfWMBvXIzWUPwpXLtAn9tx/MfOZhsQTVA866/mx4asZUvVRWfoQjXKBrTk2JQeQW
pXiqMw5Hqqs21KXItv4jM+yZ4Ynjt5JUipIfoiNFYvMMGobF/FigUIEw5DCFMHkb3UYLw80J3Wk8
HRVpPSpOxKOjcMcDVJOaPr+IwXLJGI6UtuFTSVgwxzkaCOmnhz+/pzwpaL6fx+ZYxsNFOYXJEv5t
tzPGQ/P692HH5G+q22qbXvoztNXuVEIt77zrF7aVhBtujG1yGdEY1NoY6hmNPJwsaMmNDubzvvv4
n9vb081QX70NFtz07YxMZSvMLpJ+C16VX7FiBeyur4cd+CzGc88+i8tl+VD5ne/ACSecYJnMSNte
Oe0PThnSgCaqv0rL+yM4+NR3XSM+IF7uPPWtARjHU9F20411anmqPPAdDwHJ2cYN8Ou5f4Jjvn0p
DO9Dy041ML/yfFh62iyYP+FYlspq245+1LW0A/nhVtmX0f7KcKkp1ZXJymyoEu1c7hDBNhwXvDZz
GLRxeQ6kjaZYLMigRGSao2vdsLwpy3SpZMpgTbgDSLF9ME81t0ZEhSQYl/AQEIopH7M/EljAjumN
ickemHKaLptN90mWt7cpy4S1dxyf0JUMuvO3rxwGfYpSuuyZdXMFRw6GNjwIVrfVOtS+L65Xua2j
BrlyYRnp49amFvjSqx+HiQbon376qXr2jTDo9/rrrzsyXhw5dlSfk046SfFPHX0+yqegvKIHjs14
AxOtiquzHE8vYKwjBIalZqe82fy0PtYHL4jTLV10YbwOl6fa0GHKhycbkpbmSlt1lXHTA5LEgLgT
gPbYh2Po0eRirGBZzSliyQEAHzwFUy5+Ck45+2zY8fISWFnbD2acOzRcJ4KjXXHqUNwN8MOLKhFF
ee5mHBBHlEo6S0dWKKn/O0KdtHFtc0bHlqxRjqmudUlwBZjo6bryiTNRuoyfGGzfE6QQGCHSUUkS
G0Mxg+iQpjrOUDqqFKHNdkJ8imFHALssGijloMwMGgs8P5lqbB0hdZ2BhEPcbMVb4zmVXngxLk95
B44Vt94L6bUroOHpJ1kkehtiI1qJuRwwKksgWneSZVwtw2vKhUW4ioEsipG6EK4GEInBuFluCYrM
SkgbjeDpukX//v0pq1KfPn3UpFFBR8++kZslTGSm49YpDUx6AABAAElEQVQqr/m60f3BEJqk7C86
Ja0Rpse1sqo6xB5Q+YvFcPI7r8GK1Z9C84Rp8MPT8AWMCWcd17LKuCWrQebqpShdYppfAan6v4qZ
veZ+jYxKbljYetCCfSckeX1kypp2u9Fcu46NmiscG/bnieYcSLgu63bQRbcxXW4wY8aR29tPl6iM
kWhA9u2bEf4oczYrbE0PeoFxJQJSa3pnSxgp6qEeoJFrxyPwtrS/3oaIW+xx5d1unjLdzhwPgL/d
T/7aR/cVhGmylX0K8zFI5wv7LfixPkopvoNE+JK9H0LThmejCRWVpVeHKLfto4ojHqyYGmwEV9rK
dMKImHuEu2TB5ocQcbMlMGT4KPy5hNhMvM9+CNoR1Ckykm1ehXqLhpQ86suY+dEzLClA9iICNeCU
lvWaPgFGqGsRdkN1/tEZHG+Kg8xHxcUmRzSKv9meiCqaxc1SRsG4lCiD4TyFE4/B+4masAjNqYLe
h8hrJIQNAshqx6Oy4N7igNDGyYY7qjlbRg6ME4nmJ7QTDuIGPlwEOXn57VCAlwzUbV1oU73jFZep
QmMUhSZNcp62nZvYUoQVrJg/nv6SXzPGY6tqjI7fQMYl7tSZKqojKG/E9dR5B7DxWIonD1XG+un/
zM1yGxMna2zJlMmgMmOZPJtrLGvj7aeFR4DiZsbXLIdr+zk2PcQXZMpS17RZ9WOZJdZQCJopcE3p
sLLcHbyzD30QRRbCkpwwtFn869gv7N0fmj7bAsU0qHZGcmCb8CFCstXxxLEMRyIJNz4469P8oSuc
TdAJzPkRjFMfyu4FiSrEvxh3nEqoDuxUgjqU7FR+hIS4fqWuKfEEQdZkhTKyritPk1d4DNz9JAEy
xctMTgxlB1IiNllTNxfljthxfHf7lyxL3yTdzCeRSyJDuDKZdmRZypl5ljPpuSyzDd6KPhToB3F2
nR01IEbYmSUeEL2DNTs28aWsknd2EKLT79Ab74R6vAbQjM9q0LXZzvg1ITbZGPDD6ZlVNEvplpY2
vGuKnj9pxTupWvXyVDaToj2sWXqVc7XMOk50XTLD8leFkDPTz0zas0Z9l+cLxpD1YpqnkTRHmhIp
qZ7UkXmp7x2zxfsXL6GR0RaZc8Vt/rtM6UwG+bD6mBBJ5Gz+mThcToJHsknlGDdsSzgdjVUYtp/O
HqvlK5tJqyus5ceKK0koOQlwXulzsziTAu1ckq8s4x+134kO1+O0swB+8ihs+snt0LSlo9/wDtaE
fCjq1x8njDuh+6ljggIZUWyBDgK009OG+GtTD2fghXA601DXbbKLf9DCnqL4/KdCkoD4lEI8l1gs
nytsi8kk0BY1XV/2zxk3sUfLjm5VS0AklzzkBAqRIlxB2gkjBXPAZFu8zQHkXg+Rq6AyDm2TxC+p
nAwg4uIsQejcFxQKm5Zm3byS1iABk66QNBLI+6QcuMB+4vjAsuySBtNUnk/4DEVjtONgfhYcjb/O
SNJPbTcQhJyb1W2DdaZq40+9r4KI/qBE281ENhopV1y/R1QfbtBwC1qHO6uU012CKF4uswhJtEzz
0mamulqejt+dy9seQHxAPNmEOX/UhZLBoKI2H163ZG0mbERlw81Eae3nZR0Bo8EzwtGNJT+vy/tk
XDOqfuXaipN2BX0Z2k+8811kCZjAPqQ0HQG/cRczF7tZCLRro8szaudEq/TWXqwgXhf/vKVwj6nB
+BdXK4oDd86ArDJBf6j5KPGW8uH2ibtXJOlulzpkN6wjFowbtxVtdXIzTtmOx9LJt4STK6zkVpNJ
JvUrqVwyq/FSTltEmtVLNmo/UnKRwjEmyZ62yf3CruDZIGlvH/bodr1wKg2E6qhddUREVVDaF9bS
R/VUcuz42VrM68gsxerop+efl3PZKkMixLNB+yVlKTNpqZk0ryZPfGEhXtHAJSr8RriqgFOLpibf
e1JDMR3xUH5HGSoMogGi8dAbckgrRYh6Xov2C8hrswTmyfuFkjYS6ydcIkLDSZH9/ngl2TGpkysP
nMp6nd6TT55LtpSkbaBVMixDqCpm1o7jg7Is74sA8029JF67gA64qZMMU8bTRNiXym67qUqJ2GDf
UZEM7Iu6bcz9yBMTGBkHitudFAnH63sK1YRGceUji6OObLdM+r1rGStGei6u8oIMsEeYQSbX14yD
242ljKNLGEkSYRK+9IH0sq0bvf4j29SO1y/a6V2AqULc8qThNERxsfN4cQw6VaQzk+4cZu8Is2iG
NVxONq6twTWN7YpaclY7FmbAobMwi/k7MVN9WzTMVn30DAvcoXhHUZ44lWZahpCeOOIEa6Y7NQtp
G54Ud3zNlzX0ZFhX745eyUM29WRZyoflTVvJ9TmeYcj7Ct3rG3qA5jLXn8v++jqyTIwNa5gAtY/k
me3lGEAyc3jfZdNq6zJpYPU4dt89PuVInDxQakoZ90fpEvMcOdz4kqOiMbCQxKYPwFJgn0wWtwnR
M7VTVye/4mMiR5TRmeKSMijC+aGlqRnvnnKiZcQoAkEEOFKqq5hJPPeOVsgr3SGcijtuejQiqO7j
cHDjmnAzHi8yl0w+mVSkIStT4WLFZEezCiYhUoDk3kg6ZMAIlYTy6sW5CGGpmLO8tMc+5Ax8HwSi
wdKLWdyg5OsSqKb3IVtYomJPPM+mTVvRUIxdC3RDgogyEQrqMAgQndeeBCcMkoqCl/WOi1mcKy6f
QhJl1BXs/Ay94qm5tQny0/lqCKDH/NR/fQ9DMgcSNHEyoD0g5bWDVwvZ6OEd2NNM5rZd3k5NhphE
ijutV7skWslkNDbVAH8qaJnUJsojEydM1pSL8hsxwmCi1P7heZnE2OkGTsxo7FUDOsWdf4rHDcFb
M8hkM4FdR0RJ4x/W8Nl1qaaN8DLvMyThHwvCdTqbs7f4QfVsxdei19fUQlNzA0aXLoSjd/xLGghu
rKTye06OzjC8swzlt3Qe+7C/cUSnxqzaAZTzUimqNqwfIa8MEl//ZIc1kfkMQdeBsckvXS+SZxnW
JSklSTKK6KzPepVREqznSgk+8xjTv3Us4EaoCBGuG5JUGNQfwRdZ7aAgUNZKNGQSFiNMJ0TYL5Yg
Av59SLeg00u8gtuuLseCLPqOhatIsk0xT7bVD5m65+Sw/4T58A9Gp28f5eenoKG2ERp249vA6Vsh
NHBl+r0Fbru9t4m8ycJtY3aaCDGOe2yp5CKFZOJlgwOyXYfleKtcxlFaTjLM461ySo7kmKd6BHZq
p3KsFzZxSFvBCnsRCvKIYq+XTzZWJFZAwKmaivL+bOdGgNrG6wOyJPPhPoS1l4cZpqs0HTEXBY2S
3f0p9xEowKe/6V8rPuBHH2RK0b239BZDetw9m2TTim/2bCzZdLjLsEXPGzl2kqbH0ThKUxHpD+tr
Hv015bVMkOppsC8eJVc5NambFRLgcfxg7YSyyFIXiDCjJONsCbiE2aiYJoToJLHoSbOTjH7OYVVr
0h/Z6TqhiSW8f88zje9dAaUDtc9dvyKf6R8OEC0tOGlQsUC9tTG7lpWNl23zZD8QCZ+VI/gHSdaB
T4iSn14xpAauQAg/28oKvajOIwdwPiMQqm7Hs/FIjrHD+BLLy1Ol4+vrtVcyeY2fiSxpuA2g1ZVf
Js1hqU0YL4wudXOZN+MXZ1/Kx8lm46cNn2g5suXAu1YcWHUMGmsmRsAFFe46NDIj2bTPK5vZhKgL
dXi/7EKTHTeFwaZ3T6VbmqG1DT/3Sg9qpOnVtwnWp2QjddwTjUBfk/r73/+uPudK39KQ39ZIZgO9
ko7JvAMgdw/VuYjuI2oIRfL+ONoMKBUcltowX9LC88k7DdnzjkrkEYpt5+CB3IavkTyfbLI8udh4
nqaXYzvWCdoTS5Cj+Jmx5TLzOMZcTgCrRBgnqXxH5djPKJwkMlH6xMs0DjY89iM3MbL1Sa9ZyQbb
M31hupBhUlRNhTgjfl4mDvb387Sl90+l1bfC8Zbberzvtg1vqWpoin/4Izfdyx+qTzZvhv/FT7zS
MyJHH300XHDBBX6ByJLoXY5ckIIM4bjKinL8oCeEA75Ia1FyniIPzh4lOiflZV7uhJIu84zMNN6a
dFvZlGWZDm8xZBw1nnjsmCzFW5JKFmONl4ms3YNkVPJP2PIVBV2BybokQw9OEJlimD5Iu8RjvCg5
qcN5R89VczOOgMPHDa2HK64pwlBq68kz2aEoD20vMiQ4lmEdG8Xj7c9lEwHaT/GOKfVdjfwC/Nxr
Eb6ysLU9H4rwMfFsUrDRMkNpxqfQ6/Ghkx3btwN9+pXwIvuWghdWMStKPuOEk25oBCgp0S/ZIq4L
ngZ6AL6kRL1+S3RqV8DBCvMozKqj1uWbNNRUVUMtrjmW9jwIepWXdLkHdoNGnDC8OsJmnO3anx8q
1tOoque7w2C+tepWogNBimF8k2eWPS90znQiDNfUiyqbGNpG/AGZh5lIFmHZe5Inq3SGk0jXM7U/
l2EEWvG6d2trC47PBZBfVAj5jU10ltECDc0tGUJpcdVwmM12S08Zqovw2PJ19fW4Zkb3c0Ulp+dw
7yHDISkPqmDO18+BsZXzoNonUw3zKsfCORN/C68/OBrO+Ok7Yp8kYLKBE1hkb3QMsx8+fF2oWzEP
Ro+eBzUWXi5JNWuWwqTRY+H8iy+Gyy67DMafew5UTl8AVfrrjLk01UEs2UtsUBxM3rIM63F5b9ka
frpuuhmfoyStNAw1n1BOCtkaoIO2DHUDFXL0cSOjEIkawVQYDERbkUgtsItGYAnV/dkMItDa1opn
Gfn4nfBSXBEqg1RpCQ7aeMrRXlKUAYxflNqJ2zPTNutWVqbOMOiQoS9e04jXR0v8aKjfDUupD1z1
8DWw5MoH4f5Fp8I944YomTWL7oentwLc+uvzYcinvWEqeF/Akp1Q14lrZsI7noaxSZwuGFUAFGHd
osRM5EzK6U1L4bwrZkLFKRPhkWvPhgE9UlC9+mW457qZ8O1P2uG3vxgPPTIB7FRZillUJIgXJ9Op
DmYIzv6iz67bsn5EpKRp9LS17F+Sp/NhfyWmlGF8SaN8mLwpZ5aT9lO2i3acOuHihWeW2MoF7Yf+
i0Shpixz2XRDlrWypOzPd3EEaA0qvwDPMpzVqPwNq1bChg/eg0/WrsnaFdmulM/k1/OAA6BbeTm+
DCsFI085RR860DlnZPL4wZ3Qr1gyZBzMvGgwLH/wRniFTjdqXoEbH1wOx0ycA6P6pKB24xvwxtpa
1aHXPHMvTJo1H346Cc8+zhgNo78zDd6p5sP1Onhx3nQ8c0D66PNg1oL5cMsVs2ANrn6tWYT0cZVQ
WYm/KybBpCsq4d5Fa/VOUrsJfufqVcK8Vza5DlavWgyTxhHeaBiHWGyrcc0iuOKWh2DRvFsce1JP
7mmN8OyDMwH6XQrz7xgPA3uV450NJdBn6BiY/cspAGsfgd+swPOc9Aa4t/IKWLyG3j1D+o2w+JYr
YMGqsHfRkIz8uS5nnkGYuDbKHHQv1FBd0uuXnoeS5uRdWcnzNII5agtKvHVK3ES6KP765RxpwU9q
V6iEZulWTGRKyADBU1Yu4x/qEyqPLNpyMqF8TBaybMlkhFmLxn5S0gjk5Rco0TZcBVLXN177xd2w
/PH74cMlT+qoc/S7aNu9ogL6H3KI6hu9Dz44aR9RlYgbjFQnQsnhE26Ds6EWpt31U5h1xzSo7X4e
3PatoQqj7tM34M0tu5TddN16WLH4Cdg4bCrMmXM3jK5bBnf96m0lt2rBj2DGU8vgoqmzYc6MS+Cd
R56A5Ws/gF04pxxw7Fkw5arvwRXXXgtjDlwJK9dthf5fOADjSWdvy+CRNw+GGXPmwKSzAZ6adr+a
aNJVL8L462YDnDMFbc2AM2EJTBk/BxfUcIxvqYO1yxfCg28eino/d/QeQD3evXjbBFUf4Jwx5gQo
V16KPwNGwEUVebD4zY9xjqiD97asg6oGXvpLo95aqMbXAwSTPhpWOzWbyahVJCIC8GDiYkm+kbc2
aBJFA6fLitI3rigbJ55J07uYjc5a3pb05ZkJlqU5FgyaYI6xZUHeGuyMiiYGleUvCMaThMlhJNZ2
YVhQCbhcNTHwfu2K+GRUgVn7tzmIAD7Fh0+E4/lGXr6Kf35xaTmUdz8A16uSveE2Bz74IOiuqREj
RkBhYSG89tpr0Nzc7OPbC3Jnskv4O9YAuGru1QAr/wBLVlbAlJ99H3qhmh6jaLjFV/7i3/am3QAn
ToH7J4yCoUNHwAUXDobal9/DaxJ18NbTK2HwxF/AhFHHwtAR4+D+H41Whgvxb68hI2DMmFEw8phC
eGV5Hpx4zRyoHEYWKFXAjAeugRFDh+I1lMlYqlYTzeqljyFvNFw7/qtw6KFfgotvvAbLS+DPa/j1
9KR3taP3A1ePEN3UuA1W4EnS8EEHuiQvUwB4AqeTvtbvsbok541w7j4daRfb1MrfmwcB1WvQa5uP
NhpVMIwuK+9MEEZA/EUuJcGT2Jnm2Y6p13G7ah9FGBfJzSCN6CzgmFYTj+MO800Z08v95RxEgIKt
Bkva4udeK3ocCIUFKWhsxAFzDyW61fbYY4+Ft99+GwYPHgzHH388FOAaWmgK68ehCniX1JAxMLHf
Q/D08JthzAA9inIf5b5JC1EVQ/o5d1rlQUszxaQICho/hldwcB55XF9tAe33GDAI8+/hj1E2waxz
b4K1X50C/36uPosBoAnwTDjKHbwLxRkBTSrPw5XnPo9bTngzAN3tlYrSY1nclvSFf+4HsPBvn8Dk
kX0Eg7LNUL0FoHd5KeYboMzg0jkQT08GS+2wiubGmetoSpKAjecoMtsVcTMmkOqTqh2seAHxfwiC
G36qra/QldUPb7PkXgSd96GGF3wmVP9woXxKPrn9hRxHACcMfJOI2jPp2lWqolsPfGgDhw81k+TY
WEK40tJSGDVqFGzGZzZeeOEFoLUzou3cuRP69eunHvgrwdtm8/D0iHYet9+E4OvBRzJ1B6OhuLy7
GD6RHJC1jaQlh8CX8YL222s/g8qj9QxQ8/F6RGOsRlg6/bt4nnA2PHn7GPDf7FoMtukv3YwXWAZP
VBeqixvxKUvYDm+/vBr6D8LL1riihG+wR72wmvIOUw5fHF4BtQt/Dxu+PxwG4lxYs2IB3Pv8AXDJ
v2yChdjMk0YMwPWu1aCmP/VFeNJthVqcBIPJsMdmfIIkY2X4pJTrPjFfwS+LwppLfxPiGwh7TzE3
/nNLyP5pRlDy9p76m55wTTy632+zVp5cMIeymYgjQPQdkEEL+ynBCKhxF2940EtUtMXJIo23VBXQ
mlXOUrCjxEEfeuihMHbsWNXIS5cuhcWLF7s/Ku/YsbNDE0ac/SBf9s4eMOyr3WHlv98DS1dVQdX7
S+H2Gd4Zwiq8ED5zGcBFPx4HqapNsGnTJqiqxjOGiPSFU89RF6ofW7oKzyzSsPrlx2HqzGnwiXuZ
IVkMR1xyM/TD6yaXX/MQrKiqg0a8HrJ8yUy4bup/ApwyBcYOxGXH8sPgNJz0XnnrPahrrIF3FtyL
EwpNS2GJ6s715y3LmuVkfrJ26NaE9QnmyIYPszMKOfLTgfGFhAo+Qmf4H4ZJDvGPZGQ+TIfpYY6H
0Vlv/3aviQDOEXRfXQFeEKdfio7q2/BTfsUltIyx5xLNYscddxze/ZNS1zbWrFkDu3fvhtWrV8O6
devgqKOGQq9etrX7OJ+dPRDFyvnEQKjQXbF0kkU/yuuk987CIlQo1/kRk38Jk5qnwMxrL1Yiwwbj
KLz2QPQXr3c8+5baj5669XJ4ykGoOG8mzB+FBRSz7e0lQ8bDrGvWw+SZ18GSmdrweVMehhF4olG3
GctKzwHzbbQ/LqnXCHjkl9PhvuvugMkX01SgUz/U37IMn0OpOh1G9ukBZ13/NXhqxlQ49wnkVwx2
pGznQA5LbQxbktUpeR0HPSh1te2OVIj9JoyO+q2xFErGUKhL6hnrZVJ3WdfkeuraA+1k2VUsuaH9
kjmPQArbjc426FkNmj7yhv/zqPYGfDQ6hffg/vX/Xs6RQe5Ymfde6lwfffQRrFyJtwJv2ABbt26F
Blznv+baa+CIQYNi/fOf+oaIC/eoH1Py+rLN51ZYsegJeLf3GVD5lYFKfs2iSXDlg8Pgt89frp+D
IBybqpKmPyFMXBqso+WpknJwHk53NeyZEBwUbqypgXp8JUxxt15QXlIHS+ctgH4XTIBj+UGNxnqo
wws35eXd7NA+KgfJR3QK4T5oAVPXlDeDZcoTiqnjmE60MfETKWUpJH3viM9sHvEYkuACVWEbAYYW
dsksx7j70tat5L5UqU6vC73nr0ePHmo1h5btXn/99YBNXs6jcfikk05S/JNP+Tp+6rUU9QpwOR+/
EU69sgALbbhE1fHU8cYkpw8//HA46KCDYNu2z/AsYy1epG+EA/F5jswS73GsZZaRTu5iip9oUlBR
vgmemHY5LD1hNByDF8CfX74ZV38mqQmDJp74XdQxpk16f/G5CvcuJ48akou2UoIdwrueUg5jJkzw
4+DEpK/IROHY/LTEzo8cUZK2GFvSbKpxfJsO08hGR/QZJ9NtNjbt8XCpnHFdkTZk3hX4B8l0pO5m
UDuC9Y8RblqNokGSVoMoWqk2fOUt7WR8xJ19GHLbGN26las33/bt2wcv1LdCWVmmy2fSH6qqU/Zv
IoYXoY/ZgWfeAb/9wgp4Y+Ua2FF/JMy84nQYPlAfwsdPOsmj6puAfP3ZV0gO6EqK+nAsArWXMqTI
NiWdaS6wJcMyUk/iWVQUifXC+HF00x7JE62juFF2CdtmN0qHeeyX8DFbKBOSy/u3IgK24IrYC8l9
P2uLhb3W6kI40DVvfcNKKo0vomrBJY3uPbrbNRJTeQcgBZlPDGAIagy6a4p3SqJEVVUO3mrwdd3Q
WjwxEtnFcmWYYrHgyPQYeCyMwV92iQ1Z8AWgkmJXXDrruoQMMtH2PKAwuTC6p2nP2fSI1pG62C1F
U7vCXkdtCH3M0lty3Oi5LDcTXl1WUqK+AuqY5XCYvZ9DdUkQD7MiOQ1Blj6YPu2xcgbxw2cz8vCe
W/UWkTa8e2p3Qy1eBC+h26j2mPvxhqmC+JOzglAismY5ciRNWZmwei7X4flFzPr7uRLKlzfVfEwq
uFYxbxMWfGbzNoDVUQLb4rqRoTBjJGPj2WhJ/IrSY78IJ0ouiR2uWxLZvVwmo6o4cWMdKhqh1AdN
BnEvD4HdPa6knWun6odHVe3VH8Lgn10jmpqND9GIeyuXLl+ovuN0nfxSugCLFzlqazv7Xay5CIn2
mptabQNt59TMZo4VmRfQjWU4AoZihElGtG8ZJwjgp1CJf3akwAihxBjFZodoNjopEp11qSwT60ha
XD4MK04vU342vmVqowvksRoZ18QMMQEoEI+hDqRU0aN1QW32kAmzjvodWSoGGQd3D1VhLzFLj2Xo
8YCubeCF8KJifGgOzzKaGhr2Ehej3fC1t68Qomf2nRCxzMgOaCJsKSQdJrrkYVGwaYnCnoghBJVQ
qLCQNXVIMUpPAXfwj2nTLNvgk8jY9PZ2mq3dLD53pElU6OgPgiQ0Z/FgHyHZ+pGNto9UtxOrkYcP
BeuFKLymgf0qVYJPXtMrO+gts3t7ognP2SUCw6b2nfaUkCT6C+MEJYVQkOmnsKkMVDwAVvYogZyL
62YCIh4hTCaMHmc/ju9ZtuekPuelLzaaHSk5lTCljeSanS/J9c3Akq8qvoIdxCaiQmIwjKIdbD91
fwS8CNDjGHT5Qj2rQe+eKinB71kgkSaPvTvpK/e8+0UOEcxkYWNHUUWDFqw7KzOHFBwabijnXTcR
PHdaYz3eskETl/ldtc3GPvue1EcpL/Okn439OLudgWmzSXbM+tjkckDjKmViTrnnKJp6iV1PLJiD
Su6H+DxEgB6DKMA5og333Xw81Uh1794d0q1pKExl/xGmrqy42hfMHcJ0QPJlnuScfcpUiR4MCMRT
9HYrCe6XCeJ7+n4eY9j4zPNrdF4prg7ZWvYiphCMYraonl5Xx8mznCyXoX8+cW4TH9FqNjKsPnVf
wYrVMSL35c620zEv92sni4BqRXxGI58uaeAEgrfctuL3X9N41NyG38y2va0vGXDnSmEn5D2CtwGD
VDXurDrLpciu6zI5wwZMbafsI7MOOeNjiDLxsk0SP1sMU4/9NOlsi/lcNuWyKRMm4TG2xMilHYnb
GXn2P6nPWchzqJT7Se2QMNsy650JhqmbTZn96Gq7Nl99wbQJ/MPQWnGczzbRhXCaI/B8A3djXJ6q
q6+BVnx4rmbXTvz+a/gr7LI1mEwvrnG5I0o07pRCV1ysoKwtsZbLCxBcDmaYiWAST5GZx/IswHRZ
dvK0cdjsnxWKIdWW8XzELAvsk6nONpjPZVMumzJXmrFNjFzaMrE7o8z1SYKdiSzhmTHKJDbSFuNk
op+kPjEyyTt1DNB+dmdEoK4u7Eud0dbonVMpfFFhaxq/3IdnG/nNLS3QjB8f2m1/V3Y0WpdxqfOb
P3PHEB/xQZaUlm4qrTCmEjSZbMdBITaP/A5J7+yKgReLSJ5+jENCmscbYrtch0VS/uRK+MkdKtmM
IQ195nfOuL7G2jHiouRtNAYKsc3sPb6N8l06Z6uH5Mt8JrKOXlI3XDOkYFPKwraLmU3G2f+U2a62
nY2/+3WSRqAJX+OkEn2aAi+IpwoLU9CWTkFRqffWIgnGg4n+QpbkODh8dIHFMBnWCsfSnSyczwi0
5R0kQcckERZ3ILyL1w7BtzExHWXGUGxTRo25PkM6JHjhPmDMcSgI4fMi+cBtqCUqesZ1vLlyXj3Y
7+j28HA8s36ap88SxPfsMXXPbWmylNZ1gesvOV2W94WQnfMRxQTv94q7W3j/88uHlbx289sNk6c2
JZtaOqlOOJrJMf3hMsnpOmubkq55djrjZ9LOjG3qMF1i7lq+FKqeuBPS1ZuZrLZS16bnE3YKLCd1
Cw/qD30uvR26nzjGppKYRu+SUu+Vsmiob2c49JaWVmjB5S3qjeqFhfTuqZaWZmioz/zUhStE2LJS
jq2IjTIv+GZZsJxsO54Rte1uhAL1uhOne+IM2IavQClw3vjHOw2pKET8Q1tOks80b8udXWogVwGR
FPM9jbgcxceLC+vTVtpgumsoDjaGz9iMGyNuYfv9tgh0iMT1z96/DpkXynLCoL7B5Y7Vv4PxD3SD
5HHqmN8iMImyXE8dN+VlclcTWUgkFIiX1uJ9nWISlpLGKwzDRq9964/w2ayroKIwH4pLg48x0Hhg
0yMfvbHC85hlJa9p11ZlAyY/3KGJg954u2PHDs+YyBGPE32KO40TB421+fh4Rv6Uyd+HHvg1uwJk
UCIn5Y8VzS1XhulclrqcZxlzy3xqV9aXMh4fHz5cvQ62P/YkNK/foGTbcear/Z/noP73S6ENJxSZ
uJvwlnhZ9+cM9gZqWP5Jfygv6+L1Y92BNM+TCcrLmnhyEhOpjg3i+2VMX8wy+yw7ppSRdijvJbbp
bZkn5VTepydbQ+Kxdtdudb1125mWw+pu0rm+OvZe/KPwqM0oeViawhimrlnOvt2kTd12jM31oLLM
O54R1fkRX/9INvsdTGln8MffX7jk9zUIJ2MV1s+DWlQ/tmDjaprE3vrYdCgtyINi0qO7jVqxX4kf
0fjHdC7HbfPwdlf6leAZQhk+cPfpL+8K+Ef+2n427+nDd/T9IjMRjXicSvGxDHrVFD6sgS+PbYP8
Hj0q4PprJuD3NPSkwYKZbilwSQLs4UY3honVWo/XXV54GT594CHY/X9/g9r/fR4+e3AeNK3fiIGk
QUgORJ4VNyfZ0aYdFVbgrYsUmpGNxR2JhM26aFooTIh8IqetoDb7UjDMbyljy9v2p1BbycNoM9Wp
tLD62+pio7FzNp6kyTzp2OLHWMn43gAh+5vEsOVNP7StqP5l4QmS17RezmY3N7Tc2EgarzA5GUPK
86952ydQjOv+Nj2mtTkHlxwPpmeyLcL4ky1K7AtvGTduW1ZWBkcffTQcgJ+doOUo+lGeaMTjRJcy
ClP4xb6CFF7SwIvi6zdshEMH9IeBhw1wjZPznMIcIRnmSXnSc8sUTCyTnEtTwJ6uT17xPH2pV3rk
YOh58QXw2c/nwbYZs6BtRw0UHfUFqPi3f4U8Y7Yk70WfdlCdDTG86vl5qiSZMm8RdUgyFixliw3H
gHksy1uTb5apVnKgkXYlnfAkj/HNrU2GfWPbrCNlWUbyKC/pUt7EYj29TRZjv05uStJHRuQ6SJ85
zzyW5a3JN8skx7p61/L6P9MllkljHm8J35ThMtsmWc4zj2gyb+NLbI9PmoSnt/xXFV2am2E2bnkv
tPFYLHaHZMGcbGX9CZDrmBNwBKEzAXXGYAGk0VDH12OWXnoLlJ2pv3uT/uwjqJ01EVo3rIG8bt2g
+9SnofDwo6H6O0PQUQL39AiHzlRsietk1tUmS5PDkUce6bJYhzGIQZcvCgqLoKy0DFqL8N1TQwYf
Ac3NzdCnb29XMWcZ6mXmaGaAk3N0Kxh9V3vLli34lT79DqyioiI4+OCDYeDAgeprUwW4xlbxjbGw
67kXof6/fwdtFeVw2JRroeSYo/yIGFgRWz+vU0pkzb+0wYHX5oLeyAZhl2w0P04wlCafsXibIPy+
nSYMz+Yb2/i8b2Xd/PXPZbt5WHp38MqB+MXsLywf7jdL2LYRdm3iiiZ0KMvjFG8DekJe8UIFA5p6
z81EXkP4241pNCFYTHQCidvC9UPYjeKVXHIzlI7+nutRQa9DoWLyI7Dz+lFQdslUSB02FNIfrdIx
F5hKwSy7KLnP0KczivBDTGUl9MVPvHvqpltuV9HdvHlr7q0lGL537doFf/rTn2D9+vWwfft2XDPD
h0icHaeiogIOO+wwGDlyJAw44ECo+9MyaF63AcpOPwVaa3ZB3f++AIWDDofiIYOcERWPwAybKrYc
YLM/uzVmAZcQkpEAWkcOAtxBaMt10C0u9chVXWb5EGO+AZ1lWJfKpr7kET9q/JGyjOP3mxD25eSd
tdnrT+27B9otaNbXCB1rtxhwnyWvED/46n3BjReGjSIXr+fZ8HJK0ytG5Mz+KsvsEatT3IjPbS3j
yDKZbKUtqUdH/234Y3w3Bk5XUmUnXzbG+LImRk1NHLf9GldRTsIJ433YdddF6tkIqUf2qBx2piH9
yUU+3ZLGC+Et0I6XNehgPjX1lh+qQE76wVS1pcrqAEcPOlHOcMBYxmxA6lJEq8NnQ5YtWwavvvqq
Oqs4/vjj1VkFra3RZLJu3Tp45513oAEdHtO7H7T/4glIHdIXDpp8JaQ3fATb7v0Z5B3QAw6+6XrI
xwcTTbtkP033GOObfFPYUKo7us6k8TOyACWxH+Z2Wpgr49tSR/TiZLMvxeP4Upbyprzu9MntmXiy
LDu9aUfKheUzrTfvrGF4XU+njqDbNq7+cXzTd5KX8dHt5g0kZJcndJLLJHW83Tw/4uql68EOqr3H
cZX3CeZxDbyY6nqZfJbjLeNwOYdbx3RH45XEI18cya6otnsQyzTeophPTxnSbVM89GQ1YdRMvxBg
t/P2caFHooTrYitd708Q1+Nlk0sV0Vf7AFeB6qGlLa2/Ef7w3Hn4wkI69fASd2qPEp+TDeSTtuwZ
rXhG8e6778Jf/vIXtaZGHzGnK/al+OJEqvTu3bvVBRmSeeOtt6DH5io4efhx0Gvc2VB24vHQdtwx
0Lp9J7TjxRkjnsJ0Fcw552JY0u8i+K/5E+BAl1MN8yrHw1MwEZ6Z/y3nu9ku08nUwUOjx0HTzN/C
xMLfwLmTfw8zn3kGhuuPbCsf61Y8BP82eSE2niVVXASLFn5PYdviQjRbqlsxD20BLHzhcvX9cZYh
ec1bDD/5neeH5GfaWWx+EV6Yb2xLb8n/YM3DdUlW1tks+9G7ohRXfxs/vH46btwGvP/Y5Jmn62jG
0SwHI2Hzi6RstoLadkq4LreTbDuZt+ApdoyMo0ax8O8KyfQsVv0kdhuphO+PuV8025KtHdTRP901
hf+4LzA+x9jOYyk80N34PtTccSG0480/LgaFheokE92JhcnFxYq68prVgb9srB3om0tkPI2XMdrb
8DUiE6+4DgfqCuiJyz+U2AFViPljk7XRGEby6DrKSy+9hBdZWmDUqFEwePBgFlNbuk+Yfj179oQN
GzbAip07YcS3vwOlxxytfMzDhxF7VH4LLzq1Qn4Rvf6EKylh+sDVc6+BP1z5IPxk0alwz7l4QQnT
mkX3w1NbAKY+eT4O6qJ3SVUohVFTp0D68G5QkvoqTJl0DAwu9zo0dcRuQ74Nv3z8G1BY2g5/feQ6
mPnGV2HO3G9DBdYJCnv6JiNZd2kmQKc74CrwNBANeNa0Rslhp6Ifw+CIbnSaLVF03sQyy0GN6PY2
9ePKJr4p7+dbKuAX6JJStI/h8QnTC6NTZcJ4Jt0s2wIRJWPy4somvilv8qPLSdrV21dt/djEN/2R
ZZknPbOssez7i2knqmzHDdqjQZWXjYJ7sGeBeDbM5g3vQc3t46G9Tk8YjKFkvbApXXrGTmLwhME0
t+yZzSinJ3S8xRcvgtOjfbsa8Fm+ZnxWo7SsO5TilfoW/FZ4VyaaNLZu3Qq9evWCAQMG2E2j1716
HQRHDDoCduFpWjNOFG3i1oR8fKiPLpCbhxGy25YMGQf3XTQYlv/8RnilGs3UvAI3Prgchk2cAyfX
/h6umLQI3McaG1fB9MrpsAqXrQAaYe0bL8LGHQ2Q3rEO/vD827BD0YWrJT3Qd3w6s9cAOLQ/3Uhw
EBzap4+qz4A+KXhjwb0wbvSZMBp/lbc8BqtqvFavemcRTBo3Gnn4q7wFlq4RX06s3QS/mzdd80ZX
wrxXNimjph/VKxbDLZWMMQkWvVMlnMs26/mYLUK8XlfYiPfiH1Oio7HvTH2553Zd69Dgavtl5YF4
DiPuuQsTvwXPMOofux3ad+12n+XIBENOFjxhKBtJZmbTGXWupIkpnDToVSJNzU04T+CkkUoV4rtE
ivAe3Y49pxGwmZBAb1/cjRMCV9inhn2osbEBl/Ua1PkAnR7h3I4/6rj48/Vfmrlp5icRL0/l4d+7
Dc6GXTDtrp/CrDumQW3FeXDbeLwzoWE7rF25HRU4pWHNlnehIU3ldqh64034qKEV5T6GlStfg+2K
zrLmltYeHb9wu2bBzTD1kedhxDXTYNbMKdBr+VNw3WUPAc1b6U1L4eIpD0L1iGtgzqNz4JohH8DM
K6fACjUp0Svql8Ejbx4MM+bMgUlnAzw17X5YgzzpR7pqKYyfPBs+GHIpzJwzEy4dshEenHIxLN0U
6aTptFP2/A4R2E/eKyPgtFtnrL1Y60v2aAfLZco1Xua+0dhj+2WOhBq0NEVnGwl+Ep8mjLpH8dUg
Nz3m6tKZBP8Ij/PqDAPL4vjZhZLjKNfJZWaacZqmrr4W6nGMppcWlpQU47Ma6qtM+OU+fDy8KxPN
hPTk4Y4dO2HZK8ugAWcyPTtSx9SpDZee3n77bVizZrXikTw6rOcLFPMkWYNqST+T0x+uwmUqWLkE
lqysgClzvg+9SIWWggI7gXPRglhu0t8aST6t1sBLT78H/S6aDTeP+wocO/xMuP/R/wdQ+1v4w6p6
WP3ibxF5NNx/8zgYOnAojLtjLlxz0UhIuW+mr4AZD1wNI4YOhXMmTsbVqmrYpeYCz4/VSzXG3Dsq
YfjQ4VCJGKMRdf5zeItepyczvpkadHpjpmr7rDzFE380+KsJwClH1pdkdNI5r8z04DaJTFDLo+Si
3Xgf5a2Hnrsc1bOjdc3SGx7MY8448sq8a8g0YdTOmgQ9cDUiH1d+Ys8uXGx7e3R4snCrrtuoppbe
hN6CX3ctgEI6waAxkyaMwsKunTTIeO/evdUF79dfe03dSeX66mToZVp03aO6uhpf216Esxx+zxx5
0d3Bzi0ZciZM7JcHFWffDGMOVbOFaS6kbMfzhC0eNW6DFbUAJ395kCuW6jsY6KpNM76GHprx9PPs
MdDH5faBcRMqYah63QudTZ0JR/HchWeCnHXFKdOMZzanjPRhjMRZo86deHzSOSzExcM0lam8qf8P
UMYQqfkCq6qilWHI7ENHWNzCpMkoG+ZtGEZn0XNpN6yeneW7g0sDOn26IuJHE0bPexYohZYNeNF7
+gSomDRbTxhEjdD18chWFyQ6s6FvadCkUYAvuM1vwSP8Rlz+6dov96EL6MAhh/THKrfjqc9u9bZF
tbQkjvxp0qipqVE8urYhH20PjZXs+66QJtJwXI7v2VJdk/6oo/cm1Q4kmv5sI+D1cSNFdT6F5Mq7
B4olFXA4Uj/euBP/OjJN1fCpkmzXZl9+z7uWkt4A8265F96o4qWlYvrcSUTCOxn+f3vXHmxXVd6/
e+953HvuKyFPQCAZQ5vykMlYQonaVmIrjsxUnBFm6gOrtXTqMI2FKhYUHEWpNp3YaCc+4gz+IVXa
0umkLXEUBFMdwIpI0QDBoJFCkhtyX+fec8599fdb63x7r73O3vvsc+69IQl3J+futb71vda3vvWt
vffaey2Wfv+nEs6EjMtTDxOoc1NR3ViSfKTV0aVqhadLd6qkX6b6eeZP14Kl/DlEJunkWza3K9FN
t8zoJCGYjy3mVwX7WAqtg4Ce9Ou78XOSX3eBcMAYvv1PZPDju02ekqtP/jCRrpHfiaknx4Ycbiq4
cKG506hhYmN0GLcfGE1O1MHgmsejpvPWnSfnnXeevG7L64Qf8vEYw7cbHCg418E7oMsuu0zWr18v
69atk55Ss33MW3B42DvXw2v4f5X7njgslZEDctcndyBfkqTHUBqOg4HAdNy4hlsjW97eL4/u+Kjs
+flhGT92QHbfhrkUeYNsxe3EuZt+HxW9S77w7Z9LZXpcHr57h9z96EEpDWa7A8JnNrJ+yx8Y3Xd8
82EZGR+RH9+7Xe7G3c3b38D7GR5xetmS+L/E118chmvbON4sd3HIw8/H8T1ZYNQ1rl4ni35xemh7
LbTeC80vTvc42MslN06XNmG8S2AoTfj1/fVnpGfzlWbAOP5X10ju1RcYQbPlUSl/95sy8rEPJNI2
8KSsE3AwDvMin1MZjNs5buU3NvqSjI3z2ciJ6Dg2kHA3qIsvukhWrVxp5jZewhK9L7zwIuYwfmTM
sGXLFvMW0tatW83yIn14U6qIrxHjj7qzNVG/L1yDy7Dp3vBW2faGu2XHh94lXwHkzEsvFnkWk+6w
CX9cqbKGnz0wmOALwSBbD4h24gnyCyWZqz9HIs7vXL9LPnD0JtlxwzuFQ1FHx8Vy6+6bZH0eha99
r3z6vc/L33z2BvnOZ8m9X667fadcjC8uzZtcGD+NDiwCM9WHWTOoYWzp+613y85tQ3LDjlvk+1Qe
x5s+uFPefbF5xmUB3l/y0cOdMCMsqcyFE8/eDTLFQ/nR/nEdPg5mCBflT6Ouofy0MlVGcVzbKExx
eHbLXTjTPn4arqFlm0BN2tVpnnqR2tdkI3/muOKpV+zKcvUI7+BDe0SYLWUWzAK0Ne82ko7erddi
pe6fyfEPvcO8Vlt98HsyO8YnEnhG8OOfJJHFwqN9MRZlQYAI1ZjDgL/xhAGk4/zf+O25ickxfKex
Up74yfcbhJTLZTOnYPeYJVmyQRqIGwCho5NLwM3UPsh5VITbw+8khKYZjhXkK729eKU41DvkZ7lG
/8bJIAY7pNsRXaqkMtUtjafLR9NpchSnnbPPNynIkLeWNdKY0rp4teV8fKLOap4nX09ll9Q2LE+u
o61PGk/lHz2H/u3CVY4L07TKUAsGFgUgyW+U1j+7cpQvcdQPkfJJnDwls1zPTlHm5HxoMwt5RSBG
4+7CVjkaF5vz3nz5W/B4Co/McZcxMLgMT2gwKVNI+DiOih85csQ8OuJHdnw9N93xkhTQrhB2hMA9
Q49OILa0cR1IeSih5nmuVavmMdeRI4fNhLsdOBSzfgbrwM1B5MrQDuh2PqVOK1Oc8KxasfPagUfp
Q5z4lOKpDjwrLJ7iREBZHz1s3VQ/hepZ66t59+zWI47eLXfpmqWVLo2nW+amk3grz6Ryhav/KL7y
5llhiqtn9Y6wh2hJ9Kz0yjNaanMqpwEncPIgkXABFOrZwKMuUPVgNg6Hd0DzH3zqwl6hp8a4m+2x
dRZz8fs4Pv5nXOeLSLFx0WNUrVbs/uC44zAT4fwzeMYKZOz6Ii4+31oaGBiQlfVHSG0PGPQj/nBw
jKDj1bMWmPrXDVJRRJ8H82YMwh8urEW9+ViL9bAHMIjEUz1puFuioGNrx4jrFHVGDSfSKF1YGNVd
+fGs6RB3cVPx8miMpKOZjmm0STxDuOqj57Ck/ZRpxhbJ49styoQ6ur9oaXKuuT5pNoz6TrKU5iWU
Qn/PcjRrDy3XczLPhdM/WcbpWdIYdxeunvFxMZ3/DBYsrFQnsYRfj/T19ksnR55ufGnNAv/gIykO
Gu0fzu164ENMZPTguuA0h2fHDH/kHQgyHZ0T7HaS3+piOpBboRDdQDXwu51CYS5ZNN1afVxaynF/
bpmmm8tXzOZnl1eaXdPKrBQ1nJ7txUCUf9QuLHPLXW3Tyly8pLTla3Vx2y4JfyHgzdqtXRlxg43K
Up5JdtTyVs7NbJ8mq5E29IdWdFjCDS0w/7gb8opL0ZdsXMw2k45eay46+vCYvxdPpnL92Jdiegqf
h8cMGhTI16zaO/wBQ53JgWdiHA08LontXMrXLQnTRax+y4NB0GDijwbEJHo36KR1mFBKug4+j5B/
ct1C3tQ3G55Lk5Ruxou6NsNJ4v1yw329fbu3qp9P7/J30+Tr5y2sucR2WtbXy5USpwfL0z3U5RCf
dv0iSUY8ZVYoLZFFy6x4WeWenHjtx91s9dG4aLGb23QWq9tO42PrGjZk6lyzdi3WFKnhmVW2USeT
SghyGqQbArPTS2xZE44OvouZiRYEHdyrUI+6T/LUoFcdx+0QaZ1TWWY5k6fLN6ThlXeYa0wlVL4R
MRUSLzuV5JQrdOvIdluItktuN/qPbTv3rEZzdVFY4xltm9i8jU6hdUqqlw/385nicaOSsZAG3rFY
LQKNLRIN0iKzJfRmFoj6aKO/ufQ5vG5rnBVvhXXhVapctTqFj+vKLs780gyQ4GDUiImIrbmF5eUq
1MgykOaiRdNAidBZ5aI4JhfVzjWs21FcuM+Ecjhgxh3xdI0DB2UR1/IJmakOyidrXnVRfOaVB88u
XHH1zDLFVZibd2ldOHHjaJWHf/Zp/fJW8i6vNP2y8nT5RWm0s9mzW1+XRnVQWJCPMnNybHPl7YC9
ZJqveagmq/6k8hVH9dJ8K+fWaNWX/bo5MaMV4a9QXG4bcdddd8njjz9uLHDJJZfIddddl+3j5zZs
xrmMWXwEPoevCxGtpPPFF56XWqU6r7Wn9u/ZKTffvF1+cNR+IEhnjkZp1VSdRvO+85Tlvu23yZ4D
WGZDJuS7O2+TLz10yLAiT8NXSZueKasuzxeT0CFtp0pm7Hc2YvqwOB4+ThxdslRbEsejGY0t923e
nF/7srJp5GKdCFlxMuJgrl5Mx+HEwXw6N5/ssw1O6ZJlTC8Ej6io5PpF/SgZL8ovPqd9M8rT4mpZ
POUSVOSee+4JBgzag4MHYYt1FLCEUxHLPtVwgzGBG4xcGV9gd2IjI44hbR0zz8l/7HlS+HnKv9//
M9ly7UUpbHhVHecoIcnIoSNYfhePyrAw4Sg2Xnr+nCyLKZEn9ddzyC9MNSuPDxIhvU016yxJ5Ulw
n7/m0/D9svR8451MnIw0HmllyotnHy8LTK9UlVbzLt8saaVPwm23vBmdLy8N3y8L8nql4Y0wQbkv
xMm7OG6aKNF88h1lFM8yb4RF/UjbSfE076iWMYk+mx4SPD5tximPy6mVVQPZuj/11FMN6vuw7du3
G5wbb7yxAbcdQGdXHnPfM9i9ryKdc5jcmEOQnp7OEpwbxR3/8f3yDJbN27xpjQw/8G15runUSEyj
Q74ly0n4zXevXH3nLvlEfeMkV/JMjYOKC8majpGdlXQJz7FAW8Z36BuTDDrtB55GfqcGBHZkvaGs
tahrVzc939ooLz3Pl19In73d6rJxMmOko4qTBGP20aV+GlpYU6FN4vpJHEwp53ue4R4a+CIcy9vK
NGK1+WpkBhswRSaMM0spy3/veUTk/PfIO6/JyyOP7Zb7f3pc3rdpueHw3H07ZdczF8gnbtgq5h2m
6nOy8yNfkvO3fUyuXIc1PaqH5N4vf1X2Pmk3D9p01dWm99hFg/mo6pPyzCV/LjdsXQd+M3LgoX+W
r37jAXNXIxio3vz+P5WrLz0HZaFBtfsZBZb+eBZwu6drMw8tyCq+jxvN69VmQNZCQmnp9Jpugfwk
RKXNovaJVxJ49n98cSYeCaRmCErXYb62VnoNVppP0siFG80c9Zyki7aUDiwQtdDll18ue/bsCUqZ
IIyH3mH8+te/juTnc8eBdWOlgMdTVb5hi3mNTsHbRV14PJXDr+Xj6OOyB/F+8xUXSXH5b8obl4k8
8l8Pi96zTE8+L8PPDgV5wd3M85VhGanwm5BRufe2OzBgVOVt198kN297j4zv+Td5DCt+5+s2mjwy
LM8O2e3yDj30j/J3GDCKm98h227aJm/bJLJ39x3ytUePZlA7avR0AnZ6/Smm5nk+RQ9zJY+aBVUI
EjEV0vr6RUlwH6/1fCtBp3XuC0GRZi+Xf1Zfy4rn8mY6axsonq+3wn2+7eXZbi21HavtVz2A+QXt
6XS6U11xxRXYojtcvJVpwhbrmMZeGpy+4DqFMzUMGrxS6MCaIl0YSVo99u/bC5I1cumreW/QK5dc
dq7Ir+6T/wniOB2Uy3zXHdUdl44/JQ9iImTz9R+RKzdtkHUbt8iNn3x3XQU4j/GfOek2iXH50X8+
iTuad8jH37dVNm7YKFde/2G5CuIe+Zd9Er77Fed0cbC6mMgprjPZRyYMtNmCbYThSZKp18HRpnld
aDO1m54dBqY93fwrIR1nh3nWexFYWo3IWH/z1HFRyV0dF80Yi1qDl4M5t4jQOwvKZ1q3jeAdBX/c
Qps/zc9Hzy7s6sqHqFxkdgZ3GrmOTgwYuMuYmW78Ijxd0Ivy4F77WOmLH/5gBHXvvmdly9UbnEAb
FttP7UTKh3+BXbiXyZYL7KMsg7HqHLnQJBjA3WNCsMGfLNt0trPPRK9c9Jo1suc7xCP+fJzOk1fP
ulBvjtJV7iROc8CIV49wY7HgxYQ4+8XAyC8GHC9lCZrFAqFvNTNsQmOmCiFPn66ZnFSGbRQ2k3+i
9WmjCicRCV+5ffrppwONmCZMB46gYIESnL6Ynclzb3A8msJ3GtwfnAGk1benRp94UB6DUm98/81y
xTosQ4K56a6uiuz7yp2yd+935EUMGqYzdM9h4qTuuBPYK6NekVwvl/Aelh89PSobL+ZSJVBi7LA8
i9Nqg+M6UlGWY9nw4WF3P+8Z+dVBDlr4MNHg+45pgBn+kE5lNQZZLcnA6CRDaaxLsoJ+LdWWPlxN
FQNPZr5UEmsBtTEKjQtmsWkWHFeY+rZL58h1URclDVkqLlAhSCyKxNOd6Q+xy+m3vvUtvMWE5/j1
g/MXt9xyi1xzzTXBHch85jCUb3DGADGLYF7EHuFcIr3Ttik+4GqpLavy6LcfAM/Xyx9euk5WrVor
a/Fl+apV62TrW14P+GPy4BMjWE4XG0MM/0T27X9Rjh76qXzpE7txd2GP4jmXyRsxEOz74hfkoQOH
5fjQfvnaHSj39MDO4SAYlE1vwrOox74uO/c8Ki8ePSQ/uHeHfANPrC58+xaJXx2LjDxmddmhJxPg
4KiD1/GckihJwOdkTTQfMMyAHqlgWBdzd2JswT+eUUK0pdR8LGDMWp8PCG815sPRo9V207NX3HKW
fPSXkVhFB34WJDIyWEJTC/BO4lOf+pT5qM8dMLScMH7wRxziLuRh9tCoN30nNmLKcTemliayqE31
oDz0DKcYfk+ch0tGbNwJwgAADgtJREFUz4HXvB6PmPbJA9/7X7n2z/5YNu+7U+7Zcbvcg9I1558n
8swvpWA+Sx+Qa2/bJsN/i13rtt8ud6O8eM6Fcu4wRgJzWI8bLNiJkHVX/aW8Z3iXfH3Pbnmy/uLA
hW++Xv7id/n2FA91SPVUwphWOPNpBwKtX0zSBqCPdLLlMw4YEbWjdorGMN9+fj7CaCmTagF1Jtiw
LTNG2ylVlBGg8vQMilZYBAIc+gDGhM/Mzdv+FPWlCPFSpgUL3H///aJvRKWREYe4V111VRpai2WY
/EbM7sSchhlALnnt1rlZfKsxXavIk0/8IMLs4MGDsn79+gisnQzXh5dct/QWOQB4vQWXtTWUT+Eh
Vm8JMx7qnx5aIHemKuXytOSw4mKRS6JkOA4e/EWTekCo/W+4GdH8k6hLknIZlElFUYGK1IqcaB2U
g3+2FwghblBXv118wqX8AljADuhBG7Rsc/pHKz5BlaM+xbvI8CJRy5rxVDw1geIT7qbdcq2rC9P0
0jnNAnFxl3cQWQYN8uUE+K233pomwpTFyYkj2rzlSin22H2XcoU87jTQ7uZda/NMIo5k/rBwow91
sCjPIgYAfXdL3TMeE3RdRekd0On0KJ/knHKNw6iXUSCSRq4K13OELBYYwYh21Cz4JE/T0WMfZJUG
MpDUXFDsJTRYuE1NmqwaeuyWsm1YIHrl7TRatKDO2W+d+bdUrBjjOe3yrntd/eQ6U1RWDEIb9js9
SPx2bV6rrAMGObWC21wy4gqeRpm3bOtrv2LXa3zoh5kNvk4VdzDQ6Ac8ceULAaNzuYGsLZ5x7QCY
u18v66GB08ogUXiYbhPXdxQtriwkR0oRI8AMmWZ0frkqome0XxMpWu/4tlQ+TZgsFS+ABWhrexXu
MkMvQ9aWWTjT820X3ytcfn6Zq42fVjqlUV3reMgaiEFTXJZpWul8vkl5j38S2ikJz2YLP+7u2rVr
QWur8SATUzQj42gHJsI78V0flp3CO7gIpkmv3E5NTWXi2zaS+lUmBi0go23YPBWszsgjOVg6PE2S
fxwYiWNABEePujNk8wmHNIlAdXD4xqI2BiCHuXmDTR0kzgYqxaVZSi+yBertmGz75JLsmvnOksST
8KQyX5qLZ/nzYo8pe1fhlvu0SXlSW14hRjt8QurTIbXYcVfjYjZb8aYCbTyDT8P50i2Xu+XB3aL8
g5Me3E/2RB/R29ok6XQs61zmLsXzM3Xk0dFRM3mTxCWEh/wanDji176Dh4XagaJ9wMcPJSantDKW
VvmanBHHgUJ/US60HQcJ/dFGiutimtoGf9ySpfTiWCD0A6aMjwftpBIVxzQygJpnuZv28TWfdFZ/
iiuP40u8JHjIw/Q7ZE1dQnBMyjgaMWPKXkkg16ZuOmqDExF3s8dFtu8s1pzCOAGV8/kurh6CD/uw
rMesGUWiyq9YsUKOHrWfd3PbV+4vG3e1GqVqJVc3XLL9IE+dkg7nIjJtndB3RQbMCpZ754BXqUzi
VeBVRqlG51YeLgdXhhWpEPMdnEFViGFr/wDEIlPisnNQsiWVGJzs/wiZ4R+B2Iytm9KGCH57JeGF
FEupxbFA2DZ65xfKCcsszG1lpv1ypUyC1+mVTei4SuidA0QHnsTbokQHjDjcOBhp42Q5Yk/rJG3S
vP6LFXfpd9WqjYt8RVfjYjOTF0t56e4uSamnH59RFDARDoparYp5jcZG1glsbnQ+Pj7ejHeb5daI
6oRkYjSpq2MHDdVNDZ5NVBdeE6NhtB7xVOTp8a+LSZbm4ZNxHRR8YB0IU9wA4CXiytMfObkMwkHA
3nloGeGuTQkPcRVr6bzQFvAH6YXhr56o52SuwYAEVGJb74rzsWQezUpMnyRSwDaU1Iw2Wq71CRhF
ixc4tzht066SWvdG+r6+PnNxvlhxl3cyzeNiqBd3ds3lpyWPN6fyXRg0uHPf5OSE9Pb1hlhOigE3
Peg6yC0nQ8O5AS4MblpOp9K0TTo567ue37n8qJblyRQpPeQU3qQIjoDMlR6U2kSAEyQ8hOZZX/c4
CsO9Xqm4zuDzsNq0r1OcDkuwk9gCaOrk1k7x34YqRXHpV4ZvhHkk08AhHlDny1PkSqsdXvESTmWo
xt3gIuBlrEx1vCydsx1SKZakMIhXbmu1CSkUu6V/AF9vxxyLrjScxvhN3VfC4E5lCGx0IoPv6Bql
AT8guDDDoZGNx59c44cUU4A/Lk+FBWdfKVPgCo1DsDIjdfSVDwREE7Zd7B1JszZK1ruZflGZS7mT
3wLxvuC2c1odUvDgqsaDgRL1pxSaBlH1PqBuz3I7pYpEK3waGJ+2gPj2PHHV5QVpB+5MuGPfseND
+NyuG1/UYZQvlXpl+bKV8tY/epdUUDiJz9CncEtSw2+amzRhIqSGZ2E1fADIV694m3LW2jWyCnMe
hw8fll8eOoS1SRisO4RzJFwEcZaLsMM5Vq0+W1asWI2yWRkfG5XjENyDD0XWrj1TisUe6RsYxJ1M
n/BtgfExOwcxVZvGBuYdRnYFz97ymEsp9ZTMhDbTRSqOR0+ch6lA1xrekJqFAl34erxQ6EY5bqEK
RalilyneRVF3fsDIuubzVrdJzHWUy+Mwxrj09g9Kf9+AuaPKg64Lr5blTD2wqiM2IOEa8hXwqlTt
ei+dfPUMryjzR775fB71xs5WeMw3NVXFm2izMoXlhPn8sIaFIPtQP/aToWNDpk60d3ehx9SBsrr4
HnT9a8u+/n6BqbApVs14Buubw3aLOeLgXxV1LZdHTb1Wrl5tbEd9uOE7D9qBLzXUpmoyhXkdtuUk
aOyLDnyxEzZA+01PAwftOzMzZ9bKn0Ydjw0dkaGjR2Rg2XK0Dd6qo060BX5cHrkGnbBAMm5Rc9jF
C7SoG83DlS/Z6WmL8gTacHIMsBkji/6Swy1tqX+5fV2PV5UcGPF/FjyZmAWu3X8Y6/aj/Qrwi84c
68vD/s2h3ciL6/rPQM5Lxw5LPleQPC54aHsek2hP2r2vH2v01w/ahY8pGejo0xPlEfjZSwaPPkp4
qdQPOw4Yv4WZuSAb6l+Q0eHjqM8Y2ocfpUJP09bdRqbxASDnwZu+Sv1p68/cEX5UdeDAAVVjUc8b
NmwI+P/9P+yW5YNnmHajnarVmoxPlqW7WDSLzbHCJTz+oF241DWbg803iz/sSxX08Un0CU58sg8s
A6++/j4TI+g3U7UpzBPaPkV7En8GuHNoQ/oTm4v2on3MAXl8VbOEPs9+wnWLuBQF+w51mYEfVumr
oJ2CP7EvTBnfnIKPwT+Aw/btKdmlwA/Xt6em3pRLeXn6CxL4ShkiGYjAHzrQzej3rGe5PCxf+Pyd
gZ3+6ct/h2fzORkaHpfR8Qm0LSZ70X/p88WebhlEXKL9Dg8dgw9MQpdpWXf2CukvdctLo2UZHZs0
9RqfqMgUaCnfLB9OCZCXR6A9Y6AE+2F/bag1PFaWkTHa1+pMm0NTe0BPVBO+1CklxK47Pvd5LZGP
3vJp2AbbccMG/YhT5fKYTCCm0d7sD5TZhV31irgLWH7GSmP7WhW762GNKNqbB+1C32U7dCE2UzfG
pS5Mas+hAzNGTqJNq/hNoY9XIa+YL8rA4DLYrgt9GXJg654+zGmAB/pi3qyO2IPldtlw1S4EhjmY
AAbt7ikYZ5qbm0YejQxjMEDTAdiJOUj09Q/I6tVrZGR0DLgIKTB6vlBCkJmW5RhUzn7VegwS3eis
ZWP4s846F5VfBlgJlegwg1U31oMfHhmWInSgAWZ7GOAx1wJnYiUHGcQQPEEghe6icWA6HvWdRiPM
YgOOAjY/58w+OwQ3QjcdYHYSxgqdtgDeDHA0jgbSbgR0DmI9COQ9SHPCh+8iUzdUzwRVnDDa4raM
HQ9l7Ezmy0jA6JBwV+MYs7BTFYMRB6kJONM0bukKXfh6HYHQNCQbHrbp7Rs0AwkbkvUrgm8RNijo
QAXb1TBAceDrw+PBaTQsByPalAGNzrEWwbIPd4fcSasLOuToIKgr8+xsvEKZ6phCe6B9exDksVIl
Bwp2vhJ+E+gIfIMiX+gydR8dHTF3nHzeyUG5BH3Iw6xJxnZFJyyhDVhbdsQOOCIHvhqC9DQG+akZ
dvoplNm192Ex0NNwsAE6dSFXNE5LetqTC59xWOHgMjOFQR+6wRion/3MswM+yGDPQauG+uNyBLwQ
ZMATJODNgIi5OLRBPt9tbMQLHMotwjbsID04U4Vp6DaN3R5nu2Ar2I8/doQc/IX4HDCKxV7w6jId
t4D2yKMtRo4fg81mjS2Ix/qVejHAwMeMvdn21GeWg2kH5v3G5MwzzwRPe/BFjI0bN2p2Uc779++P
yOxB8KA/s2/WEOjot3n4Hy+W6PMMBn3wdT344RYv9BgMRvOj0oELO15+cDBmEB8cXI6nEKgv+x/8
ixcZDM0V2H4G9mCGAwEsawYK8uKTC/bXGfgIL1zysCf7PI1VRb7Gtgah8QRE/1noio5vdCjC5zsQ
tGjPHvRjcxGKMgblKQyAxSIHvALKObjYnXuoK52N/cl0RMQg+kseAz8v4Ogwnehnbtss70eMQh8A
U2y/gMCJmIDII6Plirz4fxXEE/SzwQF51ZoVkj/zDMSnManANrWxYZmoon/Cn8bKiC+oCf15hrZB
fWnH5QM9cu7qAVmzYsD02ReGRmSwOycr0e8PDw3LC0OjUsHWqfRNxhNuijeAwegsXFyXzlgW0ZOx
jDFiCn2AfaGnm/MdeTtA0v8A4wDNmGQuoBDkeeFbQHuzLzOO2UAGaUiz/c0FOfow++fIyBHTd9jX
O9EvutHnyI9tb30IA6mxNS6OeVEOm/4/xk/3di8LMxUAAAAASUVORK5CYII=
--Apple-Mail=_833A36A7-75F0-443B-8B1A-41AF5906B08C--

--Apple-Mail=_45F43AED-BFD2-4BC4-B22B-14A0D79C77CC--


From nobody Thu Sep 10 14:03:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1674E1A908F for ; Thu, 10 Sep 2015 14:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64MNb60TVfUg for ; Thu, 10 Sep 2015 14:03:44 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3DF1A87AD for ; Thu, 10 Sep 2015 14:03:43 -0700 (PDT)
Received: by pacfv12 with SMTP id fv12so54080354pac.2 for ; Thu, 10 Sep 2015 14:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ktLIns011wWFhCVbaIuGbqtecaDyBDnKq/qvRcb881I=; b=kCOfZ+rYQA/2FuQqGgxh6H3OqZxn63XV0sZpzsCoBBJTUzuJQc6/SAXa8c9R09Gsip wizmnY6KpwOcVynn8+nZOv+KZPGsUdyWpmnOyd/LJ/hx66Ip24pcFc6aVWkH1gCrtEfz JVs7y+/8bZkm+dYQSfsZ0pZsKQ1u15RaxigUPQFStB35/BADfjiEKORyZTsEFrHbZZe/ jP/Bj5dOZOwj3/WnfZXpe/rFhCDdc9iQ8o0k2fPMcrDLtzJjZ17vyVoTtx1ZtmKBoglC dIUOYHdg/iOSKbxzo7y2DQZqkqP2HhtqpOcZ00CP6a8yE9gQDVwwFZxkyC0IzSZsdY07 7erQ==
X-Received: by 10.66.252.131 with SMTP id zs3mr76406399pac.75.1441919023507; Thu, 10 Sep 2015 14:03:43 -0700 (PDT)
Received: from dmp-sjc23-3.cisco.com (dmp-sjc23-3.cisco.com. [128.107.157.235]) by smtp.gmail.com with ESMTPSA id c6sm13779242pat.13.2015.09.10.14.03.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Sep 2015 14:03:42 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A68B0BD-CB21-4190-AA80-41BB31B5117F"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Thu, 10 Sep 2015 14:05:41 -0700
Message-Id: <3F0AD8A8-B1C1-4378-AD47-F9DAC28421A5@gmail.com>
References: <55F141E3.50002@cisco.com> 
To: Rob Shakir 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 21:03:46 -0000

--Apple-Mail=_3A68B0BD-CB21-4190-AA80-41BB31B5117F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Sep 10, 2015, at 7:45 AM, Rob Shakir  wrote:
>=20
> The configuration file/=E2=80=98store=E2=80=99 of a system shows the =
intent of how that system should be configured. We can agree that all =
implementations need to have this.
>=20
> The applied configuration is the value of those configuration elements =
a daemon/software component/programmable memory is actually running, =
which can be compared to the intent. Essentially, this is *dynamic* =
information which is the *state* of the running system. Implementations =
*do* store this. I think the point that you are making here is not that =
it is not supported. The point is that it is dynamically built at query =
time, according to a different schema.
>=20
> This different schema is bad news, programmatically. How did I know =
that the static (IOS-alike configuration):
>=20
> router bgp 65497
>  neighbor 192.0.2.1 remote-as 65500
>=20
> Needs me to run:
> =20
> show bgp ipv4 unicast neighbor 192.0.2.1 | i remote AS
>=20
> and then run a regexp that extracts the following AS number after the =
words =E2=80=98remote AS=E2=80=99. Today - I probably need to write a =
mapping table that tells me that.
>=20
> The requirement is that we can determine, for a particular leaf - what =
the intended value is, AND the value which is applied, PLUS be able to =
=E2=80=9Ceasily=E2=80=9D retrieve the state associated with that =
construct - in a way that is deterministic, and does not require =
per-leaf mapping tables to be maintained like we might have to today.

This makes a whole lot more sense to me from a requirement perspective =
than what has been proposed in draft-openconfig-netmod-opstate.  I am =
not going to comment on what it will require to implement this. We =
agreed with no objections for requirement 2 as Kent put it out, but it =
would help to rephrase it.=20

2. Ability to determine whether the configuration intended for the =
device has been applied.

To determine whether the configuration has been applied, the client =
should be able to query the construct and the values therein, including =
any state associated with the value, and get in return values that =
should allow the *client* to determine whether the configuration has =
been applied.=20

Note, I emphasized client because if the returned value could be a state =
construct instead of a boolean value. In addition, one client=E2=80=99s =
interpretation of the values including state value might be different =
from another client.

Note also, I am trying (very hard) not to propose a solution :-), =
specially as to whether the data is operational data or config false. =
This will allow for the best solution to be proposed.


>=20
> The point about identical values is that *in cases where no such =
retrieval of the actual applied config values is possible* a system can =
simply make all the applied leaves pointers to the intent. This would be =
akin to the =E2=80=98show=E2=80=99 command doing the equivalent of =
=E2=80=98show running-config | i 192.0.2.1.*remote-as=E2=80=99 and =
extracting the remote-as from there AFAICS.
>=20
> Regards,
> r.
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_3A68B0BD-CB21-4190-AA80-41BB31B5117F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Sep 10, 2015, at 7:45 AM, Rob Shakir <rjs@rob.sh> =
wrote:

The configuration =
file/=E2=80=98store=E2=80=99 of a system shows the intent of how that =
system should be configured. We can agree that all implementations need =
to have this.

The applied configuration is =
the value of those configuration elements a daemon/software =
component/programmable memory is actually running, which can be compared =
to the intent. Essentially, this is *dynamic* information which is the =
*state* of the running system. Implementations *do* store this. I think =
the point that you are making here is not that it is not supported. The =
point is that it is dynamically built at query time, according to a =
different schema.

This different schema is =
bad news, programmatically. How did I know that the static (IOS-alike =
configuration):

router bgp 65497
 neighbor 192.0.2.1 remote-as 65500

Needs me to run:
 
show bgp =
ipv4 unicast neighbor 192.0.2.1 | i remote AS

and then run a regexp that extracts the following AS number =
after the words =E2=80=98remote AS=E2=80=99. Today - I probably need to =
write a mapping table that tells me that.

The=
 requirement is that we can determine, for a particular leaf - what the =
intended value is, AND the value which is applied, PLUS be able to =
=E2=80=9Ceasily=E2=80=9D retrieve the state associated with that =
construct - in a way that is deterministic, and does not require =
per-leaf mapping tables to be maintained like we might have to today.

This makes a =
whole lot more sense to me from a requirement perspective than what has =
been proposed in draft-openconfig-netmod-opstate.  I am not going =
to comment on what it will require to implement this. We agreed with no =
objections for requirement 2 as Kent put it out, but it would help to =
rephrase it. 

2. Ability to =
determine whether the configuration intended for the device has been =
applied.

To determine =
whether the configuration has been applied, the client should be able to =
query the construct and the values therein, including any state =
associated with the value, and get in return values that should allow =
the *client* to determine whether the configuration has been =
applied. 

Note, I =
emphasized client because if the returned value could be a state =
construct instead of a boolean value. In addition, one client=E2=80=99s =
interpretation of the values including state value might be different =
from another client.

Note also, I am trying (very hard) not to =
propose a solution :-), specially as to whether the data is operational =
data or config false. This will allow for the best solution to be =
proposed.



The point about identical values is that *in =
cases where no such retrieval of the actual applied config values is =
possible* a system can simply make all the applied leaves pointers to =
the intent. This would be akin to the =E2=80=98show=E2=80=99 command =
doing the equivalent of =E2=80=98show running-config | i =
192.0.2.1.*remote-as=E2=80=99 and extracting the remote-as from there =
AFAICS.

Regards,
r.



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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_3A68B0BD-CB21-4190-AA80-41BB31B5117F--


From nobody Thu Sep 10 16:11:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8FA1A9100 for ; Thu, 10 Sep 2015 16:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bdn4q_DByny for ; Thu, 10 Sep 2015 16:11:55 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 9ADFF1A1B5F for ; Thu, 10 Sep 2015 16:11:55 -0700 (PDT)
Received: by pacfv12 with SMTP id fv12so56749948pac.2 for ; Thu, 10 Sep 2015 16:11:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7Gx9j0oac1/+/aIHg+uxEtAviiy4mFtt95IGt7BEGJ4=; b=X6US/myghVqbdTsS6Mjp2RvgyGAgOI+g5a3uB548h4PvLqIgzJGPWKynwkK1cfTNbn e8Hmpzb+n4g9mXVBQdoAyQASGzoRiSrOZxZk/jZCWNzWp/vwI08Y2p/J0hyDaoDpIT7n +jREuN6MtJ0pe6CJUrZbmwZ6WojIDu7u63NmMMV4CTGSybNCvPZNhOQhj0w9MbuuuYdJ IkpsSlFkHv+9rytX5mHSgYDte2fWy/Inw2jYGk8YRqBDweh+641X9UR6TCaqBk72Yg7U qiU5ebaqx89NCPhVZF2A3o2aaRweFwxBl7wsQVMdOregf93USRoYeXXYxPkHDVgg2KqL P14Q==
X-Received: by 10.68.89.35 with SMTP id bl3mr89530556pbb.69.1441926715177; Thu, 10 Sep 2015 16:11:55 -0700 (PDT)
Received: from ?IPv6:2001:420:302:1330:205f:6849:b753:4a7b? ([2001:420:302:1330:205f:6849:b753:4a7b]) by smtp.gmail.com with ESMTPSA id df1sm4302246pbb.21.2015.09.10.16.11.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Sep 2015 16:11:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_05790037-1F01-4133-9561-FF9C91E63FF3"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mahesh Jethanandani 
In-Reply-To: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com>
Date: Thu, 10 Sep 2015 16:13:53 -0700
Message-Id: <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com>
References: <55F141E3.50002@cisco.com>  <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com>
To: "Carl Moberg (camoberg)" 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Sep 2015 23:11:57 -0000

--Apple-Mail=_05790037-1F01-4133-9561-FF9C91E63FF3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) =
 wrote:
>=20
> Now, think about configuration parameters that have applied =
configuration located in more than one place. Let=E2=80=99s say you =
change the IP address of an interface, it is likely that this =
configuration will be passed around as input to a handful of subsystems =
(e.g. the DHCP server, some routing daemons that may bind to specific IP =
addresses). Is the intended and applied in sync when a specific subset =
of those configurations are updated. What happens if there=E2=80=99s a =
partial failure?

This is a good example. Another example, and somebody on the call today =
started to ask this but got cut off, relates to interfaces on the =
device.

Interfaces already exist on a system. As such they have a configuration =
(default values) that exists on them. They are enabled when =
configuration gets applied on them. They will have applied configuration =
but no intended configuration. Should this be reported?

Yet another example is of a BFD session that gets bootstrapped because =
of a ping. There is no intended configuration, but the session exists =
and a query of configuration in this case would return a valid BFD =
session.

Could we get some clarification (with examples, preferably) on what the =
expectation is from a openconfig opstate perspective?

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_05790037-1F01-4133-9561-FF9C91E63FF3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) <camoberg@cisco.com> =
wrote:

Now, think about configuration parameters that =
have applied configuration located in more than one place. Let=E2=80=99s =
say you change the IP address of an interface, it is likely that this =
configuration will be passed around as input to a handful of subsystems =
(e.g. the DHCP server, some routing daemons that may bind to specific IP =
addresses). Is the intended and applied in sync when a specific subset =
of those configurations are updated. What happens if there=E2=80=99s a =
partial failure?

This =
is a good example. Another example, and somebody on the call today =
started to ask this but got cut off, relates to interfaces on the =
device.

Interfaces already exist on =
a system. As such they have a configuration (default values) that exists =
on them. They are enabled when configuration gets applied on them. They =
will have applied configuration but no intended configuration. Should =
this be reported?

Yet another =
example is of a BFD session that gets bootstrapped because of a ping. =
There is no intended configuration, but the session exists and a query =
of configuration in this case would return a valid BFD =
session.

Could we get some =
clarification (with examples, preferably) on what the expectation is =
from a openconfig opstate perspective?



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_05790037-1F01-4133-9561-FF9C91E63FF3--


From nobody Thu Sep 10 18:19:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11961B390C for ; Thu, 10 Sep 2015 18:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qStQ6qh_FuFg for ; Thu, 10 Sep 2015 18:19:34 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id E02E11B3325 for ; Thu, 10 Sep 2015 18:19:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qdCi+3z1u/XCDnmue0NC3KMMuJl3dDUuuP9rVCY21B+bJ6OsrYf5KVdCDYDhZc7O; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZaCzp-0003vy-6G; Thu, 10 Sep 2015 21:19:21 -0400
Received: from 76.254.55.28 by webmail.earthlink.net with HTTP; Thu, 10 Sep 2015 21:19:20 -0400
Message-ID: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Date: Thu, 10 Sep 2015 18:19:20 -0700 (GMT-07:00)
From: Randy Presuhn 
To: Ladislav Lhotka , netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed1d2c2b65496f299d13093e3fa38ec088350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.52
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 01:19:36 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Sep 10, 2015 2:02 AM
>To: Randy Presuhn , netmod@ietf.org
>Subject: Re: [netmod] Y26 again, sorry
>
>Randy Presuhn  writes:
>
>> Hi -
>>
>>> From: Andy Bierman
>>> Sent: Sep 9, 2015 12:10 PM
>>> To: Ladislav Lhotka
>>> Cc: Robert Wilton , Randy Presuhn , "netmod@ietf.org"
>>> Subject: Re: [netmod] Y26 again, sorry
>> ...
>>> I don't think it really addresses the design pattern very well.
>>> You want to claim that M and Q are both being developed at the
>>> same time,so it's OK that Q adds mandatory nodes to M.  YANG
>>> has no such rule.YANG says a server can implement M and never
>>> implement Q.YANG says a server may implement M and then add Q
>>> in a future release.These conformance mechanisms do not align
>>> with your expectationsof how YANG can/should be used.
>>
>> I agree with Andy that there seems to be a mismatch in expectations.
>
>I wonder if we can explain these differences. Is your and Andy's
>expectation that the configuration schema has to reflect actual hardware
>configuration, perhaps even dynamically adjust to the changes?

I can't speak for Andy, but I would expect that a server's
schema could change dynamically, as a result, for example,
of new hardware or software being introduced into a running
system.  We were doing this in the late 1980's - it's one
of the things that pulled us into the subagent technology space.

>In my view, the supported (and advertised) data model and hardware
>configuration of the device are two different things.

They are different, but there are relationships.  When a new
line card is inserted, I would expect the system to acquire
any necessary schema knowledge in order to manage that new
resource.  Likewise, if non-present hardware is being provisioned,
part of that provisioning process (possibly implicit) is for
the system being provisioned to acquire the necessary schema
knowledge so that it can perform at least a preliminary validation of
the provisioning data.

>> Let's look at a slightly more complex hypothetical case to tease
>> out how folks *want* things to work.  Assume the following have
>> been defined:
>>
>>   - base module M
>>   - augmentation Q
>>   - augmentation R
>>
>> On a server claiming to supporting the modules containing M, Q,
>> and R, respectively, which of the following might one encounter
>> concurrently?
>>
>>      - plain M
>>      - M+Q
>>      - M+R
>>      - M+Q+R
>
>It depends on what you mean by "encounter" but in terms of datastore
>validity the only possible answer IMO is M+Q+R.

By "encounter" I mean if a client asks the server for all of its Ms,
and the server also supports Q and R, are all of the Ms *guaranteed*
to be M+Q+R, or is it possible that some of the Ms might lack Q or
lack R of lack both?  If what netmod gives us is strictly M+Q+R,
how would one model a system inhabited by a mixture of the four
kinds of Ms?

Randy


From nobody Thu Sep 10 18:31:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B0D1A6FF5 for ; Thu, 10 Sep 2015 18:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6BnXy3hEvxd for ; Thu, 10 Sep 2015 18:31:00 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1312E1B3DF8 for ; Thu, 10 Sep 2015 18:31:00 -0700 (PDT)
Received: by padhy16 with SMTP id hy16so58802200pad.1 for ; Thu, 10 Sep 2015 18:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=z+Sc8nXPCunR6Q1FwGvsXK6KG7MhCVd+YNQ0J2WNf4M=; b=r30lIVwjCQcMdkO9oaeM1/Da9hdavnvyZfiOuxhmmPkugoJAEZH1x+SRT7KjAvKpep k1vwn7TiNYejEBL0J7XmZ84VNC1UByUfWXkx5+uat2Bnfv7omYXCXonTlHDCptcShdZT XifSwPPPA+BLEE/U0yBkAWJPoPkICKnAmdbaTMh0+gyZFM6XkzpvXhJRFLvFeQWGv502 tRdicEz9jo5NnBLNa3KJgIpzxSH+dDxzdeX36UYlZkbkjuceNy/TRsE7jWl3rHaGiYXi BOhPP4gBuQNbLGKG4lw/PtgsuRVWBDeSD5+TfGhRbVWDzMwi6YAzGds5thEdfhdBZTAh qJ8A==
X-Received: by 10.68.137.202 with SMTP id qk10mr89478971pbb.30.1441935059772;  Thu, 10 Sep 2015 18:30:59 -0700 (PDT)
Received: from [192.168.1.11] (c-73-189-176-93.hsd1.ca.comcast.net. [73.189.176.93]) by smtp.gmail.com with ESMTPSA id jd12sm14356058pbd.44.2015.09.10.18.30.58 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Sep 2015 18:30:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_384580B5-C8C6-4462-9DFE-E655B407625C"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Sam Aldrin 
In-Reply-To: <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com>
Date: Thu, 10 Sep 2015 18:30:59 -0700
Message-Id: <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com>
References: <55F141E3.50002@cisco.com>  <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com>
To: Mahesh Jethanandani 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 01:31:01 -0000

--Apple-Mail=_384580B5-C8C6-4462-9DFE-E655B407625C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani =
 wrote:
>=20
>=20
>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) =
> wrote:
>>=20
>> Now, think about configuration parameters that have applied =
configuration located in more than one place. Let=E2=80=99s say you =
change the IP address of an interface, it is likely that this =
configuration will be passed around as input to a handful of subsystems =
(e.g. the DHCP server, some routing daemons that may bind to specific IP =
addresses). Is the intended and applied in sync when a specific subset =
of those configurations are updated. What happens if there=E2=80=99s a =
partial failure?
>=20
> This is a good example. Another example, and somebody on the call =
today started to ask this but got cut off, relates to interfaces on the =
device.
>=20
> Interfaces already exist on a system. As such they have a =
configuration (default values) that exists on them. They are enabled =
when configuration gets applied on them. They will have applied =
configuration but no intended configuration. Should this be reported?
>=20
> Yet another example is of a BFD session that gets bootstrapped because =
of a ping. There is no intended configuration, but the session exists =
and a query of configuration in this case would return a valid BFD =
session.
>=20
> Could we get some clarification (with examples, preferably) on what =
the expectation is from a openconfig opstate perspective?

Section 7 of draft-openconfig-netmod-opstate talks about that. =
Specifically, #3 talks about the interface question you raise..
Also, Rob mentioned on the call that, this is no different than BGP =
specific config/state (draft-ietf-idr-bgp-model).

-sam
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_384580B5-C8C6-4462-9DFE-E655B407625C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:


On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) <camoberg@cisco.com> =
wrote:

Now, think about configuration parameters that =
have applied configuration located in more than one place. Let=E2=80=99s =
say you change the IP address of an interface, it is likely that this =
configuration will be passed around as input to a handful of subsystems =
(e.g. the DHCP server, some routing daemons that may bind to specific IP =
addresses). Is the intended and applied in sync when a specific subset =
of those configurations are updated. What happens if there=E2=80=99s a =
partial failure?

This is a good example. Another example, and somebody on the =
call today started to ask this but got cut off, relates to interfaces on =
the device.

Interfaces already exist on a system. As such they have a =
configuration (default values) that exists on them. They are enabled =
when configuration gets applied on them. They will have applied =
configuration but no intended configuration. Should this be =
reported?

Yet =
another example is of a BFD session that gets bootstrapped because of a =
ping. There is no intended configuration, but the session exists and a =
query of configuration in this case would return a valid BFD =
session.

Could =
we get some clarification (with examples, preferably) on what the =
expectation is from a openconfig opstate =
perspective?

Section 7 of draft-openconfig-netmod-opstate talks =
about that. Specifically, #3 talks about the interface question you =
raise..
Also, Rob mentioned on the call that, this is no =
different than BGP specific config/state =
(draft-ietf-idr-bgp-model).

-sam



Mahesh Jethanandani
mjethanandani@gmail.com







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

=

--Apple-Mail=_384580B5-C8C6-4462-9DFE-E655B407625C--


From nobody Thu Sep 10 22:05:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07F61B2D3A for ; Thu, 10 Sep 2015 22:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwloeOlm28tb for ; Thu, 10 Sep 2015 22:05:18 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 A02DC1B2FF5 for ; Thu, 10 Sep 2015 22:05:12 -0700 (PDT)
Received: by ioii196 with SMTP id i196so85939797ioi.3 for ; Thu, 10 Sep 2015 22:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tfo820mPpoYuFImclOkwv9j53buyKIrPw2r0P48bIjs=; b=NsA2Dsvd4vNEuJG7XxwbFiz9Rf2ZX4JAu+KJI392QR2YDYvtFP8/a2GJ0LEUHCv7st 5hhVFLB31A5+s1fcZQzMcrCGIDnZJ1VNulixhaUoawUTKx6wCV8nInRYqeuVe6qeGLEI f485CNw25U/Sdm1BsPuL7uvA7hZw+lVsUeCD4zLIyIQNK2IBqSd6ZzKGu1DvaWYI5UOr XPddwPMX6cN7GT7fGJ2nTGpM8wI0MyHRWlEE9ttgGsIWz/XsGUeZqANgPHQPXodmS7cb IQw6UK6aRVRNIRA4SeT/tH7SIFGaqjlZU5Os0brnQvZH2YKHSvNI2148H0C4T1XsMcRb 8fmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tfo820mPpoYuFImclOkwv9j53buyKIrPw2r0P48bIjs=; b=bGeTBxJEQXDsu3s9YmnGP75Lv9p2Yh/r+MYwRISJT6KCOQvd1E/WoOkd729K24Kv3H xwSHAiGvurdoxzaJ3ziXkp/8QmqvuUhB5zjUgq+DC/oksDIr7TL8W9TQxo6gw79rHckV nD432ZLAWwfm0SRlylz0OF08hDycxa26Xf/PcYBWCD88gNZfXjHTUo4sXctaQEbey2CV znpFDLEbwy5+ycMq0hqXavNPPech5jT57Js1assNhjnYZM7K42OlGaLyOmnjWHVhGRA6 c92A1pmVzeLbaWRYIvRjl+PJRER2s+B9IT8etr4JwiLlqMEgZbprXiF8l2Bj3TOWe0hh Gm3A==
X-Gm-Message-State: ALoCoQmZA1mAipceHvXLqQ8mp8Qgkm2rLbEhhcSebaISojyrZ3XZAscfZHIe6EPymVGFRFFwH4W2
MIME-Version: 1.0
X-Received: by 10.107.47.219 with SMTP id v88mr438428iov.134.1441947911720; Thu, 10 Sep 2015 22:05:11 -0700 (PDT)
Received: by 10.79.32.130 with HTTP; Thu, 10 Sep 2015 22:05:11 -0700 (PDT)
In-Reply-To: <55F141E3.50002@cisco.com>
References: <55F141E3.50002@cisco.com>
Date: Thu, 10 Sep 2015 22:05:11 -0700
Message-ID: 
From: Anees Shaikh 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=001a11c14e921066a7051f71a9b1
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 05:05:21 -0000

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

Benoit, I think Rob and others have already addressed the first issue
raised in the comments from your group.  For the second point, your mail
says that the OpenConfig opstate draft says:

 *   "The proposal does not allow items that are not configured, configured
but not present, or system configured."*

*Please note that this is a general note that would apply to the language
itself. Meaning that YANG will no longer be able to describe situations
like the above for any type of application in any context.*

While the draft does say this, you've unfortunately misunderstood the point
being made in that section (I'll have to accept some responsibility for
writing it this way).  The preface to Section 7 says, "A number of issues
have been raised with the proposed solution ..." and point #3 is just
stating the issue that was raised with regard to our proposal -- if you
read the rest of the explanation in #3, it describes an example of how the
solution can address these situations, using a specific example of
configuring 'all' interfaces , some of which may not be present.
Similarly, if an implementation supports pre-configuration of interfaces,
for example, the intended configuration reflects that preconfiguration,
while the corresponding state would show that it is applied but also that
oper-status = 'NOT PRESENT'

So I would say that your point about the solution limiting expressivity
that is otherwise allowed by the language is based on a misreading of the
section.  Other points in Section 7 also first relate the issue raised,
followed by our response regarding how it can be addressed.

thanks.
-- Anees


On Thu, Sep 10, 2015 at 1:40 AM, Benoit Claise  wrote:

> Dear all,
>
> The YANG coordination team
> 
> has spent some time reading and gathering input on the requirements and
> proposed solutions in draft-openconfig-netmod-opstate. This note is to
> collect some observations that will hopefully contribute to progress in the
> working group.
>
> We believe it is useful to consider that YANG was initially designed to be
> a data modeling language for the NETCONF protocol. IETF is also working on
> RESTCONF which is an HTTP-based protocol to access data defined in YANG,
> using the datastores defined in NETCONF.
>
> YANG is fulfilling its intended role with NETCONF and RESTCONF and has
> gained some significant traction in this capacity. There are some changes
> worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and RESTCONF
> to manipulate data described by YANG. The proposals in the draft is based
> on the assertion that YANG models should be usable for protocols beyond
> RESTCONF and NETCONF. So these are new requirements on YANG from, or in
> preparation for, new protocol bindings.
>
> We have focused on two main aspects of the draft.
>
> FIRSTLY: The proposed split between intended and applied configuration as
> described in sections 4.1 (requirements) and 5.1 (implications)
>
> There are two observations here:
> 1. The implication is that all configurable data nodes ("intended
> configuration") shall be repeated in an operational version ("applied
> configuration") in all models for all applications going forward. This
> would apply independent of if the system is synchronous or asynchronous in
> nature. Synchronous systems would simply hard-wire the applied
> configuration to be the same as intended configuration at all times.
> 2. An informal round of conversations with some vendors as well as some
> tooling vendors show that there are currently no widely known platforms
> that allow for observing the intended and applied state separately. A
> common architecture includes a central configuration data store that is
> being updated by the manageability framework and updates read by the
> subsystems affected by the change (e.g. the BGP service or the interface
> manager). In this case, there is no other source of configuration except
> for the content of the data store.
>
> Please note that this was not an exhaustive collection of data, but should
> give some directional information.
>
> The *implication* we would like to make here is that by making this
> feature mandatory part of the YANG language itself (as opposed to an
> optional capability) we risk introducing a fake perception that the current
> NETCONF server supports a capability it can't support. Indeed, polling the
> applied configuration would always return the intended configuration.
>
> A *question* would be if it would be useful to consider a direction where
> we make an attempt to separate out requirements that are tied to specific
> protocols and solve them in the protocol semantics rather than in the
> language to the extent we can. Without knowing more about the intended
> protocol in the case of this draft, it is hard to make more progress.
>
> A *suggestion* is to ask the draft authors to document the protocol
> bindings in order to qualify the requirements going forward.
>
> SECONDLY: The proposed schema locations for configuration and
> corresponding operational state in sections 4.5 (requirements) and 5.4
> (implications)
>
> The observation to be made here is well captured in the draft itself as
> bullet 3 under section 7:
>
>     "The proposal does not allow items that are not configured, configured
> but not present, or system configured."
>
> Please note that this is a general note that would apply to the language
> itself. Meaning that YANG will no longer be able to describe situations
> like the above for any type of application in any context.
>
> Examples beyond what's already mentioned in the bullet of this could
> include:
> - Removable physical assets (line cards, mezzanine cards) in systems that
> allow pre-provisioning of configuration
> - Physical assets that arrive in the system with readable default state
>
> Independent of the direction we will be taking going forward, the
> implication we make is that it is a pretty significant impact on the
> expressivity of the language itself and how useful it is in terms of
> modeling application data sets that may not align with the requirements.
>
> The question we would ask is if it would be possible to rebalance the
> implication and make it a little more modular and optional in the language.
> We are aware of suggestions to use the extensibility of the language itself
> (e.g. in draft-kwatsen-netmod-opstate) to express relations across data
> sets. Understanding that this suggested approach does not normalize the
> paths according to the wish of the authors, but it can perhaps be a
> balanced approach that impacts the expressivity less.
>
>                         Regards, the YANG coordination team
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Benoit, I think Rob and others have already addressed the =
first issue raised in the comments from your group.=C2=A0 For the second po=
int, your mail says that the OpenConfig opstate draft says:

<=
div>=C2=A0 =C2=A0 "The proposal do=
es not allow items that are not configured, configured but not present, or =
system configured."

Please note that =
this is a general note that would apply to the language itself. Meaning tha=
t YANG will no longer be able to describe situations like the above for any=
 type of application in any context.

While the draft does say this, you've unfortunately misunderstood th=
e point being made in that section (I'll have to accept some responsibi=
lity for writing it this way).=C2=A0 The preface to Section 7 says, "<=
/span>A number of issu=
es have been raised with the proposed solution ..." and point #3 is ju=
st stating the issue that was raised with regard to our proposal -- if you =
read the rest of the explanation in #3, it describes an example of how the =
solution can address these situations, using a specific example of configur=
ing 'all' interfaces , some of which may not be present.=C2=A0 Simi=
larly, if an implementation supports pre-configuration of interfaces, for e=
xample, the intended configuration reflects that preconfiguration, while th=
e corresponding state would show that it is applied but also that oper-stat=
us =3D 'NOT PRESENT'=C2=A0

So I would say that your point about the solu=
tion limiting expressivity that is otherwise allowed by the language is bas=
ed on a misreading of the section.=C2=A0 Other points in Section 7 also fir=
st relate the issue raised, followed by our response regarding how it can b=
e addressed.=C2=A0

thanks.
-- Anees


=

On Thu, Sep 10, 2015 at 1:40 AM, Benoit Claise <=
span dir=3D"ltr"><bclaise@cisco.com> wrote:

 =20

   =20
 =20
  

    Dear all,

    

    The YANG
      coordination team has spent some time reading and gathering
    input on the requirements and proposed solutions in
    draft-openconfig-netmod-opstate. This note is to collect some
    observations that will hopefully contribute to progress in the
    working group.

    

    We believe it is useful to consider that YANG was initially designed
    to be a data modeling language for the NETCONF protocol. IETF is
    also working on RESTCONF which is an HTTP-based protocol to access
    data defined in YANG, using the datastores defined in NETCONF.

    

    YANG is fulfilling its intended role with NETCONF and RESTCONF and
    has gained some significant traction in this capacity. There are
    some changes worked on in YANG 1.1, but they are mostly incremental.
    

    There is interest in using other protocols outside of NETCONF and
    RESTCONF to manipulate data described by YANG. The proposals in the
    draft is based on the assertion that YANG models should be usable
    for protocols beyond RESTCONF and NETCONF. So these are new
    requirements on YANG from, or in preparation for, new protocol
    bindings.

    

    We have focused on two main aspects of the draft.

    

    FIRSTLY: The proposed split between intended and applied
    configuration as described in sections 4.1 (requirements) and 5.1
    (implications)

    

    There are two observations here:

    1. The implication is that all configurable data nodes ("intended
    configuration") shall be repeated in an operational version
    ("applied configuration") in all models for all applications =
going
    forward. This would apply independent of if the system is
    synchronous or asynchronous in nature. Synchronous systems would
    simply hard-wire the applied configuration to be the same as
    intended configuration at all times.

    2. An informal round of conversations with some vendors as well as
    some tooling vendors show that there are currently no widely known
    platforms that allow for observing the intended and applied state
    separately. A common architecture includes a central configuration
    data store that is being updated by the manageability framework and
    updates read by the subsystems affected by the change (e.g. the BGP
    service or the interface manager). In this case, there is no other
    source of configuration except for the content of the data store.

    

    Please note that this was not an exhaustive collection of data, but
    should give some directional information.

    

    The *implication* we would like to make here is that by making this
    feature mandatory part of the YANG language itself (as opposed to an
    optional capability) we risk introducing a fake perception that the
    current NETCONF server supports a capability it can't
    support.=C2=A0Indeed, polling the applied configuration would always
    return the intended configuration.

    

    A *question* would be if it would be useful to consider a direction
    where we make an attempt to separate out requirements that are tied
    to specific protocols and solve them in the protocol semantics
    rather than in the language to the extent we can. Without knowing
    more about the intended protocol in the case of this draft, it is
    hard to make more progress.

    

    A *suggestion* is to ask the draft authors to document the protocol
    bindings in order to qualify the requirements going forward.

    

    SECONDLY: The proposed schema locations for configuration and
    corresponding operational state in sections 4.5 (requirements) and
    5.4 (implications)

    

    The observation to be made here is well captured in the draft itself
    as bullet 3 under section 7:

    

    =C2=A0=C2=A0=C2=A0 "The proposal does not allow items that are not=
 configured,
    configured but not present, or system configured."

    

    Please note that this is a general note that would apply to the
    language itself. Meaning that YANG will no longer be able to
    describe situations like the above for any type of application in
    any context.

    

    Examples beyond what's already mentioned in the bullet of this coul=
d
    include:

    - Removable physical assets (line cards, mezzanine cards) in systems
    that allow pre-provisioning of configuration

    - Physical assets that arrive in the system with readable default
    state

    

    Independent of the direction we will be taking going forward, the
    implication we make is that it is a pretty significant impact on the
    expressivity of the language itself and how useful it is in terms of
    modeling application data sets that may not align with the
    requirements.

    

    The question we would ask is if it would be possible to rebalance
    the implication and make it a little more modular and optional in
    the language. We are aware of suggestions to use the extensibility
    of the language itself (e.g. in draft-kwatsen-netmod-opstate) to
    express relations across data sets. Understanding that this
    suggested approach does not normalize the paths according to the
    wish of the authors, but it can perhaps be a balanced approach that
    impacts the expressivity less.

    

    =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 Regards, the YANG coordination=
 team

  



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c14e921066a7051f71a9b1--


From nobody Fri Sep 11 00:38:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFBE1B3F6A for ; Fri, 11 Sep 2015 00:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsY2ANSRqFzq for ; Fri, 11 Sep 2015 00:38:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 467DB1B3079 for ; Fri, 11 Sep 2015 00:38:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 86ED11AE096B; Fri, 11 Sep 2015 09:38:46 +0200 (CEST)
Date: Fri, 11 Sep 2015 09:38:46 +0200 (CEST)
Message-Id: <20150911.093846.709202940600841233.mbj@tail-f.com>
To: aldrin.ietf@gmail.com
From: Martin Bjorklund 
In-Reply-To: <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 07:38:49 -0000

U2FtIEFsZHJpbiA8YWxkcmluLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+ID4gT24gU2Vw
IDEwLCAyMDE1LCBhdCA0OjEzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+ID4gPG1qZXRoYW5h
bmRhbmlAZ21haWwuY29tPiB3cm90ZToNCj4gPiANCj4gPiANCj4gPj4gT24gU2VwIDEwLCAyMDE1
LCBhdCAxMjo0MyBQTSwgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKQ0KPiA+PiA8Y2Ftb2JlcmdAY2lz
Y28uY29tIDxtYWlsdG86Y2Ftb2JlcmdAY2lzY28uY29tPj4gd3JvdGU6DQo+ID4+IA0KPiA+PiBO
b3csIHRoaW5rIGFib3V0IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyB0aGF0IGhhdmUgYXBwbGll
ZA0KPiA+PiBjb25maWd1cmF0aW9uIGxvY2F0ZWQgaW4gbW9yZSB0aGFuIG9uZSBwbGFjZS4gTGV0
4oCZcyBzYXkgeW91IGNoYW5nZSB0aGUNCj4gPj4gSVAgYWRkcmVzcyBvZiBhbiBpbnRlcmZhY2Us
IGl0IGlzIGxpa2VseSB0aGF0IHRoaXMgY29uZmlndXJhdGlvbiB3aWxsDQo+ID4+IGJlIHBhc3Nl
ZCBhcm91bmQgYXMgaW5wdXQgdG8gYSBoYW5kZnVsIG9mIHN1YnN5c3RlbXMgKGUuZy4gdGhlIERI
Q1ANCj4gPj4gc2VydmVyLCBzb21lIHJvdXRpbmcgZGFlbW9ucyB0aGF0IG1heSBiaW5kIHRvIHNw
ZWNpZmljIElQDQo+ID4+IGFkZHJlc3NlcykuIElzIHRoZSBpbnRlbmRlZCBhbmQgYXBwbGllZCBp
biBzeW5jIHdoZW4gYSBzcGVjaWZpYyBzdWJzZXQNCj4gPj4gb2YgdGhvc2UgY29uZmlndXJhdGlv
bnMgYXJlIHVwZGF0ZWQuIFdoYXQgaGFwcGVucyBpZiB0aGVyZeKAmXMgYSBwYXJ0aWFsDQo+ID4+
IGZhaWx1cmU/DQo+ID4gDQo+ID4gVGhpcyBpcyBhIGdvb2QgZXhhbXBsZS4gQW5vdGhlciBleGFt
cGxlLCBhbmQgc29tZWJvZHkgb24gdGhlIGNhbGwNCj4gPiB0b2RheSBzdGFydGVkIHRvIGFzayB0
aGlzIGJ1dCBnb3QgY3V0IG9mZiwgcmVsYXRlcyB0byBpbnRlcmZhY2VzIG9uDQo+ID4gdGhlIGRl
dmljZS4NCj4gPiANCj4gPiBJbnRlcmZhY2VzIGFscmVhZHkgZXhpc3Qgb24gYSBzeXN0ZW0uIEFz
IHN1Y2ggdGhleSBoYXZlIGENCj4gPiBjb25maWd1cmF0aW9uIChkZWZhdWx0IHZhbHVlcykgdGhh
dCBleGlzdHMgb24gdGhlbS4gVGhleSBhcmUgZW5hYmxlZA0KPiA+IHdoZW4gY29uZmlndXJhdGlv
biBnZXRzIGFwcGxpZWQgb24gdGhlbS4gVGhleSB3aWxsIGhhdmUgYXBwbGllZA0KPiA+IGNvbmZp
Z3VyYXRpb24gYnV0IG5vIGludGVuZGVkIGNvbmZpZ3VyYXRpb24uIFNob3VsZCB0aGlzIGJlIHJl
cG9ydGVkPw0KPiA+IA0KPiA+IFlldCBhbm90aGVyIGV4YW1wbGUgaXMgb2YgYSBCRkQgc2Vzc2lv
biB0aGF0IGdldHMgYm9vdHN0cmFwcGVkIGJlY2F1c2UNCj4gPiBvZiBhIHBpbmcuIFRoZXJlIGlz
IG5vIGludGVuZGVkIGNvbmZpZ3VyYXRpb24sIGJ1dCB0aGUgc2Vzc2lvbiBleGlzdHMNCj4gPiBh
bmQgYSBxdWVyeSBvZiBjb25maWd1cmF0aW9uIGluIHRoaXMgY2FzZSB3b3VsZCByZXR1cm4gYSB2
YWxpZCBCRkQNCj4gPiBzZXNzaW9uLg0KPiA+IA0KPiA+IENvdWxkIHdlIGdldCBzb21lIGNsYXJp
ZmljYXRpb24gKHdpdGggZXhhbXBsZXMsIHByZWZlcmFibHkpIG9uIHdoYXQNCj4gPiB0aGUgZXhw
ZWN0YXRpb24gaXMgZnJvbSBhIG9wZW5jb25maWcgb3BzdGF0ZSBwZXJzcGVjdGl2ZT8NCj4gDQo+
IFNlY3Rpb24gNyBvZiBkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1vcHN0YXRlIHRhbGtzIGFib3V0
DQo+IHRoYXQuIFNwZWNpZmljYWxseSwgIzMgdGFsa3MgYWJvdXQgdGhlIGludGVyZmFjZSBxdWVz
dGlvbiB5b3UgcmFpc2UuLg0KDQpJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0aGF0IHdlIHVuZGVy
c3RhbmQgaG93IHRoaXMgJ2FwcGxpZWQgY29uZmlnJw0KaXMgc3VwcG9zZWQgdG8gYmUgcG9wdWxh
dGVkIG9uIGEgZGV2aWNlLg0KDQpGaXJzdCBpdCB3YXMgc2FpZCB0aGF0IGl0IHRoZXJlIGlzIGp1
c3Qgb25lIHdheSB0aGV5IGNhbiBiZSBkaWZmZXJlbnQ7DQp0aW1lIChvbiBhc3luYyBzeXN0ZW1z
KS4gIEFmdGVyIHNvbWUgZGlzY3Vzc2lvbiBJIHRoaW5rIHRoZXJlIGFyZSBub3cNCmZvdXIgd2F5
czoNCg0KICAxLiAgVGltZSAoaW4gYXN5bmMgc3lzdGVtcykuDQoNCiAgMi4gIEhhcmR3YXJlLiAg
SWYgc29tZXRoaW5nIGlzIGluIGludGVuZGVkIGNvbmZpZyBidXQgdGhlcmUgaXMgbm8gaHcNCiAg
ICAgIHByZXNlbnQsIGl0IGlzIG5vdCBpbiBhcHBsaWVkLg0KDQogIDMuICBTeXN0ZW0tY29udHJv
bGxlZCBzdHVmZi4gIElmIHRoZSBzeXN0ZW0gYXV0by1jcmVhdGVzIGFuDQogICAgICBpbnRlcmZh
Y2UgKGZvciBleGFtcGxlKSwgaXQgd2lsbCBiZSBpbiB0aGUgYXBwbGllZCBjb25maWcgYnV0DQog
ICAgICBub3QgaW4gaW50ZW5kZWQuDQoNCiAgNC4gICJUZW1wbGF0ZSBzdWJzdGl0dXRpb24iOyB0
aGUgZHJhZnQgdXNlcyB0aGUgZXhhbXBsZSBvZiBhbiAnYWxsJw0KICAgICAgaW50ZXJmYWNlIHRo
YXQgZXhpc3RzIGluIGludGVuZGVkIGNvbmZpZyBidXQgbm90IGluIGFwcGxpZWQuDQoNCg0KVGhl
biBMYWRhIGJyb3VnaHQgdXAgdGhlIGV4YW1wbGUgb2YgaXAgYWRkcmVzc2VzLiAgSXQgd2FzIG1l
bnRpb25lZA0Kb24gdGhlIGNhbGwgdGhhdCBmb3IgaXAgYWRkcmVzc2VzIHRoZXJlIHdvdWxkIGJl
IHRocmVlIGxpc3RzOyBvbmUgZm9yDQppbnRlbmRlZCwgb25lIGZvciBhcHBsaWVkLCBhbmQgb25l
IGluIGRlcml2ZWQgc3RhdGUsIHdoZXJlIHRoZSBvbmUgaW4NCmRlcml2ZWQgc3RhdGUgaXMgd2hh
dCB0aGUgYm94ICpyZWFsbHkqIHVzZXMuICBTbyBmb3IgZXhhbXBsZSBpZiBpdA0KZ2V0cyBhbiBp
cCBmcm9tIGRoY3AsIGl0IHdpbGwgYmUgaW4gdGhlIGRlcml2ZWQgc3RhdGUgbGlzdCwgYnV0IG5v
dCBpbg0KYXBwbGllZCBjb25maWcuDQoNCldoeSBpcyB0aGlzIGlwLWFkZHJlc3MgbGlzdCBkaWZm
ZXJlbnQgZnJvbSB0aGUgaW50ZXJmYWNlIGxpc3Q/ICBXaHkNCndhcyBpdCBlbm91Z2ggd2l0aCB0
d28gbGlzdHMgZm9yIGludGVyZmFjZXMsIGJ1dCB3ZSBuZWVkIHRocmVlIGZvciBpcA0KYWRkcmVz
c2VzPw0KDQoNCi9tYXJ0aW4NCg==


From nobody Fri Sep 11 02:20:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946851A8A9A for ; Fri, 11 Sep 2015 02:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC7TNqJKEPoJ for ; Fri, 11 Sep 2015 02:20:32 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6258E1A0242 for ; Fri, 11 Sep 2015 02:20:32 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5F30A1CC0181; Fri, 11 Sep 2015 11:20:31 +0200 (CEST)
From: Ladislav Lhotka 
To: Randy Presuhn , netmod@ietf.org
In-Reply-To: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 11 Sep 2015 11:20:30 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 09:20:34 -0000

Randy Presuhn  writes:

> Hi -
>
>>From: Ladislav Lhotka 
>>Sent: Sep 10, 2015 2:02 AM
>>To: Randy Presuhn , netmod@ietf.org
>>Subject: Re: [netmod] Y26 again, sorry
>>
>>Randy Presuhn  writes:
>>
>>> Hi -
>>>
>>>> From: Andy Bierman
>>>> Sent: Sep 9, 2015 12:10 PM
>>>> To: Ladislav Lhotka
>>>> Cc: Robert Wilton , Randy Presuhn , "netmod@ietf.org"
>>>> Subject: Re: [netmod] Y26 again, sorry
>>> ...
>>>> I don't think it really addresses the design pattern very well.
>>>> You want to claim that M and Q are both being developed at the
>>>> same time,so it's OK that Q adds mandatory nodes to M.  YANG
>>>> has no such rule.YANG says a server can implement M and never
>>>> implement Q.YANG says a server may implement M and then add Q
>>>> in a future release.These conformance mechanisms do not align
>>>> with your expectationsof how YANG can/should be used.
>>>
>>> I agree with Andy that there seems to be a mismatch in expectations.
>>
>>I wonder if we can explain these differences. Is your and Andy's
>>expectation that the configuration schema has to reflect actual hardware
>>configuration, perhaps even dynamically adjust to the changes?
>
> I can't speak for Andy, but I would expect that a server's
> schema could change dynamically, as a result, for example,
> of new hardware or software being introduced into a running
> system.  We were doing this in the late 1980's - it's one
> of the things that pulled us into the subagent technology space.

My (faint) understanding of CMIP/GDMO is that it was about management
objects and prototypes, which indeed makes such a plug-in architecture
easier. NETCONF/YANG deals with documents and schemas instead, and I
assume the data model is in mostly (always?) fixed by NETCONF/RESTCONF
server implementation. Am I wrong?

>
>>In my view, the supported (and advertised) data model and hardware
>>configuration of the device are two different things.
>
> They are different, but there are relationships.  When a new
> line card is inserted, I would expect the system to acquire
> any necessary schema knowledge in order to manage that new
> resource.  Likewise, if non-present hardware is being provisioned,
> part of that provisioning process (possibly implicit) is for
> the system being provisioned to acquire the necessary schema
> knowledge so that it can perform at least a preliminary validation of
> the provisioning data.

I would expect that schema parts related to the new hardware have to be
present beforehand. Encapsulation in YANG models is just a matter of
conventions, so I think a general solution to dynamically changing
schemas is next to impossible, also because parts of data model
semantics may be expressed in prose (descriptions). 

>
>>> Let's look at a slightly more complex hypothetical case to tease
>>> out how folks *want* things to work.  Assume the following have
>>> been defined:
>>>
>>>   - base module M
>>>   - augmentation Q
>>>   - augmentation R
>>>
>>> On a server claiming to supporting the modules containing M, Q,
>>> and R, respectively, which of the following might one encounter
>>> concurrently?
>>>
>>>      - plain M
>>>      - M+Q
>>>      - M+R
>>>      - M+Q+R
>>
>>It depends on what you mean by "encounter" but in terms of datastore
>>validity the only possible answer IMO is M+Q+R.
>
> By "encounter" I mean if a client asks the server for all of its Ms,
> and the server also supports Q and R, are all of the Ms *guaranteed*
> to be M+Q+R, or is it possible that some of the Ms might lack Q or
> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
> how would one model a system inhabited by a mixture of the four
> kinds of Ms?

This very much depends on how M, Q and R are designed. In a typical
case, such as ietf-interfaces or ietf-routing, the augmenting modules
just add new alternatives (interface types, address families, routing
protocols).

Lada

>
> Randy

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 11 02:54:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15A31A893C for ; Fri, 11 Sep 2015 02:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLOziboPnjt4 for ; Fri, 11 Sep 2015 02:54:25 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5476B1B33E8 for ; Fri, 11 Sep 2015 02:54:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5506; q=dns/txt; s=iport; t=1441965265; x=1443174865; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YRkFY5wEgLLwEzOZDS4lZYuOG3R6dJY06W+JBAYC9Ok=; b=OEAJXw465avLXgA+fRmcAAovJDicg9gCmDdn6rBBLJpgD0cOmcMqb7Ov UP3DH4xkHAE6kk1UT0nF+cIs5R8Tp6x9d1QQ0s7BIiPNCDykLIavWlCfk f4ZoOOKY6f4y1QScingQ3DH8AScf0oRKJ98yGeeFmYsK7Wc01WCuiDhrV Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DoAQARpPJV/xbLJq1dg3dpgyq6CAENgW4KhS9KAoIKFAEBAQEBAQGBCoQjAQEBAwEBAQEgDwEFNgsQCw4KAgIFHgMCAg8CEAYfEQYBDAYCAQGIFQMKCA23EY8uDYRlAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIoVRhH2CUIFySweCaYFDBYcuhneHMYcyg1uBbYh8ikGHPB8BAUKCEByBVT0zih8BAQE
X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="629662584"
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; 11 Sep 2015 09:54:23 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8B9sMVj000343; Fri, 11 Sep 2015 09:54:23 GMT
To: Martin Bjorklund , aldrin.ietf@gmail.com
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <55F2A4CE.70608@cisco.com>
Date: Fri, 11 Sep 2015 10:54:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150911.093846.709202940600841233.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 09:54:27 -0000

Hi Martin,

On 11/09/2015 08:38, Martin Bjorklund wrote:
> Sam Aldrin  wrote:
>>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>>>  wrote:
>>>
>>>
>>>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>>>> > wrote:
>>>>
>>>> Now, think about configuration parameters that have applied
>>>> configuration located in more than one place. Let’s say you change the
>>>> IP address of an interface, it is likely that this configuration will
>>>> be passed around as input to a handful of subsystems (e.g. the DHCP
>>>> server, some routing daemons that may bind to specific IP
>>>> addresses). Is the intended and applied in sync when a specific subset
>>>> of those configurations are updated. What happens if there’s a partial
>>>> failure?
>>> This is a good example. Another example, and somebody on the call
>>> today started to ask this but got cut off, relates to interfaces on
>>> the device.
>>>
>>> Interfaces already exist on a system. As such they have a
>>> configuration (default values) that exists on them. They are enabled
>>> when configuration gets applied on them. They will have applied
>>> configuration but no intended configuration. Should this be reported?
>>>
>>> Yet another example is of a BFD session that gets bootstrapped because
>>> of a ping. There is no intended configuration, but the session exists
>>> and a query of configuration in this case would return a valid BFD
>>> session.
>>>
>>> Could we get some clarification (with examples, preferably) on what
>>> the expectation is from a openconfig opstate perspective?
>> Section 7 of draft-openconfig-netmod-opstate talks about
>> that. Specifically, #3 talks about the interface question you raise..
> I think it is important that we understand how this 'applied config'
> is supposed to be populated on a device.
>
> First it was said that it there is just one way they can be different;
> time (on async systems).  After some discussion I think there are now
> four ways:
>
>    1.  Time (in async systems).
>
>    2.  Hardware.  If something is in intended config but there is no hw
>        present, it is not in applied.
>
>    3.  System-controlled stuff.  If the system auto-creates an
>        interface (for example), it will be in the applied config but
>        not in intended.

I don't agree with this one.
  - if a system auto-creates an interface with no config then it is 
/interfaces-state, but not in /interfaces.
  - if a system auto-creates an interface and only then applies default 
config, the default config would go in intended and applied.
  - interfaces with pre-config that could be put into intended, but be 
left out of applied (because the hw isn't present).

So in summary, I would say that config is in applied and not intended 
only if the config is in the process of being deleted (or the delete 
operational failed for some reason).

>
>    4.  "Template substitution"; the draft uses the example of an 'all'
>        interface that exists in intended config but not in applied.
I don't agree with this one either.  I don't think that cfg intended vs 
applied can or should be used as templating mechanism.

But I think that there is another case, which is for config that was 
accepted into the system (i.e. semantically valid) and then failed when 
being applied.  E.g. due to a system, or internal error.  There is also 
a possible failure due to out of resource (which could be counted as the 
same as case 2).

For a sync system, config failures can be returned as part of the 
edit-config request.  What is the equivalent mechanism for an async system?


>
> Then Lada brought up the example of ip addresses.  It was mentioned
> on the call that for ip addresses there would be three lists; one for
> intended, one for applied, and one in derived state, where the one in
> derived state is what the box *really* uses.  So for example if it
> gets an ip from dhcp, it will be in the derived state list, but not in
> applied config.
>
> Why is this ip-address list different from the interface list?  Why
> was it enough with two lists for interfaces, but we need three for ip
> addresses?
I don't see that they are different.  I think that you have 3 
lists/leaves in both cases:

I.e. I would say that 3 IP addr leaves are required in an async system, 
at a given time t:
  - only the intended leaf can indicate what IP addr config the operator 
wants on the interface (if any).
  - only the applied leaf can indicate what IP addr is actually being 
used as the configured value on the interface.
  - only the derived leaf can indicate what IP addr is actually 
operationally being used for the interface (which might be due to IP 
addr config, DHCP, or perhaps some other mechanism).

I think that in the both kwatsen-netmod-opstate and 
wilton-netmod-opstate there are logically 3 interface lists as well:
  - /if:interfaces is logically split into 2, either through being 
present in separate running and applied datastores, or through having 
separate cfg-intended/cfg-applied leaves.
  - /if:interfaces-state, which I perceive as logically the derived 
state for an interface.

Cheers,
Rob


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


From nobody Fri Sep 11 03:07:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFA51B45B3 for ; Fri, 11 Sep 2015 03:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-_Rm6TwsIbf for ; Fri, 11 Sep 2015 03:07:42 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A43A41B3EAB for ; Fri, 11 Sep 2015 03:07:41 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6F14D1CC0181; Fri, 11 Sep 2015 12:07:42 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , aldrin.ietf@gmail.com
In-Reply-To: <20150911.093846.709202940600841233.mbj@tail-f.com>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 11 Sep 2015 12:07:40 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 10:07:44 -0000

Martin Bjorklund  writes:

> Sam Aldrin  wrote:
>>=20
>> > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>> >  wrote:
>> >=20
>> >=20
>> >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>> >> > wrote:
>> >>=20
>> >> Now, think about configuration parameters that have applied
>> >> configuration located in more than one place. Let=E2=80=99s say you c=
hange the
>> >> IP address of an interface, it is likely that this configuration will
>> >> be passed around as input to a handful of subsystems (e.g. the DHCP
>> >> server, some routing daemons that may bind to specific IP
>> >> addresses). Is the intended and applied in sync when a specific subset
>> >> of those configurations are updated. What happens if there=E2=80=99s =
a partial
>> >> failure?
>> >=20
>> > This is a good example. Another example, and somebody on the call
>> > today started to ask this but got cut off, relates to interfaces on
>> > the device.
>> >=20
>> > Interfaces already exist on a system. As such they have a
>> > configuration (default values) that exists on them. They are enabled
>> > when configuration gets applied on them. They will have applied
>> > configuration but no intended configuration. Should this be reported?
>> >=20
>> > Yet another example is of a BFD session that gets bootstrapped because
>> > of a ping. There is no intended configuration, but the session exists
>> > and a query of configuration in this case would return a valid BFD
>> > session.
>> >=20
>> > Could we get some clarification (with examples, preferably) on what
>> > the expectation is from a openconfig opstate perspective?
>>=20
>> Section 7 of draft-openconfig-netmod-opstate talks about
>> that. Specifically, #3 talks about the interface question you raise..
>
> I think it is important that we understand how this 'applied config'
> is supposed to be populated on a device.
>
> First it was said that it there is just one way they can be different;
> time (on async systems).  After some discussion I think there are now
> four ways:
>
>   1.  Time (in async systems).
>
>   2.  Hardware.  If something is in intended config but there is no hw
>       present, it is not in applied.
>
>   3.  System-controlled stuff.  If the system auto-creates an
>       interface (for example), it will be in the applied config but
>       not in intended.
>
>   4.  "Template substitution"; the draft uses the example of an 'all'
>       interface that exists in intended config but not in applied.
>
>
> Then Lada brought up the example of ip addresses.  It was mentioned
> on the call that for ip addresses there would be three lists; one for
> intended, one for applied, and one in derived state, where the one in
> derived state is what the box *really* uses.  So for example if it
> gets an ip from dhcp, it will be in the derived state list, but not in
> applied config.

Right. After yesterday's interim I am much less in favour of this
intended/applied proposal because

- as you say, applied configuration falls short of representing "the
  state that the network element is actually in",

- states in which intended and applied configuration can be out of sync
  are only transient. In the use cases I am interested in, such states
  could be relatively normal and last long.

Another example that comes to my mind are static routes: an operator
needs to know that a configured static route got installed, and this can
be verified only by inspecting a corresponding RIB (operational
state). I don't see how a copy of static routes in applied configuration
could help.

I agree with Juergen that what we need is a clever representation of
operational state and this is hard work that needs to be done by experts
on an ad hoc basis. That's why I am also sceptical about the possibility
of having fixed and universally applicable relationships between
configuration and operational state.

Lada

>
> Why is this ip-address list different from the interface list?  Why
> was it enough with two lists for interfaces, but we need three for ip
> addresses?
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 11 03:27:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28621B3B77 for ; Fri, 11 Sep 2015 03:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7EuIK_cejcC for ; Fri, 11 Sep 2015 03:27:41 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450: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 A7F211B3EF2 for ; Fri, 11 Sep 2015 03:27:40 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so52995711wic.1 for ; Fri, 11 Sep 2015 03:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1nM2TOOrQyDxSMOxKVTP6QKHxz3s0nXuRY51vSIN7vo=; b=Fl3VbPXp2SAh5kdRrGjo7L8meaSDlHmdS14dP9nwroyjnev7s5IWwbwUfU+kV6J7kc nbW6hwViWzMFAWJLCI8mU9R5uiXYtdtR/mlfVysXD6rCyIPJUTUrWFEta+WUmAWVBCVw gVnXfcet3ele/6uu8F1B6zuJ7BzctN5f93BFKh9j+iTDFIrr4QiyroXiKChBQ7ho4oxJ 8XIuEypvWua5lHllyjBB57Z03sztAlXgedw57Ug4VBCdUvYbE4hV+A1iANb6MgKlPKFm MBfvAFAQ6Ygw6Znt8V4o5IwEGkQQwodwnIO44nIGJ6UYM/4re69To2m3QctUqPmtoSJd zW7A==
X-Received: by 10.180.107.1 with SMTP id gy1mr16241533wib.56.1441967259238; Fri, 11 Sep 2015 03:27:39 -0700 (PDT)
Received: from [192.168.1.62] (200.Red-79-146-232.dynamicIP.rima-tde.net. [79.146.232.200]) by smtp.gmail.com with ESMTPSA id x10sm13970351wiy.6.2015.09.11.03.27.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Sep 2015 03:27:38 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Fri, 11 Sep 2015 12:27:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E9E5B5F-6B39-4CDA-9CEF-02EA4B030100@gmail.com>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com> 
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 10:27:43 -0000

> On Sep 11, 2015, at 12:07 PM, Ladislav Lhotka  wrote:
>=20
> Martin Bjorklund  writes:
>=20
>> Sam Aldrin  wrote:
>>>=20
>>>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>>>>> > wrote:
>>>>>=20
>>>>> Now, think about configuration parameters that have applied
>>>>> configuration located in more than one place. Let=E2=80=99s say =
you change the
>>>>> IP address of an interface, it is likely that this configuration =
will
>>>>> be passed around as input to a handful of subsystems (e.g. the =
DHCP
>>>>> server, some routing daemons that may bind to specific IP
>>>>> addresses). Is the intended and applied in sync when a specific =
subset
>>>>> of those configurations are updated. What happens if there=E2=80=99s=
 a partial
>>>>> failure?
>>>>=20
>>>> This is a good example. Another example, and somebody on the call
>>>> today started to ask this but got cut off, relates to interfaces on
>>>> the device.
>>>>=20
>>>> Interfaces already exist on a system. As such they have a
>>>> configuration (default values) that exists on them. They are =
enabled
>>>> when configuration gets applied on them. They will have applied
>>>> configuration but no intended configuration. Should this be =
reported?
>>>>=20
>>>> Yet another example is of a BFD session that gets bootstrapped =
because
>>>> of a ping. There is no intended configuration, but the session =
exists
>>>> and a query of configuration in this case would return a valid BFD
>>>> session.
>>>>=20
>>>> Could we get some clarification (with examples, preferably) on what
>>>> the expectation is from a openconfig opstate perspective?
>>>=20
>>> Section 7 of draft-openconfig-netmod-opstate talks about
>>> that. Specifically, #3 talks about the interface question you =
raise..
>>=20
>> I think it is important that we understand how this 'applied config'
>> is supposed to be populated on a device.
>>=20
>> First it was said that it there is just one way they can be =
different;
>> time (on async systems).  After some discussion I think there are now
>> four ways:
>>=20
>>  1.  Time (in async systems).
>>=20
>>  2.  Hardware.  If something is in intended config but there is no hw
>>      present, it is not in applied.
>>=20
>>  3.  System-controlled stuff.  If the system auto-creates an
>>      interface (for example), it will be in the applied config but
>>      not in intended.
>>=20
>>  4.  "Template substitution"; the draft uses the example of an 'all'
>>      interface that exists in intended config but not in applied.
>>=20
>>=20
>> Then Lada brought up the example of ip addresses.  It was mentioned
>> on the call that for ip addresses there would be three lists; one for
>> intended, one for applied, and one in derived state, where the one in
>> derived state is what the box *really* uses.  So for example if it
>> gets an ip from dhcp, it will be in the derived state list, but not =
in
>> applied config.
>=20
> Right. After yesterday's interim I am much less in favour of this
> intended/applied proposal because
>=20
> - as you say, applied configuration falls short of representing "the
>  state that the network element is actually in",
>=20
> - states in which intended and applied configuration can be out of =
sync
>  are only transient. In the use cases I am interested in, such states
>  could be relatively normal and last long.
>=20
> Another example that comes to my mind are static routes: an operator
> needs to know that a configured static route got installed, and this =
can
> be verified only by inspecting a corresponding RIB (operational
> state). I don't see how a copy of static routes in applied =
configuration
> could help.
>=20
> I agree with Juergen that what we need is a clever representation of
> operational state and this is hard work that needs to be done by =
experts
> on an ad hoc basis. That's why I am also sceptical about the =
possibility
> of having fixed and universally applicable relationships between
> configuration and operational state.

This is very true! As the networking is done today by vendors, achieving =
universally applicable relation between config and operational state is =
very hard. Openconfig folks want to get a single tree with of variables =
and it is lot of work for existing vendors to translate between customer =
desires and current vendor implementations, having separate operational =
and config models.

We should ask ourselves are we ready to work on an object oriented =
networking model with getter and setter functions and if vendors are =
ready to support such model.

Dean

>=20
> Lada
>=20
>>=20
>> Why is this ip-address list different from the interface list?  Why
>> was it enough with two lists for interfaces, but we need three for ip
>> addresses?
>>=20
>>=20
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --=20
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 11 03:35:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C811AD0A7 for ; Fri, 11 Sep 2015 03:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7llrWKL9CFG for ; Fri, 11 Sep 2015 03:35:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 270941ACDCB for ; Fri, 11 Sep 2015 03:35:15 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 701C11AE09C3; Fri, 11 Sep 2015 12:35:13 +0200 (CEST)
Date: Fri, 11 Sep 2015 12:35:12 +0200 (CEST)
Message-Id: <20150911.123512.343807770675929180.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <55F2A4CE.70608@cisco.com>
References: <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com> <55F2A4CE.70608@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 10:35:17 -0000

Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+
IA0KPiBPbiAxMS8wOS8yMDE1IDA4OjM4LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+IFNh
bSBBbGRyaW4gPGFsZHJpbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+PiBPbiBTZXAgMTAs
IDIwMTUsIGF0IDQ6MTMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkNCj4gPj4+IDxtamV0aGFuYW5k
YW5pQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiBPbiBTZXAgMTAsIDIw
MTUsIGF0IDEyOjQzIFBNLCBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpDQo+ID4+Pj4gPGNhbW9iZXJn
QGNpc2NvLmNvbSA8bWFpbHRvOmNhbW9iZXJnQGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+Pj4+DQo+
ID4+Pj4gTm93LCB0aGluayBhYm91dCBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgdGhhdCBoYXZl
IGFwcGxpZWQNCj4gPj4+PiBjb25maWd1cmF0aW9uIGxvY2F0ZWQgaW4gbW9yZSB0aGFuIG9uZSBw
bGFjZS4gTGV04oCZcyBzYXkgeW91IGNoYW5nZSB0aGUNCj4gPj4+PiBJUCBhZGRyZXNzIG9mIGFu
IGludGVyZmFjZSwgaXQgaXMgbGlrZWx5IHRoYXQgdGhpcyBjb25maWd1cmF0aW9uIHdpbGwNCj4g
Pj4+PiBiZSBwYXNzZWQgYXJvdW5kIGFzIGlucHV0IHRvIGEgaGFuZGZ1bCBvZiBzdWJzeXN0ZW1z
IChlLmcuIHRoZSBESENQDQo+ID4+Pj4gc2VydmVyLCBzb21lIHJvdXRpbmcgZGFlbW9ucyB0aGF0
IG1heSBiaW5kIHRvIHNwZWNpZmljIElQDQo+ID4+Pj4gYWRkcmVzc2VzKS4gSXMgdGhlIGludGVu
ZGVkIGFuZCBhcHBsaWVkIGluIHN5bmMgd2hlbiBhIHNwZWNpZmljIHN1YnNldA0KPiA+Pj4+IG9m
IHRob3NlIGNvbmZpZ3VyYXRpb25zIGFyZSB1cGRhdGVkLiBXaGF0IGhhcHBlbnMgaWYgdGhlcmXi
gJlzIGEgcGFydGlhbA0KPiA+Pj4+IGZhaWx1cmU/DQo+ID4+PiBUaGlzIGlzIGEgZ29vZCBleGFt
cGxlLiBBbm90aGVyIGV4YW1wbGUsIGFuZCBzb21lYm9keSBvbiB0aGUgY2FsbA0KPiA+Pj4gdG9k
YXkgc3RhcnRlZCB0byBhc2sgdGhpcyBidXQgZ290IGN1dCBvZmYsIHJlbGF0ZXMgdG8gaW50ZXJm
YWNlcyBvbg0KPiA+Pj4gdGhlIGRldmljZS4NCj4gPj4+DQo+ID4+PiBJbnRlcmZhY2VzIGFscmVh
ZHkgZXhpc3Qgb24gYSBzeXN0ZW0uIEFzIHN1Y2ggdGhleSBoYXZlIGENCj4gPj4+IGNvbmZpZ3Vy
YXRpb24gKGRlZmF1bHQgdmFsdWVzKSB0aGF0IGV4aXN0cyBvbiB0aGVtLiBUaGV5IGFyZSBlbmFi
bGVkDQo+ID4+PiB3aGVuIGNvbmZpZ3VyYXRpb24gZ2V0cyBhcHBsaWVkIG9uIHRoZW0uIFRoZXkg
d2lsbCBoYXZlIGFwcGxpZWQNCj4gPj4+IGNvbmZpZ3VyYXRpb24gYnV0IG5vIGludGVuZGVkIGNv
bmZpZ3VyYXRpb24uIFNob3VsZCB0aGlzIGJlIHJlcG9ydGVkPw0KPiA+Pj4NCj4gPj4+IFlldCBh
bm90aGVyIGV4YW1wbGUgaXMgb2YgYSBCRkQgc2Vzc2lvbiB0aGF0IGdldHMgYm9vdHN0cmFwcGVk
IGJlY2F1c2UNCj4gPj4+IG9mIGEgcGluZy4gVGhlcmUgaXMgbm8gaW50ZW5kZWQgY29uZmlndXJh
dGlvbiwgYnV0IHRoZSBzZXNzaW9uIGV4aXN0cw0KPiA+Pj4gYW5kIGEgcXVlcnkgb2YgY29uZmln
dXJhdGlvbiBpbiB0aGlzIGNhc2Ugd291bGQgcmV0dXJuIGEgdmFsaWQgQkZEDQo+ID4+PiBzZXNz
aW9uLg0KPiA+Pj4NCj4gPj4+IENvdWxkIHdlIGdldCBzb21lIGNsYXJpZmljYXRpb24gKHdpdGgg
ZXhhbXBsZXMsIHByZWZlcmFibHkpIG9uIHdoYXQNCj4gPj4+IHRoZSBleHBlY3RhdGlvbiBpcyBm
cm9tIGEgb3BlbmNvbmZpZyBvcHN0YXRlIHBlcnNwZWN0aXZlPw0KPiA+PiBTZWN0aW9uIDcgb2Yg
ZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZSB0YWxrcyBhYm91dA0KPiA+PiB0aGF0LiBT
cGVjaWZpY2FsbHksICMzIHRhbGtzIGFib3V0IHRoZSBpbnRlcmZhY2UgcXVlc3Rpb24geW91IHJh
aXNlLi4NCj4gPiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0aGF0IHdlIHVuZGVyc3RhbmQgaG93
IHRoaXMgJ2FwcGxpZWQgY29uZmlnJw0KPiA+IGlzIHN1cHBvc2VkIHRvIGJlIHBvcHVsYXRlZCBv
biBhIGRldmljZS4NCj4gPg0KPiA+IEZpcnN0IGl0IHdhcyBzYWlkIHRoYXQgaXQgdGhlcmUgaXMg
anVzdCBvbmUgd2F5IHRoZXkgY2FuIGJlIGRpZmZlcmVudDsNCj4gPiB0aW1lIChvbiBhc3luYyBz
eXN0ZW1zKS4gIEFmdGVyIHNvbWUgZGlzY3Vzc2lvbiBJIHRoaW5rIHRoZXJlIGFyZSBub3cNCj4g
PiBmb3VyIHdheXM6DQo+ID4NCj4gPiAgICAxLiAgVGltZSAoaW4gYXN5bmMgc3lzdGVtcykuDQo+
ID4NCj4gPiAgICAyLiAgSGFyZHdhcmUuICBJZiBzb21ldGhpbmcgaXMgaW4gaW50ZW5kZWQgY29u
ZmlnIGJ1dCB0aGVyZSBpcyBubyBodw0KPiA+ICAgICAgICBwcmVzZW50LCBpdCBpcyBub3QgaW4g
YXBwbGllZC4NCj4gPg0KPiA+ICAgIDMuICBTeXN0ZW0tY29udHJvbGxlZCBzdHVmZi4gIElmIHRo
ZSBzeXN0ZW0gYXV0by1jcmVhdGVzIGFuDQo+ID4gICAgICAgIGludGVyZmFjZSAoZm9yIGV4YW1w
bGUpLCBpdCB3aWxsIGJlIGluIHRoZSBhcHBsaWVkIGNvbmZpZyBidXQNCj4gPiAgICAgICAgbm90
IGluIGludGVuZGVkLg0KPiANCj4gSSBkb24ndCBhZ3JlZSB3aXRoIHRoaXMgb25lLg0KPiAgLSBp
ZiBhIHN5c3RlbSBhdXRvLWNyZWF0ZXMgYW4gaW50ZXJmYWNlIHdpdGggbm8gY29uZmlnIHRoZW4g
aXQgaXMNCj4gIC0gL2ludGVyZmFjZXMtc3RhdGUsIGJ1dCBub3QgaW4gL2ludGVyZmFjZXMuDQoN
ClllcyB0aGlzIGlzIGhvdyBpZXRmLWludGVyZmFjZXMgd29yay4gIEJ1dCB0aGUgb3BlbmNvbmZp
ZyBwZW9wbGUgd2FudA0KdG8gY2hhbmdlIHRoaXMsIGFuZCBpbnRyb2R1Y2UgJ2FwcGxpZWQgY29u
ZmlnJyBhcyBhIHNpbXBsaWNpZmF0aW9uLiBJDQphbSAvIHdlIGFyZSB0cnlpbmcgdG8gdW5kZXJz
dGFuZCBob3cgdGhleSBpbnRlbmQgdGhpcyAnYXBwbGllZCBjb25maWcnDQp0byB3b3JrLg0KDQo+
ICAtIGlmIGEgc3lzdGVtIGF1dG8tY3JlYXRlcyBhbiBpbnRlcmZhY2UgYW5kIG9ubHkgdGhlbiBh
cHBsaWVzIGRlZmF1bHQNCj4gIC0gY29uZmlnLCB0aGUgZGVmYXVsdCBjb25maWcgd291bGQgZ28g
aW4gaW50ZW5kZWQgYW5kIGFwcGxpZWQuDQo+ICAtIGludGVyZmFjZXMgd2l0aCBwcmUtY29uZmln
IHRoYXQgY291bGQgYmUgcHV0IGludG8gaW50ZW5kZWQsIGJ1dCBiZQ0KPiAgLSBsZWZ0IG91dCBv
ZiBhcHBsaWVkIChiZWNhdXNlIHRoZSBodyBpc24ndCBwcmVzZW50KS4NCj4gDQo+IFNvIGluIHN1
bW1hcnksIEkgd291bGQgc2F5IHRoYXQgY29uZmlnIGlzIGluIGFwcGxpZWQgYW5kIG5vdCBpbnRl
bmRlZA0KPiBvbmx5IGlmIHRoZSBjb25maWcgaXMgaW4gdGhlIHByb2Nlc3Mgb2YgYmVpbmcgZGVs
ZXRlZCAob3IgdGhlIGRlbGV0ZQ0KPiBvcGVyYXRpb25hbCBmYWlsZWQgZm9yIHNvbWUgcmVhc29u
KS4NCj4gDQo+ID4NCj4gPiAgICA0LiAgIlRlbXBsYXRlIHN1YnN0aXR1dGlvbiI7IHRoZSBkcmFm
dCB1c2VzIHRoZSBleGFtcGxlIG9mIGFuICdhbGwnDQo+ID4gICAgICAgIGludGVyZmFjZSB0aGF0
IGV4aXN0cyBpbiBpbnRlbmRlZCBjb25maWcgYnV0IG5vdCBpbiBhcHBsaWVkLg0KPiBJIGRvbid0
IGFncmVlIHdpdGggdGhpcyBvbmUgZWl0aGVyLiAgSSBkb24ndCB0aGluayB0aGF0IGNmZyBpbnRl
bmRlZA0KPiB2cyBhcHBsaWVkIGNhbiBvciBzaG91bGQgYmUgdXNlZCBhcyB0ZW1wbGF0aW5nIG1l
Y2hhbmlzbS4NCg0KU2VlIGFib3ZlOyB0aGUgZm91ciBidWxsZXRzIGFyZSAobXkgdW5kZXJzdGFu
ZGluZyBvZikgd2hhdCB0aGUNCm9wZW5jb25maWcgcGVvcGxlIGhhdmUgc2FpZC4gIEkgaG9wZSB0
aGV5IGNsYXJpZnkgaWYgdGhpcyBpcyBub3Qgd2hhdA0KdGhleSBtZWFudC4NCg0KDQovbWFydGlu
DQoNCg0KPiBCdXQgSSB0aGluayB0aGF0IHRoZXJlIGlzIGFub3RoZXIgY2FzZSwgd2hpY2ggaXMg
Zm9yIGNvbmZpZyB0aGF0IHdhcw0KPiBhY2NlcHRlZCBpbnRvIHRoZSBzeXN0ZW0gKGkuZS4gc2Vt
YW50aWNhbGx5IHZhbGlkKSBhbmQgdGhlbiBmYWlsZWQNCj4gd2hlbiBiZWluZyBhcHBsaWVkLiAg
RS5nLiBkdWUgdG8gYSBzeXN0ZW0sIG9yIGludGVybmFsIGVycm9yLiAgVGhlcmUNCj4gaXMgYWxz
byBhIHBvc3NpYmxlIGZhaWx1cmUgZHVlIHRvIG91dCBvZiByZXNvdXJjZSAod2hpY2ggY291bGQg
YmUNCj4gY291bnRlZCBhcyB0aGUgc2FtZSBhcyBjYXNlIDIpLg0KPiANCj4gRm9yIGEgc3luYyBz
eXN0ZW0sIGNvbmZpZyBmYWlsdXJlcyBjYW4gYmUgcmV0dXJuZWQgYXMgcGFydCBvZiB0aGUNCj4g
ZWRpdC1jb25maWcgcmVxdWVzdC4gIFdoYXQgaXMgdGhlIGVxdWl2YWxlbnQgbWVjaGFuaXNtIGZv
ciBhbiBhc3luYw0KPiBzeXN0ZW0/DQo+IA0KPiANCj4gPg0KPiA+IFRoZW4gTGFkYSBicm91Z2h0
IHVwIHRoZSBleGFtcGxlIG9mIGlwIGFkZHJlc3Nlcy4gIEl0IHdhcyBtZW50aW9uZWQNCj4gPiBv
biB0aGUgY2FsbCB0aGF0IGZvciBpcCBhZGRyZXNzZXMgdGhlcmUgd291bGQgYmUgdGhyZWUgbGlz
dHM7IG9uZSBmb3INCj4gPiBpbnRlbmRlZCwgb25lIGZvciBhcHBsaWVkLCBhbmQgb25lIGluIGRl
cml2ZWQgc3RhdGUsIHdoZXJlIHRoZSBvbmUgaW4NCj4gPiBkZXJpdmVkIHN0YXRlIGlzIHdoYXQg
dGhlIGJveCAqcmVhbGx5KiB1c2VzLiAgU28gZm9yIGV4YW1wbGUgaWYgaXQNCj4gPiBnZXRzIGFu
IGlwIGZyb20gZGhjcCwgaXQgd2lsbCBiZSBpbiB0aGUgZGVyaXZlZCBzdGF0ZSBsaXN0LCBidXQg
bm90IGluDQo+ID4gYXBwbGllZCBjb25maWcuDQo+ID4NCj4gPiBXaHkgaXMgdGhpcyBpcC1hZGRy
ZXNzIGxpc3QgZGlmZmVyZW50IGZyb20gdGhlIGludGVyZmFjZSBsaXN0PyAgV2h5DQo+ID4gd2Fz
IGl0IGVub3VnaCB3aXRoIHR3byBsaXN0cyBmb3IgaW50ZXJmYWNlcywgYnV0IHdlIG5lZWQgdGhy
ZWUgZm9yIGlwDQo+ID4gYWRkcmVzc2VzPw0KPiBJIGRvbid0IHNlZSB0aGF0IHRoZXkgYXJlIGRp
ZmZlcmVudC4gIEkgdGhpbmsgdGhhdCB5b3UgaGF2ZSAzDQo+IGxpc3RzL2xlYXZlcyBpbiBib3Ro
IGNhc2VzOg0KPiANCj4gSS5lLiBJIHdvdWxkIHNheSB0aGF0IDMgSVAgYWRkciBsZWF2ZXMgYXJl
IHJlcXVpcmVkIGluIGFuIGFzeW5jDQo+IHN5c3RlbSwgYXQgYSBnaXZlbiB0aW1lIHQ6DQo+ICAt
IG9ubHkgdGhlIGludGVuZGVkIGxlYWYgY2FuIGluZGljYXRlIHdoYXQgSVAgYWRkciBjb25maWcg
dGhlIG9wZXJhdG9yDQo+ICAtIHdhbnRzIG9uIHRoZSBpbnRlcmZhY2UgKGlmIGFueSkuDQo+ICAt
IG9ubHkgdGhlIGFwcGxpZWQgbGVhZiBjYW4gaW5kaWNhdGUgd2hhdCBJUCBhZGRyIGlzIGFjdHVh
bGx5IGJlaW5nIHVzZWQNCj4gIC0gYXMgdGhlIGNvbmZpZ3VyZWQgdmFsdWUgb24gdGhlIGludGVy
ZmFjZS4NCj4gIC0gb25seSB0aGUgZGVyaXZlZCBsZWFmIGNhbiBpbmRpY2F0ZSB3aGF0IElQIGFk
ZHIgaXMgYWN0dWFsbHkNCj4gIC0gb3BlcmF0aW9uYWxseSBiZWluZyB1c2VkIGZvciB0aGUgaW50
ZXJmYWNlICh3aGljaCBtaWdodCBiZSBkdWUgdG8gSVANCj4gIC0gYWRkciBjb25maWcsIERIQ1As
IG9yIHBlcmhhcHMgc29tZSBvdGhlciBtZWNoYW5pc20pLg0KPiANCj4gSSB0aGluayB0aGF0IGlu
IHRoZSBib3RoIGt3YXRzZW4tbmV0bW9kLW9wc3RhdGUgYW5kDQo+IHdpbHRvbi1uZXRtb2Qtb3Bz
dGF0ZSB0aGVyZSBhcmUgbG9naWNhbGx5IDMgaW50ZXJmYWNlIGxpc3RzIGFzIHdlbGw6DQo+ICAt
IC9pZjppbnRlcmZhY2VzIGlzIGxvZ2ljYWxseSBzcGxpdCBpbnRvIDIsIGVpdGhlciB0aHJvdWdo
IGJlaW5nIHByZXNlbnQNCj4gIC0gaW4gc2VwYXJhdGUgcnVubmluZyBhbmQgYXBwbGllZCBkYXRh
c3RvcmVzLCBvciB0aHJvdWdoIGhhdmluZyBzZXBhcmF0ZQ0KPiAgLSBjZmctaW50ZW5kZWQvY2Zn
LWFwcGxpZWQgbGVhdmVzLg0KPiAgLSAvaWY6aW50ZXJmYWNlcy1zdGF0ZSwgd2hpY2ggSSBwZXJj
ZWl2ZSBhcyBsb2dpY2FsbHkgdGhlIGRlcml2ZWQgc3RhdGUNCj4gIC0gZm9yIGFuIGludGVyZmFj
ZS4NCj4gDQo+IENoZWVycywNCj4gUm9iDQo+IA0KPiANCj4gPg0KPiA+DQo+ID4gL21hcnRpbg0K
PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g
bmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0K


From nobody Fri Sep 11 03:48:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942881B46D0 for ; Fri, 11 Sep 2015 03:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7o5YlY33U1G for ; Fri, 11 Sep 2015 03:48:43 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9031B3804 for ; Fri, 11 Sep 2015 03:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4870; q=dns/txt; s=iport; t=1441968523; x=1443178123; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2Dw33pl1wH0YIcvqGyY4Ut55JBlmmQSAorDuP0l6U4Q=; b=PkGI/di0jVtKT8aPYs5tH+LOeCSbFNKDGot7LpTgZev9tPjE+zrZgxsA sugDT6v8KilMTFkTkIcbPEDn22qJZse3BBHE/z7maPz4Ckem7wVzjO3LJ otVe3R8o5+ezbeztJNRKoV4IcxK8zuv99yt1oMz7I4xpAfWx8QuRUUHF7 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CMAgBTsPJV/xbLJq1dg3dpgyq5EHgBDYF4gkOCV18CggoUAQEBAQEBAYEKhCMBAQEDAR0GDwEFQAEQCw4HAwICBRYLAgIJAwIBAgFFBgEMCAEBF4gLCA23IpQhAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EihVGEfYUNB4JpgUMFhy6Gd4cxhQqCbYUDgUxGhmojjW6DbB8BAUKCDR+BVT00ih4BAQE
X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="611540409"
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; 11 Sep 2015 10:48:41 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8BAme4d013489; Fri, 11 Sep 2015 10:48:40 GMT
To: Nadeau Thomas , netmod WG 
References: <25E74703-B15C-4CE1-8FE3-A35EE875507B@lucidvision.com>
From: Robert Wilton 
Message-ID: <55F2B187.5030604@cisco.com>
Date: Fri, 11 Sep 2015 11:48:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <25E74703-B15C-4CE1-8FE3-A35EE875507B@lucidvision.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: Re: [netmod] Consensus Call Note for Requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 10:48:45 -0000

Hi Kent, Tom,

I don't really want to slow down the consensus process, but after the 
discussion there are a couple of requirements that are not absolutely 
clear to me.  [Sorry for not raising them in the meeting yesterday, but 
we had already spent a lot of time discussing the requirements and I 
also think that you understandably went through the options quite fast 
at the end].

On 10/09/2015 21:44, Nadeau Thomas wrote:
> 	This is an official NETMOD working group call for consensus around the requirements referenced
> below and discussed in detail at the interim meeting held Thursday, September 10, 2015. At that meeting, the
> chairs went over each requirement in detail and called for any objections to each requirement (and sub-requirement). The question that was asked was “Are there any objections to requirement X in general meaning as it is currently written or with minor/editorial changes to how its written?” There were no objections to any of the requirements, as is detailed in the meeting minutes.  However, to confirm these statements the co-chairs are opening this question to the WG for period starting today, Thursday, September 10, 2015 at 5PM EST.  This period will close on Monday, September 14, 2015 at 5PM EST.  If you commented on the list previously, or at the meeting, there is no need to repeat yourself; we have your position on
>
> 	We will make a call of consensus shortly thereafter.
>
> 	For your reference, the requirements can be found at this URL:
>
> http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements
>
> 	but I will paste them into this message explicitly to be complete.
>
> 	—Tom (as co-chair)
>
>
>
> Terminology
>
> From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>
>    In order to understand the way in which a network operator or network
>    management system may need to interact with a device, it is key to
>    understand the different types of data that network elements may
>    store or master:
>
>    o  intended configuration - this data represents the state that the
>       network operator intends the system to be in.  This data is
>       colloquially referred to as the 'configuration' of the system.
>
>    o  applied configuration - this data represents the state that the
>       network element is actually in, i.e., that which is currently
>       being run by particular software modules (e.g., the BGP daemon),
>       or other systems within the device (e.g., a secondary control-
>       plane, or line card).
>
>    o  derived state - this data represents information which is
>       generated as part of the system's own interactions.  For example,
>       derived state may consist of the results of protocol interactions
>       (the negotiated duplex state of an Ethernet link), statistics
>       (such as message queue depth), or counters (such as packet input
>       or output bytes).
>
>
>
> 1. Ability to interact with both intended and applied configuration
>
>    a. The ability to ask the operational components of a system
>        (e.g., line cards) for the configuration that they are currently
>        using. This is the "applied configuration".
>
>    b. applied configuration is read-only
>
>    c. The data model for the applied configuration is the same as
>        the data model for the intended configuration (same leaves)
>
>    d. For asynchronous systems, when fully synchronized, the data
>        in the applied configuration is the same as the data in the
>        intended configuration.
- I think that it would be useful to define what full synchronized 
means.  In this context, I think of it as meaning if none of the 
configuration failed to be applied for any reason (e.g. due to absence 
of hardware, or internal system error).

- Separately, this isn't specified in the openconfig-netmod-opstate 
draft, but is there any requirement to indicate why an intended cfg node 
isn't in the applied cfg?  In the solution that I've proposed, I've 
assumed that there is.  It would be good to get clarification on whether 
it is a genuine valid requirement or not.

>
> 2. Applied configuration as part of operational state
>
>     a. the ability to retrieve the applied configuration and
>         derived state nodes in a single protocol operation.
>
>
> 3. Support for both transactional, synchronous management
>    systems as well as distributed, asynchronous management
>    systems
>
>     a. For asynchronous systems, the ability to request a protocol
>         operation to not return (i.e. block) until the intended
>         configuration has been fully synchronized.
I'm not sure why 3 (a) is a requirement, or its unclear to me where this 
is specified in the openconfig-netmod-opstate draft.

Thanks,
Rob


From nobody Fri Sep 11 05:09:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC781B4A5E for ; Fri, 11 Sep 2015 05:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pwwwj1sIkwos for ; Fri, 11 Sep 2015 05:09:42 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 951201B4A67 for ; Fri, 11 Sep 2015 05:09:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1441973307; bh=8lj+YLX7VrvKXBpcg68z8a+/FLyVRZIBiS+/nEsO6Lk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=0RATUeYB43hMxy+XdFoR0B4+RoMZODj7vMOx8R8c6dL9SAy9S78A0B/ixa5/rZFj1 xoRkIhlBQe9fJAMZ2M0nydfaXbzrFbQCb2laXNQ4nH+mR4B1QoWdDjQYCojk1Asn9h +nckTFBkwiFJTItgLDhJRhgYxqMwZsrAVo9JzDNI=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <55F2B187.5030604@cisco.com>
Date: Fri, 11 Sep 2015 08:09:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6BE85265-0E47-4DED-A92D-B11A6FDDD08B@lucidvision.com>
References: <25E74703-B15C-4CE1-8FE3-A35EE875507B@lucidvision.com> <55F2B187.5030604@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 119, in=1591, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod-chairs@tools.ietf.org, netmod WG 
Subject: Re: [netmod] Consensus Call Note for Requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 12:09:45 -0000

> On Sep 11, 2015:6:48 AM, at 6:48 AM, Robert Wilton  =
wrote:
>=20
> Hi Kent, Tom,
>=20
> I don't really want to slow down the consensus process, but after the =
discussion there are a couple of requirements that are not absolutely =
clear to me.  [Sorry for not raising them in the meeting yesterday, but =
we had already spent a lot of time discussing the requirements and I =
also think that you understandably went through the options quite fast =
at the end].
>=20
> On 10/09/2015 21:44, Nadeau Thomas wrote:
>> 	This is an official NETMOD working group call for consensus =
around the requirements referenced
>> below and discussed in detail at the interim meeting held Thursday, =
September 10, 2015. At that meeting, the
>> chairs went over each requirement in detail and called for any =
objections to each requirement (and sub-requirement). The question that =
was asked was =E2=80=9CAre there any objections to requirement X in =
general meaning as it is currently written or with minor/editorial =
changes to how its written?=E2=80=9D There were no objections to any of =
the requirements, as is detailed in the meeting minutes.  However, to =
confirm these statements the co-chairs are opening this question to the =
WG for period starting today, Thursday, September 10, 2015 at 5PM EST.  =
This period will close on Monday, September 14, 2015 at 5PM EST.  If you =
commented on the list previously, or at the meeting, there is no need to =
repeat yourself; we have your position on
>>=20
>> 	We will make a call of consensus shortly thereafter.
>>=20
>> 	For your reference, the requirements can be found at this URL:
>>=20
>> http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements
>>=20
>> 	but I will paste them into this message explicitly to be =
complete.
>>=20
>> 	=E2=80=94Tom (as co-chair)
>>=20
>>=20
>>=20
>> Terminology
>>=20
>> From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>>=20
>>   In order to understand the way in which a network operator or =
network
>>   management system may need to interact with a device, it is key to
>>   understand the different types of data that network elements may
>>   store or master:
>>=20
>>   o  intended configuration - this data represents the state that the
>>      network operator intends the system to be in.  This data is
>>      colloquially referred to as the 'configuration' of the system.
>>=20
>>   o  applied configuration - this data represents the state that the
>>      network element is actually in, i.e., that which is currently
>>      being run by particular software modules (e.g., the BGP daemon),
>>      or other systems within the device (e.g., a secondary control-
>>      plane, or line card).
>>=20
>>   o  derived state - this data represents information which is
>>      generated as part of the system's own interactions.  For =
example,
>>      derived state may consist of the results of protocol =
interactions
>>      (the negotiated duplex state of an Ethernet link), statistics
>>      (such as message queue depth), or counters (such as packet input
>>      or output bytes).
>>=20
>>=20
>>=20
>> 1. Ability to interact with both intended and applied configuration
>>=20
>>   a. The ability to ask the operational components of a system
>>       (e.g., line cards) for the configuration that they are =
currently
>>       using. This is the "applied configuration".
>>=20
>>   b. applied configuration is read-only
>>=20
>>   c. The data model for the applied configuration is the same as
>>       the data model for the intended configuration (same leaves)
>>=20
>>   d. For asynchronous systems, when fully synchronized, the data
>>       in the applied configuration is the same as the data in the
>>       intended configuration.
> - I think that it would be useful to define what full synchronized =
means.  In this context, I think of it as meaning if none of the =
configuration failed to be applied for any reason (e.g. due to absence =
of hardware, or internal system error).
>=20
> - Separately, this isn't specified in the openconfig-netmod-opstate =
draft, but is there any requirement to indicate why an intended cfg node =
isn't in the applied cfg?  In the solution that I've proposed, I've =
assumed that there is.  It would be good to get clarification on whether =
it is a genuine valid requirement or not.
>=20
>>=20
>> 2. Applied configuration as part of operational state
>>=20
>>    a. the ability to retrieve the applied configuration and
>>        derived state nodes in a single protocol operation.
>>=20
>>=20
>> 3. Support for both transactional, synchronous management
>>   systems as well as distributed, asynchronous management
>>   systems
>>=20
>>    a. For asynchronous systems, the ability to request a protocol
>>        operation to not return (i.e. block) until the intended
>>        configuration has been fully synchronized.
> I'm not sure why 3 (a) is a requirement, or its unclear to me where =
this is specified in the openconfig-netmod-opstate draft.

	Anees/Rob, can you guys please add some color to the above =
descriptions to help clarify things for Robert?

	=E2=80=94Tom


>=20
> Thanks,
> Rob
>=20


From nobody Fri Sep 11 06:29:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD67A1B2EA4 for ; Fri, 11 Sep 2015 06:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTBA27Lgey_c for ; Fri, 11 Sep 2015 06:29:18 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 110CF1B2DFE for ; Fri, 11 Sep 2015 06:29:17 -0700 (PDT)
Received: (qmail 18703 invoked by uid 0); 11 Sep 2015 13:29:15 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 11 Sep 2015 13:29:15 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id FpV61r01A2SSUrH01pV91H; Fri, 11 Sep 2015 07:29:14 -0600
X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=zYmfZQLjFTOujMHk0jIA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=FaGfcWtDJX1rrVu/ElFugeUYY+3IDTqWnL5H/u3tMzI=;  b=etvjKxCiHnht/c5P/MC9qZw5d2It4vZ2tMBRcuBYgCxmSjpXVw6Fg62mtD9k1nygo6IDADHkBG++QHnm5vqYSqLP5TPcofBX/qiwceXVy+W8FTi7wNcqM87QVaUB0sSz;
Received: from box313.bluehost.com ([69.89.31.113]:40854 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZaOO3-0001Dn-GW; Fri, 11 Sep 2015 07:29:07 -0600
To: Nadeau Thomas , Robert Wilton 
References: <25E74703-B15C-4CE1-8FE3-A35EE875507B@lucidvision.com> <55F2B187.5030604@cisco.com> <6BE85265-0E47-4DED-A92D-B11A6FDDD08B@lucidvision.com>
From: Lou Berger 
Message-ID: <55F2D71B.4050303@labn.net>
Date: Fri, 11 Sep 2015 09:28:59 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <6BE85265-0E47-4DED-A92D-B11A6FDDD08B@lucidvision.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: netmod-chairs@tools.ietf.org, netmod WG 
Subject: Re: [netmod] Consensus Call Note for Requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 13:29:20 -0000

On 9/11/2015 8:09 AM, Nadeau Thomas wrote:
>>> 3. Support for both transactional, synchronous management
>>> >>   systems as well as distributed, asynchronous management
>>> >>   systems
>>> >> 
>>> >>    a. For asynchronous systems, the ability to request a protocol
>>> >>        operation to not return (i.e. block) until the intended
>>> >>        configuration has been fully synchronized.
>> > I'm not sure why 3 (a) is a requirement, or its unclear to me where this is specified in the openconfig-netmod-opstate draft.
> 	Anees/Rob, can you guys please add some color to the above descriptions to help clarify things for Robert?
I see (3) but not (3.a) in
http://tools.ietf.org/html/draft-openconfig-netmod-opstate-01#section-4.2
so am unsure how 3.a made it on the list.

also, I don't object to 3.a if *users* say they need it.

Lou


From nobody Fri Sep 11 07:32:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5E11B4989 for ; Fri, 11 Sep 2015 07:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0EIqE65VMsP for ; Fri, 11 Sep 2015 07:32:12 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEFB1B4067 for ; Fri, 11 Sep 2015 07:32:12 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BEFF41CC0181; Fri, 11 Sep 2015 16:32:12 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: <20150909091440.GA34260@elstar.local>
References: <20150909091440.GA34260@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 11 Sep 2015 16:32:11 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] minutes of the NETMOD 2015-09-07 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 14:32:17 -0000

Juergen Schoenwaelder  writes:
> * Data tree ordering (Lada)
>
>   LL: Is the data tree fundamentally unordered?
>   MB: Yes, the ordering is in the encoding parts.
>   
>   Action: LL to check whether his comments have been resolved in the
>           svn version.
> 	

The definition of "data tree" is OK, and the text about document order
in sec. 6.4 (XPath Evaluations) is IMO sufficient.

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 11 09:42:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B321B4C14 for ; Fri, 11 Sep 2015 09:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmz_38zUAHAy for ; Fri, 11 Sep 2015 09:42:36 -0700 (PDT)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 23EAC1B3500 for ; Fri, 11 Sep 2015 09:42:36 -0700 (PDT)
Received: by lamp12 with SMTP id p12so50748528lam.0 for ; Fri, 11 Sep 2015 09:42:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v/tgHBeSesuvdyXqD6ZmVH4VTUMsMccDq17sWG6T3h8=; b=G8CbEFKPp62wmPMLtDS/VmYQR+RGMf9YldlIF5uAQW6m1I1JTlEwrB1qEQk5Bqqw/O JKDSyywwGlXv/stSCfMmjUhiYImmm1lMcOCirQgGP3gUf1Kbams22WmgK55oSufVPXab b9Oy3OwIfz1iAlssh54CQLvc+HJKxEHMqBg/zVZhKzfvTCf8Akw0NkwOexlBcDYLOe60 qXv8A6b50mYYrusdMrCZ9Oam9QFK1lqguH85ge7Q/bGZWXY14Tpg8H0K/KZjRmYoLKPE dofd6bcgcnSpjyx8jvAvZuEpOZi8cVIGDyphgD064B/wCcjso8tPdkugtxnsvKupcsxh fRIg==
X-Gm-Message-State: ALoCoQm19zzJYmFBaAl2FSnIzCL+P/IoJlvQRpXz7Wxt55bjrS80Wq0CYPVL8SK4Z6NEGFgsxqhc
MIME-Version: 1.0
X-Received: by 10.152.6.133 with SMTP id b5mr42842704laa.33.1441989754333; Fri, 11 Sep 2015 09:42:34 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Fri, 11 Sep 2015 09:42:34 -0700 (PDT)
In-Reply-To: <20150911.093846.709202940600841233.mbj@tail-f.com>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>
Date: Fri, 11 Sep 2015 09:42:34 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=089e01493fa813c8d2051f7b67b9
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 16:42:40 -0000

--089e01493fa813c8d2051f7b67b9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund  wrote:

> Sam Aldrin  wrote:
> >
> > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> > >  wrote:
> > >
> > >
> > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> > >> > wrote:
> > >>
> > >> Now, think about configuration parameters that have applied
> > >> configuration located in more than one place. Let=E2=80=99s say you =
change the
> > >> IP address of an interface, it is likely that this configuration wil=
l
> > >> be passed around as input to a handful of subsystems (e.g. the DHCP
> > >> server, some routing daemons that may bind to specific IP
> > >> addresses). Is the intended and applied in sync when a specific subs=
et
> > >> of those configurations are updated. What happens if there=E2=80=99s=
 a partial
> > >> failure?
> > >
> > > This is a good example. Another example, and somebody on the call
> > > today started to ask this but got cut off, relates to interfaces on
> > > the device.
> > >
> > > Interfaces already exist on a system. As such they have a
> > > configuration (default values) that exists on them. They are enabled
> > > when configuration gets applied on them. They will have applied
> > > configuration but no intended configuration. Should this be reported?
> > >
> > > Yet another example is of a BFD session that gets bootstrapped becaus=
e
> > > of a ping. There is no intended configuration, but the session exists
> > > and a query of configuration in this case would return a valid BFD
> > > session.
> > >
> > > Could we get some clarification (with examples, preferably) on what
> > > the expectation is from a openconfig opstate perspective?
> >
> > Section 7 of draft-openconfig-netmod-opstate talks about
> > that. Specifically, #3 talks about the interface question you raise..
>
> I think it is important that we understand how this 'applied config'
> is supposed to be populated on a device.
>
> First it was said that it there is just one way they can be different;
> time (on async systems).  After some discussion I think there are now
> four ways:
>
>

IMO it would help to think just a bit about the operational aspects
of these issues.

There are at least 2 outcomes I can think of:

  Outcome 1) Convergence:
  Intended config eventually matches Applied

  Outcome 2) Non-convergence:
  Intended config is not going to become Applied

A system needs to decide if/when outcome 2 has occurred.
When is a fault raised because convergence is not happening?
There are probably other uses for all this extra meta-data.

So how do these 4 types of differences relate to these outcomes?

  1.  Time (in async systems).
>

Obviously the main use-case.
Nothing in any solution proposal helps the client  decide Outcome 2 has
occurred.
That is out of scope I guess.

For most systems, this time delta will be too short to worry about ( < 5
sec.)
A good solution would not impact this vast majority of servers.




>   2.  Hardware.  If something is in intended config but there is no hw
>       present, it is not in applied.
>

This is usually handled with a notification that the line-card was plugged
in, which
causes the NMS to re-check the config.  The solution proposal assumes the
server
can identify all the resources or other reasons that some specific leaf is
not applied yet.
This seems very complicated to implement in the server.



>   3.  System-controlled stuff.  If the system auto-creates an
>       interface (for example), it will be in the applied config but
>       not in intended.
>


There is no convergence here because this is a case where applied has more
than intended,
not the other way around.



>   4.  "Template substitution"; the draft uses the example of an 'all'
>       interface that exists in intended config but not in applied.
>
>
There is no convergence here because the template is not supposed to show
up in Applied.
However it is worth noting than none of the proposals solve this problem.
The Intended and Applied will never match.  The NMS must understand
how the specific template works to know what actual instances are expected
in Applied.



>
> Then Lada brought up the example of ip addresses.  It was mentioned
> on the call that for ip addresses there would be three lists; one for
> intended, one for applied, and one in derived state, where the one in
> derived state is what the box *really* uses.  So for example if it
> gets an ip from dhcp, it will be in the derived state list, but not in
> applied config.
>
> Why is this ip-address list different from the interface list?  Why
> was it enough with two lists for interfaces, but we need three for ip
> addresses?
>
>
> /martin
>


Andy


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

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




On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Sam Aldrin <aldrin.ietf@gmail.com> wrote:

>

> > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani

> > <mjethanandani@gmai=
l.com> wrote:

> >

> >

> >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)

> >> <camoberg@cisco.com<=
/a> <mailto:camoberg@cisco.com=
>> wrote:

> >>

> >> Now, think about configuration parameters that have applied
> >> configuration located in more than one place. Let=E2=80=99s s=
ay you change the

> >> IP address of an interface, it is likely that this configurat=
ion will

> >> be passed around as input to a handful of subsystems (e.g. th=
e DHCP

> >> server, some routing daemons that may bind to specific IP

> >> addresses). Is the intended and applied in sync when a specif=
ic subset

> >> of those configurations are updated. What happens if there=E2=
=80=99s a partial

> >> failure?

> >

> > This is a good example. Another example, and somebody on the call=


> > today started to ask this but got cut off, relates to interfaces =
on

> > the device.

> >

> > Interfaces already exist on a system. As such they have a

> > configuration (default values) that exists on them. They are enab=
led

> > when configuration gets applied on them. They will have applied
> > configuration but no intended configuration. Should this be repor=
ted?

> >

> > Yet another example is of a BFD session that gets bootstrapped be=
cause

> > of a ping. There is no intended configuration, but the session ex=
ists

> > and a query of configuration in this case would return a valid BF=
D

> > session.

> >

> > Could we get some clarification (with examples, preferably) on wh=
at

> > the expectation is from a openconfig opstate perspective?

>

> Section 7 of draft-openconfig-netmod-opstate talks about

> that. Specifically, #3 talks about the interface question you raise..<=
br>


I think it is important that we understand how this 'applied config'=
;

is supposed to be populated on a device.



First it was said that it there is just one way they can be different;

time (on async systems).=C2=A0 After some discussion I think there are now<=
br>
four ways:




IMO it would help to th=
ink just a bit about the operational aspects
of these issues.

There are at least 2 outcomes I can think of:

=C2=A0 Outcome 1) Convergence:=C2=A0
=C2=A0 Int=
ended config eventually matches Applied

=C2=A0 Out=
come 2) Non-convergence:
=C2=A0 Intended config is not going to b=
ecome Applied

A system needs to decide if/when out=
come 2 has occurred.
When is a fault raised because convergence i=
s not happening?
There are probably other uses for all this extra=
 meta-data.

So how do these 4 types of differences=
 relate to these outcomes?


=C2=A0 1.=C2=A0 Time (in async systems).

Obviously the main use-case.
Nothing in any solution proposal h=
elps the client =C2=A0decide Outcome 2 has occurred.
That is out =
of scope I guess.

For most systems, this time delt=
a will be too short to worry about ( < 5 sec.)
A good solution=
 would not impact this vast majority of servers.

<=
br>




=C2=A0 2.=C2=A0 Hardware.=C2=A0 If something is in intended config but ther=
e is no hw

=C2=A0 =C2=A0 =C2=A0 present, it is not in applied.
This is usually handled with a notification that the line-card=
 was plugged in, which
causes the NMS to re-check the config.=C2=
=A0 The solution proposal assumes the server
can identify all the=
 resources or other reasons that some specific leaf is not applied yet.
This seems very complicated to implement in the server.




=C2=A0 3.=C2=A0 System-controlled stuff.=C2=A0 If the system auto-creates a=
n

=C2=A0 =C2=A0 =C2=A0 interface (for example), it will be in the applied con=
fig but

=C2=A0 =C2=A0 =C2=A0 not in intended.

<=
br>
There is no convergence here because this is a case where app=
lied has more than intended,
not the other way around.
=





=C2=A0 4.=C2=A0 "Template substitution"; the draft uses the examp=
le of an 'all'

=C2=A0 =C2=A0 =C2=A0 interface that exists in intended config but not in ap=
plied.



There is no convergence here because t=
he template is not supposed to show up in Applied.
However it is =
worth noting than none of the proposals solve this problem.
The I=
ntended and Applied will never match.=C2=A0 The NMS must understand
how the specific template works to know what actual instances are expect=
ed in Applied.

=C2=A0



Then Lada brought up the example of ip addresses.=C2=A0 It was mentioned
on the call that for ip addresses there would be three lists; one for

intended, one for applied, and one in derived state, where the one in

derived state is what the box *really* uses.=C2=A0 So for example if it

gets an ip from dhcp, it will be in the derived state list, but not in

applied config.



Why is this ip-address list different from the interface list?=C2=A0 Why
was it enough with two lists for interfaces, but we need three for ip

addresses?





/martin


Andy
=
=C2=A0

_______________________________________________

netmod mailing list

netmod@ietf.org

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





--089e01493fa813c8d2051f7b67b9--


From nobody Fri Sep 11 14:52:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EC51B4273 for ; Fri, 11 Sep 2015 14:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lDzkPMjI73y for ; Fri, 11 Sep 2015 14:52:15 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 259241B4249 for ; Fri, 11 Sep 2015 14:52:15 -0700 (PDT)
Received: by padhy16 with SMTP id hy16so85455314pad.1 for ; Fri, 11 Sep 2015 14:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=54iQOz/m2mWvCVPLUw4XleA9g0NxWeaPsOpHv0nnjWY=; b=E+MsR1IL0CbG+aJWfU42sUxdq2SkGTXV2Dc3eKZEh0bRVoqwvaPpupqXQlvQ8u6t1Y ero9M63tFRym1L5WW87dIsw70KjRIeHz97EKkQ0zx7XTc3+kAEdQEIGMyeUqlesCUsmp DPDGYi6o014aMbbjRxidjI54qjvJ14mdBCpPlLQ7X25mF4GKUdplUpIEo8AaeT/dmH8q AAj3Ng2FSMkyaJGLjoj1HL+DTBzvwmQkAd54Vbc8olyZzt8cd1BmJagof1MvAs1QNSNM 4h/LbS37a4ermHCdom6Ki2pA1M+8dILdEQs1Joze8GV3itGNLKKT9oqitKg7bsttQJxr UtTQ==
X-Received: by 10.66.221.68 with SMTP id qc4mr2168283pac.26.1442008334718; Fri, 11 Sep 2015 14:52:14 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1005::6ce? ([2001:420:c0c8:1005::6ce]) by smtp.gmail.com with ESMTPSA id ga1sm2142289pbb.80.2015.09.11.14.52.12 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Sep 2015 14:52:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AE8AE02E-0CA7-4CB5-ABDE-55C6FF15D486"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Fri, 11 Sep 2015 14:52:11 -0700
Message-Id: <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 21:52:20 -0000

--Apple-Mail=_AE8AE02E-0CA7-4CB5-ABDE-55C6FF15D486
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

And while we mull over the questions Andy has raised, I want to go back =
and dwell on what Rob said about why he wanted a way to determine when =
the configuration has taken effect. I might be simplifying the problem a =
little too much, but I am sure Rob will correct me. The ask as I =
understand is, give me a way to deterministically know when a given =
piece of configuration has taken effect.

As an exercise I wanted to mentally go through trying to configure an =
interface to determine if the configuration has taken effect. Very =
simply, I want to assign an IP address to an interface. If I now want to =
know if this configuration has taken effect, I can check for the IP =
address of the interface. Querying the IP address on an interface does =
not tell me if it has taken effect. Yes, it has been written to a =
register, but what does that tell me? Nothing. My only deterministic way =
of knowing that the IP address has taken effect is if I can see traffic =
transmitted/received with that IP address on that interface.

To me that is the crux of the problem with simply reflecting operational =
status with a flag that gets updated when the configuration gets =
written. In most cases, the configuration will just work and the flag =
will tell me nothing new. But when it does not, having written to a flag =
will also tell me nothing, other than the fact that the configuration =
was written.

I contend that the real ask with this example is to determine if I can =
pass IP traffic, and to determine that, we need more than a =E2=80=9Cinten=
ded vs actual=E2=80=9D flag.

> On Sep 11, 2015, at 9:42 AM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund > wrote:
> Sam Aldrin > =
wrote:
> >
> > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> > > > wrote:
> > >
> > >
> > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> > >>  =
>> wrote:
> > >>
> > >> Now, think about configuration parameters that have applied
> > >> configuration located in more than one place. Let=E2=80=99s say =
you change the
> > >> IP address of an interface, it is likely that this configuration =
will
> > >> be passed around as input to a handful of subsystems (e.g. the =
DHCP
> > >> server, some routing daemons that may bind to specific IP
> > >> addresses). Is the intended and applied in sync when a specific =
subset
> > >> of those configurations are updated. What happens if there=E2=80=99=
s a partial
> > >> failure?
> > >
> > > This is a good example. Another example, and somebody on the call
> > > today started to ask this but got cut off, relates to interfaces =
on
> > > the device.
> > >
> > > Interfaces already exist on a system. As such they have a
> > > configuration (default values) that exists on them. They are =
enabled
> > > when configuration gets applied on them. They will have applied
> > > configuration but no intended configuration. Should this be =
reported?
> > >
> > > Yet another example is of a BFD session that gets bootstrapped =
because
> > > of a ping. There is no intended configuration, but the session =
exists
> > > and a query of configuration in this case would return a valid BFD
> > > session.
> > >
> > > Could we get some clarification (with examples, preferably) on =
what
> > > the expectation is from a openconfig opstate perspective?
> >
> > Section 7 of draft-openconfig-netmod-opstate talks about
> > that. Specifically, #3 talks about the interface question you =
raise..
>=20
> I think it is important that we understand how this 'applied config'
> is supposed to be populated on a device.
>=20
> First it was said that it there is just one way they can be different;
> time (on async systems).  After some discussion I think there are now
> four ways:
>=20
>=20
>=20
> IMO it would help to think just a bit about the operational aspects
> of these issues.
>=20
> There are at least 2 outcomes I can think of:
>=20
>   Outcome 1) Convergence:=20
>   Intended config eventually matches Applied
>=20
>   Outcome 2) Non-convergence:
>   Intended config is not going to become Applied
>=20
> A system needs to decide if/when outcome 2 has occurred.
> When is a fault raised because convergence is not happening?
> There are probably other uses for all this extra meta-data.
>=20
> So how do these 4 types of differences relate to these outcomes?
>=20
>   1.  Time (in async systems).
>=20
> Obviously the main use-case.
> Nothing in any solution proposal helps the client  decide Outcome 2 =
has occurred.
> That is out of scope I guess.
>=20
> For most systems, this time delta will be too short to worry about ( < =
5 sec.)
> A good solution would not impact this vast majority of servers.
>=20
>=20
>=20
>=20
>   2.  Hardware.  If something is in intended config but there is no hw
>       present, it is not in applied.
>=20
> This is usually handled with a notification that the line-card was =
plugged in, which
> causes the NMS to re-check the config.  The solution proposal assumes =
the server
> can identify all the resources or other reasons that some specific =
leaf is not applied yet.
> This seems very complicated to implement in the server.
>=20
>=20
>=20
>   3.  System-controlled stuff.  If the system auto-creates an
>       interface (for example), it will be in the applied config but
>       not in intended.
>=20
>=20
> There is no convergence here because this is a case where applied has =
more than intended,
> not the other way around.
>=20
>=20
>=20
>   4.  "Template substitution"; the draft uses the example of an 'all'
>       interface that exists in intended config but not in applied.
>=20
>=20
> There is no convergence here because the template is not supposed to =
show up in Applied.
> However it is worth noting than none of the proposals solve this =
problem.
> The Intended and Applied will never match.  The NMS must understand
> how the specific template works to know what actual instances are =
expected in Applied.
>=20
> =20
>=20
> Then Lada brought up the example of ip addresses.  It was mentioned
> on the call that for ip addresses there would be three lists; one for
> intended, one for applied, and one in derived state, where the one in
> derived state is what the box *really* uses.  So for example if it
> gets an ip from dhcp, it will be in the derived state list, but not in
> applied config.
>=20
> Why is this ip-address list different from the interface list?  Why
> was it enough with two lists for interfaces, but we need three for ip
> addresses?
>=20
>=20
> /martin
>=20
>=20
> Andy
> =20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_AE8AE02E-0CA7-4CB5-ABDE-55C6FF15D486
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

And while we mull over the questions Andy has raised, I want =
to go back and dwell on what Rob said about why he wanted a way to =
determine when the configuration has taken effect. I might be =
simplifying the problem a little too much, but I am sure Rob will =
correct me. The ask as I understand is, give me a way to =
deterministically know when a given piece of configuration has taken =
effect.

As an exercise I wanted to mentally go =
through trying to configure an interface to determine if the =
configuration has taken effect. Very simply, I want to assign an IP =
address to an interface. If I now want to know if this configuration has =
taken effect, I can check for the IP address of the interface. Querying =
the IP address on an interface does not tell me if it has taken effect. =
Yes, it has been written to a register, but what does that tell me? =
Nothing. My only deterministic way of knowing that the IP address has =
taken effect is if I can see traffic transmitted/received with that IP =
address on that interface.

To me that is the crux of the problem with simply reflecting =
operational status with a flag that gets updated when the configuration =
gets written. In most cases, the configuration will just work and the =
flag will tell me nothing new. But when it does not, having written to a =
flag will also tell me nothing, other than the fact that the =
configuration was written.

I contend that the real ask with this example is to determine =
if I can pass IP traffic, and to determine that, we need more than a =
=E2=80=9Cintended vs actual=E2=80=9D flag.

On Sep 11, 2015, at 9:42 AM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Fri, Sep 11, 2015 at 12:38 AM, Martin =
Bjorklund <mbj@tail-f.com> wrote:
Sam Aldrin <aldrin.ietf@gmail.com> wrote:
>
> > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> > <mjethanandani@gmail.com> wrote:
> =
>
> >
> >> On Sep 10, =
2015, at 12:43 PM, Carl Moberg (camoberg)
> >> =
<camoberg@cisco.com <mailto:camoberg@cisco.com>> wrote:
> =
>>
> >> Now, think about configuration =
parameters that have applied
> >> configuration =
located in more than one place. Let=E2=80=99s say you change the
> >> IP address of an interface, it is likely that =
this configuration will
> >> be passed around as =
input to a handful of subsystems (e.g. the DHCP
> =
>> server, some routing daemons that may bind to specific IP
> >> addresses). Is the intended and applied in sync =
when a specific subset
> >> of those =
configurations are updated. What happens if there=E2=80=99s a partial
> >> failure?
> >
> > This is a good example. Another example, and =
somebody on the call
> > today started to ask this =
but got cut off, relates to interfaces on
> > the =
device.
> >
> > Interfaces =
already exist on a system. As such they have a
> > =
configuration (default values) that exists on them. They are enabled
> > when configuration gets applied on them. They will =
have applied
> > configuration but no intended =
configuration. Should this be reported?
> >
> > Yet another example is of a BFD session that gets =
bootstrapped because
> > of a ping. There is no =
intended configuration, but the session exists
> > =
and a query of configuration in this case would return a valid BFD
> > session.
> >
> =
> Could we get some clarification (with examples, preferably) on =
what
> > the expectation is from a openconfig =
opstate perspective?
>
> Section 7 of =
draft-openconfig-netmod-opstate talks about
> that. =
Specifically, #3 talks about the interface question you raise..

I think it is important that we understand how =
this 'applied config'
is supposed to be populated on a =
device.

First it was said that it there is =
just one way they can be different;
time (on async =
systems).  After some discussion I think there are now
four ways:



IMO it would help to think just a bit about the operational =
aspects
of these issues.

There are at least 2 outcomes I can =
think of:

 =
 Outcome 1) Convergence: 
  Intended =
config eventually matches Applied

  Outcome 2) =
Non-convergence:
  Intended config is not =
going to become Applied

A system needs to decide if/when outcome 2 has =
occurred.
When is a fault raised because =
convergence is not happening?
There are probably =
other uses for all this extra meta-data.

So how do these 4 types of differences =
relate to these outcomes?

  1.  Time (in async =
systems).

Obviously the main use-case.
Nothing in any solution proposal helps the client =
 decide Outcome 2 has occurred.
That is out of =
scope I guess.

For most systems, this time delta will be too short to worry =
about ( < 5 sec.)
A good solution would not =
impact this vast majority of servers.




  2.  Hardware.  If =
something is in intended config but there is no hw
  =
    present, =
it is not in applied.

This is usually handled with a =
notification that the line-card was plugged in, which
causes the NMS to re-check the config.  The solution =
proposal assumes the server
can identify all the =
resources or other reasons that some specific leaf is not applied =
yet.
This seems very complicated to implement in =
the server.



  3.  System-controlled =
stuff.  If the system auto-creates an
    =
  interface (for =
example), it will be in the applied config but
  =
    not in =
intended.


There is no convergence here because this is a case where =
applied has more than intended,
not the other way =
around.



  4.  "Template =
substitution"; the draft uses the example of an 'all'
 =
     interface=
 that exists in intended config but not in applied.


There is no convergence here because the template is not =
supposed to show up in Applied.
However it is worth =
noting than none of the proposals solve this problem.
The Intended and Applied will never match.  The NMS must =
understand
how the specific template works to know =
what actual instances are expected in Applied.

 

Then Lada =
brought up the example of ip addresses.  It was mentioned
on the call that for ip addresses there would be three lists; =
one for
intended, one for applied, and one in derived =
state, where the one in
derived state is what the box =
*really* uses.  So for example if it
gets an ip from =
dhcp, it will be in the derived state list, but not in
applied config.

Why is this =
ip-address list different from the interface list?  Why
was it enough with two lists for interfaces, but we need =
three for ip
addresses?


/martin


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

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



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_AE8AE02E-0CA7-4CB5-ABDE-55C6FF15D486--


From nobody Fri Sep 11 15:16:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B761B425A for ; Fri, 11 Sep 2015 15:16:47 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFbFLEX2h4Ba for ; Fri, 11 Sep 2015 15:16:45 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4139E1B3FE4 for ; Fri, 11 Sep 2015 15:16:44 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Fri, 11 Sep 2015 22:16:40 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Fri, 11 Sep 2015 22:16:40 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
Thread-Index: AQHQ7NnysQc/svWyUEyF7cDHm/QsQ543okqA
Date: Fri, 11 Sep 2015 22:16:40 +0000
Message-ID: 
References: <20150911213636.11309.79529.idtracker@ietfa.amsl.com>
In-Reply-To: <20150911213636.11309.79529.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:uYkpwoptGH/2xKTBdsUe3AMaBs/OjJB5s0gslHdhMychqRRpYUkxfSnRnMRCGr693tmBr3Rptq6Z9vcwr/0FAFOf52wMDpkrxSsDfMD6M+F6s7vFP2/gLIoWjmowz/EXw9z/OWGx3frSqj4B5MgvDQ==; 24:eByZXJDgunnoMPXbTxJ7TtajDPYJQKGWNUkjBCavX+jN6t7Na5d+GHb2E5i6aHoI6jNjvgHDN+2gaMss67gpuqhiy9fBR7dPskyHCWDe68Y=; 20:aF1cCABzZncSXnJnbTS0JMMqlHJiDWUN+nLVXf+hcqfcYItkLR+l5EhmT8oZQZwsFr6sUn6N/KN35rAB7wa2GQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 06968FD8C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(479174004)(377454003)(189002)(377424004)(164054003)(450100001)(76176999)(81156007)(50986999)(101416001)(54356999)(64706001)(62966003)(5001960100002)(40100003)(77156002)(4001540100001)(122556002)(97736004)(83506001)(5001860100001)(107886002)(87936001)(110136002)(189998001)(2950100001)(230783001)(36756003)(4001350100001)(2501003)(5002640100001)(2351001)(106116001)(19580395003)(19580405001)(99286002)(5007970100001)(15975445007)(46102003)(68736005)(92566002)(11100500001)(105586002)(102836002)(86362001)(10400500002)(66066001)(5001830100001)(2900100001)(106356001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2015 22:16:40.4412 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Sep 2015 22:16:47 -0000

The AD and chairs thought it best to formalize the consensus on the
requirements a bit more.  So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

	https://github.com/netmod-wg/opstate-reqs/issues

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so.   Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom


On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" 
wrote:

>
>A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>has been successfully submitted by Kent Watsen and posted to the
>IETF repository.
>
>Name:		draft-chairs-netmod-opstate-reqs
>Revision:	00
>Title:		NETMOD Operational State Requirements
>Document date:	2015-09-11
>Group:		Individual Submission
>Pages:		5
>URL:           =20
>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>xt
>Status:        =20
>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>Htmlized:      =20
>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>
>
>Abstract:
>   This document captures consensus on operational state requirements by
>   the NETMOD working group.
>
>                 =20
>       =20
>
>
>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.
>
>The IETF Secretariat
>


From nobody Fri Sep 11 20:49:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2141A9083 for ; Fri, 11 Sep 2015 20:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM4a0e8j6XW0 for ; Fri, 11 Sep 2015 20:48:58 -0700 (PDT)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 BBF411A907A for ; Fri, 11 Sep 2015 20:48:57 -0700 (PDT)
Received: by lamp12 with SMTP id p12so57732568lam.0 for ; Fri, 11 Sep 2015 20:48:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3Lajn2xiG+XAa72qc0lPBRc4B1EBrCR2mBhHV+ErW9A=; b=g6b6HfkURoLScQMSQDSUiAKQ0ndMic5FW0IVvnNdQdcDH170oQuQj0BHdZKT0BFtlO tbSWGiu3y1TDUf60gQ2hNywBhZm1hqr1euaPfKypTI6hl0AZ5fSk1x2Ku2/3hlEvT/6A GNPpwVPJOgIjjdFaQkjdxCRKZQuvYklQDckZrGqeTd59Y7p81OngrlDS1uwAM2X3FNzd Nmtyi8Ad2Gqblc6xjLjwe5DyK6qNmHs+lJoIX3Vl6MZp+hRfCtbymGRdILPPCfPudNqJ YYbkFTiDIRWqAoymFPNhcTnKzAQYGjWzbK97L1aLialWeQOavjM5ZCdVoZtBra7V516+ nXuA==
X-Gm-Message-State: ALoCoQm6O1CHsyymdb/Ua1nC1ELmOaX7U73GglZmx5GXHmjzJTle9g+wpDbypOXdtXbb0+O6e1iu
MIME-Version: 1.0
X-Received: by 10.152.36.101 with SMTP id p5mr1946403laj.123.1442029735879; Fri, 11 Sep 2015 20:48:55 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Fri, 11 Sep 2015 20:48:55 -0700 (PDT)
In-Reply-To: <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>  <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>
Date: Fri, 11 Sep 2015 20:48:55 -0700
Message-ID: 
From: Andy Bierman 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=089e0158b5bc29c69f051f84b673
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Sep 2015 03:49:02 -0000

--089e0158b5bc29c69f051f84b673
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

The answer (today) is that some operator knows the show commands
to type, and then knows from the screen full of data that certain config
commands
are active.

It's not hard to imagine that how an API to do this without any magic would
be useful.
(Hence the openconfig requirement...)

As Carl pointed out in the interim, current systems do not provide this
level of automation.
All this is new code, and perhaps there are complicated corner-cases to be
found.

All solutions expect the server to be able to determine applied status for
every leaf
in the intended config. All solutions require basically the same internal
API support
to check the relevant applied config or operational state.

In every solution, the server will magically know how to check that the IP
address is active.
That's the point. It is better than forcing the client to know how to do
this for every type of server.

IMO, this requirement is clear, and each draft has a solution approach for
this new API.


Andy

On Fri, Sep 11, 2015 at 2:52 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> And while we mull over the questions Andy has raised, I want to go back
> and dwell on what Rob said about why he wanted a way to determine when th=
e
> configuration has taken effect. I might be simplifying the problem a litt=
le
> too much, but I am sure Rob will correct me. The ask as I understand
> is, give me a way to deterministically know when a given piece of
> configuration has taken effect.
>
> As an exercise I wanted to mentally go through trying to configure an
> interface to determine if the configuration has taken effect. Very simply=
,
> I want to assign an IP address to an interface. If I now want to know if
> this configuration has taken effect, I can check for the IP address of th=
e
> interface. Querying the IP address on an interface does not tell me if it
> has taken effect. Yes, it has been written to a register, but what does
> that tell me? Nothing. My only deterministic way of knowing that the IP
> address has taken effect is if I can see traffic transmitted/received wit=
h
> that IP address on that interface.
>
> To me that is the crux of the problem with simply reflecting operational
> status with a flag that gets updated when the configuration gets written.
> In most cases, the configuration will just work and the flag will tell me
> nothing new. But when it does not, having written to a flag will also tel=
l
> me nothing, other than the fact that the configuration was written.
>
> I contend that the real ask with this example is to determine if I can
> pass IP traffic, and to determine that, we need more than a =E2=80=9Cinte=
nded vs
> actual=E2=80=9D flag.
>
> On Sep 11, 2015, at 9:42 AM, Andy Bierman  wrote:
>
>
>
> On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund  wrote=
:
>
>> Sam Aldrin  wrote:
>> >
>> > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>> > >  wrote:
>> > >
>> > >
>> > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>> > >> > wrote:
>> > >>
>> > >> Now, think about configuration parameters that have applied
>> > >> configuration located in more than one place. Let=E2=80=99s say you=
 change
>> the
>> > >> IP address of an interface, it is likely that this configuration wi=
ll
>> > >> be passed around as input to a handful of subsystems (e.g. the DHCP
>> > >> server, some routing daemons that may bind to specific IP
>> > >> addresses). Is the intended and applied in sync when a specific
>> subset
>> > >> of those configurations are updated. What happens if there=E2=80=99=
s a
>> partial
>> > >> failure?
>> > >
>> > > This is a good example. Another example, and somebody on the call
>> > > today started to ask this but got cut off, relates to interfaces on
>> > > the device.
>> > >
>> > > Interfaces already exist on a system. As such they have a
>> > > configuration (default values) that exists on them. They are enabled
>> > > when configuration gets applied on them. They will have applied
>> > > configuration but no intended configuration. Should this be reported=
?
>> > >
>> > > Yet another example is of a BFD session that gets bootstrapped becau=
se
>> > > of a ping. There is no intended configuration, but the session exist=
s
>> > > and a query of configuration in this case would return a valid BFD
>> > > session.
>> > >
>> > > Could we get some clarification (with examples, preferably) on what
>> > > the expectation is from a openconfig opstate perspective?
>> >
>> > Section 7 of draft-openconfig-netmod-opstate talks about
>> > that. Specifically, #3 talks about the interface question you raise..
>>
>> I think it is important that we understand how this 'applied config'
>> is supposed to be populated on a device.
>>
>> First it was said that it there is just one way they can be different;
>> time (on async systems).  After some discussion I think there are now
>> four ways:
>>
>>
>
> IMO it would help to think just a bit about the operational aspects
> of these issues.
>
> There are at least 2 outcomes I can think of:
>
>   Outcome 1) Convergence:
>   Intended config eventually matches Applied
>
>   Outcome 2) Non-convergence:
>   Intended config is not going to become Applied
>
> A system needs to decide if/when outcome 2 has occurred.
> When is a fault raised because convergence is not happening?
> There are probably other uses for all this extra meta-data.
>
> So how do these 4 types of differences relate to these outcomes?
>
>   1.  Time (in async systems).
>>
>
> Obviously the main use-case.
> Nothing in any solution proposal helps the client  decide Outcome 2 has
> occurred.
> That is out of scope I guess.
>
> For most systems, this time delta will be too short to worry about ( < 5
> sec.)
> A good solution would not impact this vast majority of servers.
>
>
>
>
>>   2.  Hardware.  If something is in intended config but there is no hw
>>       present, it is not in applied.
>>
>
> This is usually handled with a notification that the line-card was plugge=
d
> in, which
> causes the NMS to re-check the config.  The solution proposal assumes the
> server
> can identify all the resources or other reasons that some specific leaf i=
s
> not applied yet.
> This seems very complicated to implement in the server.
>
>
>
>>   3.  System-controlled stuff.  If the system auto-creates an
>>       interface (for example), it will be in the applied config but
>>       not in intended.
>>
>
>
> There is no convergence here because this is a case where applied has mor=
e
> than intended,
> not the other way around.
>
>
>
>>   4.  "Template substitution"; the draft uses the example of an 'all'
>>       interface that exists in intended config but not in applied.
>>
>>
> There is no convergence here because the template is not supposed to show
> up in Applied.
> However it is worth noting than none of the proposals solve this problem.
> The Intended and Applied will never match.  The NMS must understand
> how the specific template works to know what actual instances are expecte=
d
> in Applied.
>
>
>
>>
>> Then Lada brought up the example of ip addresses.  It was mentioned
>> on the call that for ip addresses there would be three lists; one for
>> intended, one for applied, and one in derived state, where the one in
>> derived state is what the box *really* uses.  So for example if it
>> gets an ip from dhcp, it will be in the derived state list, but not in
>> applied config.
>>
>> Why is this ip-address list different from the interface list?  Why
>> was it enough with two lists for interfaces, but we need three for ip
>> addresses?
>>
>>
>> /martin
>>
>
>
> Andy
>
>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
>

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


Hi Mahesh,

The answer (today) is that s=
ome operator knows the show commands
to type, and then knows from=
 the screen full of data that certain config commands
are active.=


It's not hard to imagine that how an API to d=
o this without any magic would be useful.
(Hence the openconfig r=
equirement...)

As Carl pointed out in the interim,=
 current systems do not provide this level of automation.
All thi=
s is new code, and perhaps there are complicated corner-cases to be found.<=
/div>

All solutions expect the server to be able to dete=
rmine applied status for every leaf
in the intended config. All s=
olutions require basically the same internal API support
to check=
 the relevant applied config or operational state.

In every solution, the server will magically know how to check that the IP=
 address is active.
That's the point. It is better than forci=
ng the client to know how to do this for every type of server.
IMO, this requirement is clear, and each draft has a solution =
approach for this new API.


Andy

On Fri, Sep 11, 2015 at 2:52 PM, Mahesh J=
ethanandani <mjethanandani@gmail.com> wrote:
And while we m=
ull over the questions Andy has raised, I want to go back and dwell on what=
 Rob said about why he wanted a way to determine when the configuration has=
 taken effect. I might be simplifying the problem a little too much, but I =
am sure Rob will correct me. The ask as I understand is,=C2=A0give me a way=
 to deterministically know when a given piece of configuration has taken ef=
fect.

As an exercise I wanted to mentally go t=
hrough trying to configure an interface to determine if the configuration h=
as taken effect. Very simply, I want to assign an IP address to an interfac=
e. If I now want to know if this configuration has taken effect, I can chec=
k for the IP address of the interface. Querying the IP address on an interf=
ace does not tell me if it has taken effect. Yes, it has been written to a =
register, but what does that tell me? Nothing. My only deterministic way of=
 knowing that the IP address has taken effect is if I can see traffic trans=
mitted/received with that IP address on that interface.

To me that is the crux of the problem with simply reflecting operatio=
nal status with a flag that gets updated when the configuration gets writte=
n. In most cases, the configuration will just work and the flag will tell m=
e nothing new. But when it does not, having written to a flag will also tel=
l me nothing, other than the fact that the configuration was written.
=


I contend that the real ask with this example is to det=
ermine if I can pass IP traffic, and to determine that, we need more than a=
 =E2=80=9Cintended vs actual=E2=80=9D flag.

On Sep 11, 2015, at 9:42 AM, Andy Bierman <andy@yumaworks.com> wrot=
e:


<=
br>
On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjor=
klund=C2=A0<mbj@tail-f.com>=C2=A0wrot=
e:
Sam Aldrin <aldrin.ietf@gmail.com> wrote:
>
> =
> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> > <mjethanandani@gmai=
l.com> wrote:
> >
> >
> >> On Sep 10, =
2015, at 12:43 PM, Carl Moberg (camoberg)
> >> <camoberg@cisco.com=C2=
=A0<mailto:camoberg@cisco.com>> wrote:
> >>
> >> N=
ow, think about configuration parameters that have applied
> >>=
 configuration located in more than one place. Let=E2=80=99s say you change=
 the
> >> IP address of an interface, it is likely that this co=
nfiguration will
> >> be passed around as input to a handful of=
 subsystems (e.g. the DHCP
> >> server, some routing daemons th=
at may bind to specific IP
> >> addresses). Is the intended and=
 applied in sync when a specific subset
> >> of those configura=
tions are updated. What happens if there=E2=80=99s a partial
> >&g=
t; failure?
> >
> > This is a good example. Another examp=
le, and somebody on the call
> > today started to ask this but got=
 cut off, relates to interfaces on
> > the device.
> >> > Interfaces already exist on a system. As such they have a
>=
; > configuration (default values) that exists on them. They are enabled=

> > when configuration gets applied on them. They will have appli=
ed
> > configuration but no intended configuration. Should this be=
 reported?
> >
> > Yet another example is of a BFD sessio=
n that gets bootstrapped because
> > of a ping. There is no intend=
ed configuration, but the session exists
> > and a query of config=
uration in this case would return a valid BFD
> > session.
>=
 >
> > Could we get some clarification (with examples, preferab=
ly) on what
> > the expectation is from a openconfig opstate persp=
ective?
>
> Section 7 of draft-openconfig-netmod-opstate talks =
about
> that. Specifically, #3 talks about the interface question you=
 raise..

I think it is important that we understand how this 'ap=
plied config'
is supposed to be populated on a device.

First =
it was said that it there is just one way they can be different;
time (o=
n async systems).=C2=A0 After some discussion I think there are now
four=
 ways:



IMO it would =
help to think just a bit about the operational aspects
of these i=
ssues.

There are at least 2 outcomes I can think o=
f:

=C2=A0 Outcome 1) Convergence:=C2=A0
=
=C2=A0 Intended config eventually matches Applied

=
=C2=A0 Outcome 2) Non-convergence:
=C2=A0 Intended config is not =
going to become Applied

A system needs to decide i=
f/when outcome 2 has occurred.
When is a fault raised because con=
vergence is not happening?
There are probably other uses for all =
this extra meta-data.

So how do these 4 types of d=
ifferences relate to these outcomes?

=
=C2=A0=C2=A01.=C2=A0 Time (in async systems).
=


Obviously the main use-case.
Nothing in any s=
olution proposal helps the client =C2=A0decide Outcome 2 has occurred.
That is out of scope I guess.

For most syste=
ms, this time delta will be too short to worry about ( < 5 sec.)
A good solution would not impact this vast majority of servers.




=C2=A0=
=C2=A02.=C2=A0 Hardware.=C2=A0 If something is in intended config bu=
t there is no hw
=C2=A0 =C2=A0 =C2=A0=C2=A0present, it is n=
ot in applied.

This is usually handled =
with a notification that the line-card was plugged in, which
caus=
es the NMS to re-check the config.=C2=A0 The solution proposal assumes the =
server
can identify all the resources or other reasons that some =
specific leaf is not applied yet.
This seems very complicated to =
implement in the server.



=C2=A0=C2=A03.=C2=A0 System-controlled stuff.=C2=A0 If t=
he system auto-creates an
=C2=A0 =C2=A0 =C2=A0=C2=A0interfa=
ce (for example), it will be in the applied config but
=C2=A0 =C2=A0 =C2=
=A0=C2=A0not in intended.

=

There is no convergence here because this is a case where ap=
plied has more than intended,
not the other way around.



=C2=A0=C2=A04.=
=C2=A0 "Template substitution"; the draft uses the example of an =
'all'
=C2=A0 =C2=A0 =C2=A0=C2=A0interface that exis=
ts in intended config but not in applied.


There is no convergence here because the template is not supposed to=
 show up in Applied.
However it is worth noting than none of the =
proposals solve this problem.
The Intended and Applied will never=
 match.=C2=A0 The NMS must understand
how the specific template w=
orks to know what actual instances are expected in Applied.

<=
/div>
=C2=A0

Then Lada brought up the example=
 of ip addresses.=C2=A0 It was mentioned
on the call that for ip address=
es there would be three lists; one for
intended, one for applied, and on=
e in derived state, where the one in
derived state is what the box *real=
ly* uses.=C2=A0 So for example if it
gets an ip from dhcp, it will be in=
 the derived state list, but not in
applied config.

Why is this i=
p-address list different from the interface list?=C2=A0 Why
was it enoug=
h with two lists for interfaces, but we need three for ip
addresses?
=


/martin


Andy
=C2=A0
_______________________________________=
________
netmod mailing list
netmod@ietf.org
https://www.ietf.org=
/mailman/listinfo/netmod

________________________________=
_______________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



Mahesh Jethanandani











--089e0158b5bc29c69f051f84b673--


From nobody Mon Sep 14 01:10:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807091A87BD for ; Mon, 14 Sep 2015 01:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level: 
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_BOTCC=2.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgADzY3PnlK7 for ; Mon, 14 Sep 2015 01:10:50 -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 665771B2C89 for ; Mon, 14 Sep 2015 01:10:50 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8464747; Mon, 14 Sep 2015 10:10:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HyDz5fq2OutA; Mon, 14 Sep 2015 10:10:47 +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; Mon, 14 Sep 2015 10:10:47 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C82522004E; Mon, 14 Sep 2015 10:10:47 +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 QuM-wvP6csxh; Mon, 14 Sep 2015 10:10:46 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C425820048; Mon, 14 Sep 2015 10:10:45 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EB8263708002; Mon, 14 Sep 2015 10:10:42 +0200 (CEST)
Date: Mon, 14 Sep 2015 10:10:42 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20150914081042.GC46546@elstar.local>
Mail-Followup-To: Robert Wilton , Martin Bjorklund , aldrin.ietf@gmail.com, netmod@ietf.org
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com> <55F2A4CE.70608@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55F2A4CE.70608@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 08:10:52 -0000

On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
> >
> >Then Lada brought up the example of ip addresses.  It was mentioned
> >on the call that for ip addresses there would be three lists; one for
> >intended, one for applied, and one in derived state, where the one in
> >derived state is what the box *really* uses.  So for example if it
> >gets an ip from dhcp, it will be in the derived state list, but not in
> >applied config.
> >
> >Why is this ip-address list different from the interface list?  Why
> >was it enough with two lists for interfaces, but we need three for ip
> >addresses?
> I don't see that they are different.  I think that you have 3 
> lists/leaves in both cases:
> 
> I.e. I would say that 3 IP addr leaves are required in an async system, 
> at a given time t:
>  - only the intended leaf can indicate what IP addr config the operator 
> wants on the interface (if any).
>  - only the applied leaf can indicate what IP addr is actually being 
> used as the configured value on the interface.
>  - only the derived leaf can indicate what IP addr is actually 
> operationally being used for the interface (which might be due to IP 
> addr config, DHCP, or perhaps some other mechanism).
> 
> I think that in the both kwatsen-netmod-opstate and 
> wilton-netmod-opstate there are logically 3 interface lists as well:
>  - /if:interfaces is logically split into 2, either through being 
> present in separate running and applied datastores, or through having 
> separate cfg-intended/cfg-applied leaves.
>  - /if:interfaces-state, which I perceive as logically the derived 
> state for an interface.
>

My personal requirement would be to be able to find all IP addresses
of an interface that are operationally used in one place.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 14 01:21:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997211B478F for ; Mon, 14 Sep 2015 01:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_XbEzqAxpQN for ; Mon, 14 Sep 2015 01:21: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 031DC1B4747 for ; Mon, 14 Sep 2015 01:21:52 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D3341AE0492; Mon, 14 Sep 2015 10:21:50 +0200 (CEST)
Date: Mon, 14 Sep 2015 10:21:55 +0200 (CEST)
Message-Id: <20150914.102155.1446687883167410013.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20150914081042.GC46546@elstar.local>
References: <20150911.093846.709202940600841233.mbj@tail-f.com> <55F2A4CE.70608@cisco.com> <20150914081042.GC46546@elstar.local>
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: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 08:21:53 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
> > >
> > >Then Lada brought up the example of ip addresses.  It was mentioned
> > >on the call that for ip addresses there would be three lists; one for
> > >intended, one for applied, and one in derived state, where the one in
> > >derived state is what the box *really* uses.  So for example if it
> > >gets an ip from dhcp, it will be in the derived state list, but not in
> > >applied config.
> > >
> > >Why is this ip-address list different from the interface list?  Why
> > >was it enough with two lists for interfaces, but we need three for ip
> > >addresses?
> > I don't see that they are different.  I think that you have 3 
> > lists/leaves in both cases:
> > 
> > I.e. I would say that 3 IP addr leaves are required in an async system, 
> > at a given time t:
> >  - only the intended leaf can indicate what IP addr config the operator 
> > wants on the interface (if any).
> >  - only the applied leaf can indicate what IP addr is actually being 
> > used as the configured value on the interface.
> >  - only the derived leaf can indicate what IP addr is actually 
> > operationally being used for the interface (which might be due to IP 
> > addr config, DHCP, or perhaps some other mechanism).
> > 
> > I think that in the both kwatsen-netmod-opstate and 
> > wilton-netmod-opstate there are logically 3 interface lists as well:
> >  - /if:interfaces is logically split into 2, either through being 
> > present in separate running and applied datastores, or through having 
> > separate cfg-intended/cfg-applied leaves.
> >  - /if:interfaces-state, which I perceive as logically the derived 
> > state for an interface.
> >
> 
> My personal requirement would be to be able to find all IP addresses
> of an interface that are operationally used in one place.

Yes.  I am trying to understand if a separate list of operationally
used addresses is needed even if we have the "applied config".  I
think the answer is yes.  Then the question is if we don't need a
separate list of operationally used interfaces as well.  If we do,
what value does the "applied config" idea bring us?


/martin


From nobody Mon Sep 14 01:27:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A71B5FD0 for ; Mon, 14 Sep 2015 01:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HER7vesdhVJU for ; Mon, 14 Sep 2015 01:27:52 -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 119F41B5E17 for ; Mon, 14 Sep 2015 01:27:52 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D09208E4; Mon, 14 Sep 2015 10:27:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id M1OLhRd2K_OJ; Mon, 14 Sep 2015 10:27:49 +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; Mon, 14 Sep 2015 10:27:49 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91A2F20048; Mon, 14 Sep 2015 10:27:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y4f4NUV8MjVM; Mon, 14 Sep 2015 10:27:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 552E320053; Mon, 14 Sep 2015 10:27:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8D355370808A; Mon, 14 Sep 2015 10:27:45 +0200 (CEST)
Date: Mon, 14 Sep 2015 10:27:45 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20150914082745.GE46546@elstar.local>
Mail-Followup-To: Andy Bierman , Mahesh Jethanandani , "netmod@ietf.org" 
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>  <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 08:27:53 -0000

On Fri, Sep 11, 2015 at 08:48:55PM -0700, Andy Bierman wrote:
> 
> All solutions expect the server to be able to determine applied status for
> every leaf
> in the intended config. All solutions require basically the same internal
> API support
> to check the relevant applied config or operational state.
> 
> In every solution, the server will magically know how to check that the IP
> address is active.
> That's the point. It is better than forcing the client to know how to do
> this for every type of server.
> 
> IMO, this requirement is clear, and each draft has a solution approach for
> this new API.
>

For resources residing somewhere in an OS kernel (e.g. IP addresses of
an interface), a proper implementation would require that the kernel
knows why the resource is there and not just the fact that the
resource is there. If I take an average resource in the Linux kernel,
then this information is not kept in the kernel. Daemons and user
space application simply create and modify resources in the kernel and
then the kernel does what it does. So how would I implement an applied
datastore on such a kernel? One obvious option would be that I simply
grab the operational state and I match it against the intended config
and everything that matches I report as applied config. Of course,
this may go wrong in certain cases if there are clashes or the mapping
is not trivial 1:1. But unless the piece of code that manages the
underlying resource has a way to maintain and manage meta information,
this is probably the best an implementation will be able to do. Or am
I missing something?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 14 01:31:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D181B365B for ; Mon, 14 Sep 2015 01:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFTzfdX1-kAf for ; Mon, 14 Sep 2015 01:31:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908F21B5BB6 for ; Mon, 14 Sep 2015 01:31:08 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 3306218188D; Mon, 14 Sep 2015 10:31:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442219467; bh=BwTOhFo/JIQz/5wUvYtd7Zbvx+KNke1ElYFn0RhZvb0=; h=From:Date:To; b=RMnMrvjDHcDcNeFJgISBWOnz+x4+g0FF1X1EkA6zMCHWujyivZLS0pPveW3bM41qj GqvDbuiATBCZ8BviS/IWcgwyuM2BSNrsOGuMZ2TPy9zGKtMGZtwls0FYvezUL0G7fh C4oPNKiCHTl3ZsuT0KMAo2GVcLNslzyLWCf4H8A0=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150914.102155.1446687883167410013.mbj@tail-f.com>
Date: Mon, 14 Sep 2015 10:31:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F839161-A126-495B-832B-BD5533346AEE@nic.cz>
References: <20150911.093846.709202940600841233.mbj@tail-f.com> <55F2A4CE.70608@cisco.com> <20150914081042.GC46546@elstar.local> <20150914.102155.1446687883167410013.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 08:31:11 -0000

> On 14 Sep 2015, at 10:21, Martin Bjorklund  wrote:
>=20
> Juergen Schoenwaelder  wrote:
>> On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
>>>>=20
>>>> Then Lada brought up the example of ip addresses.  It was mentioned
>>>> on the call that for ip addresses there would be three lists; one =
for
>>>> intended, one for applied, and one in derived state, where the one =
in
>>>> derived state is what the box *really* uses.  So for example if it
>>>> gets an ip from dhcp, it will be in the derived state list, but not =
in
>>>> applied config.
>>>>=20
>>>> Why is this ip-address list different from the interface list?  Why
>>>> was it enough with two lists for interfaces, but we need three for =
ip
>>>> addresses?
>>> I don't see that they are different.  I think that you have 3=20
>>> lists/leaves in both cases:
>>>=20
>>> I.e. I would say that 3 IP addr leaves are required in an async =
system,=20
>>> at a given time t:
>>> - only the intended leaf can indicate what IP addr config the =
operator=20
>>> wants on the interface (if any).
>>> - only the applied leaf can indicate what IP addr is actually being=20=

>>> used as the configured value on the interface.
>>> - only the derived leaf can indicate what IP addr is actually=20
>>> operationally being used for the interface (which might be due to IP=20=

>>> addr config, DHCP, or perhaps some other mechanism).
>>>=20
>>> I think that in the both kwatsen-netmod-opstate and=20
>>> wilton-netmod-opstate there are logically 3 interface lists as well:
>>> - /if:interfaces is logically split into 2, either through being=20
>>> present in separate running and applied datastores, or through =
having=20
>>> separate cfg-intended/cfg-applied leaves.
>>> - /if:interfaces-state, which I perceive as logically the derived=20
>>> state for an interface.
>>>=20
>>=20
>> My personal requirement would be to be able to find all IP addresses
>> of an interface that are operationally used in one place.
>=20
> Yes.  I am trying to understand if a separate list of operationally
> used addresses is needed even if we have the "applied config".  I
> think the answer is yes.  Then the question is if we don't need a
> separate list of operationally used interfaces as well.  If we do,
> what value does the "applied config" idea bring us?

In my view, it provides just information that intended configuration was =
taken into account in an asynchronous system but, despite the =
definition, it may not always provide the parameter values that are =
operationally used. If this is true, then IMO the use case for applied =
configuration is too narrow and doesn=E2=80=99t warrant making applied =
configuration a general requirement.

Lada

>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Sep 14 02:50:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2AA1B5DC0 for ; Mon, 14 Sep 2015 02:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9h5L459dNUb for ; Mon, 14 Sep 2015 02:50:16 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan5.extendcp.co.uk [79.170.43.33]) (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 98ABE1B5D83 for ; Mon, 14 Sep 2015 02:50:16 -0700 (PDT)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan6.hi.local) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZbQOs-0008NY-QS; Mon, 14 Sep 2015 10:50:14 +0100
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=www.outitgoes.com) by mailscan6.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZbQOr-0005Vg-F3; Mon, 14 Sep 2015 10:50:14 +0100
Received: from localhost ([127.0.0.1]) by webmail4.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZbQOr-0001ux-7L; Mon, 14 Sep 2015 10:50:13 +0100
Message-Id: <086460742009f24c7cb566cc4652d26bc9dcd52b@webmail.hansfords.net>
From: "Jonathan Hansford" 
To: "Kent Watsen" , netmod@ietf.org
X-Mailer: Atmail 6.6.0.11156
X-Originating-IP: 212.159.131.153
in-reply-to: 
Date: Mon, 14 Sep 2015 10:50:13 +0100
Content-Type: multipart/alternative; boundary="=_e80e6c8bbd86fa60e3b0054ff63a6b9d"
MIME-Version: 1.0
X-Authenticated-As: jonathan@hansfords.net
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 09:50:27 -0000

--=_e80e6c8bbd86fa60e3b0054ff63a6b9d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Looking in from outside the current problem domain I'm not sure I'm=0Asu=
fficiently informed to comment, however I have a couple of queries:=0A=
=0A=09* The requirements talk about both synchronous and asynchronous=0A=
systems (1(D), 3, 3(A)) but really only address the behaviour for=0Aasyn=
chronous systems. Would it not be worth clarifying the=0Arelationship be=
tween the intended and applied configurations for=0Asynchronous systems=
 (i.e. they are the same), hence there is no need=0Afor synchronous requ=
irements equivalent to 1(D) and 3(A)?=0A=09* Why does 7(A) limit the sco=
pe to IETF-defined modules of others are=0Anow defining YANG modules?=0A=
=0AThanks,=0AJonathan=0A=0A----- Original Message -----=0AFrom: "Kent Wa=
tsen" =0ATo:"netmod@ietf.org" =0ACc:=0ASent:Fri, 11 Sep 2015 22:16:40 +0=
000=0ASubject:[netmod] FW: New Version Notification for=0Adraft-chairs-n=
etmod-opstate-reqs-00.txt=0A=0A The AD and chairs thought it best to for=
malize the consensus on the=0A requirements a bit more. So we created th=
e I-D listed below to track=0Aand=0A capture final consensus.=0A=0A Addi=
tionally, we want to use this GitHub issue tracker to track=0Aissues:=0A=
=0A https://github.com/netmod-wg/opstate-reqs/issues=0A=0A Consistent wi=
th Tom's earlier email, we want to collect any issues=0Awith=0A these re=
quirements before EOB Monday, September 14, 2015 at 5PM EST.=0AIf=0A you=
 have an issue, in addition to posting it to the list, please=0Aconsider=
=0A adding it to the GitHub tracker, and let people know you did so. Our=
=0A goal is to close the issues as quickly as possible, some will go to=
=0ADEAD=0A while others may remain OPEN, based on WG consensus.=0A=0A Th=
anks,=0A Kent & Tom=0A=0A On 9/11/15, 5:36 PM, "internet-drafts@ietf.org=
" =0A wrote:=0A=0A >=0A >A new version of I-D, draft-chairs-netmod-opsta=
te-reqs-00.txt=0A >has been successfully submitted by Kent Watsen and po=
sted to the=0A >IETF repository.=0A >=0A >Name: draft-chairs-netmod-opst=
ate-reqs=0A >Revision: 00=0A >Title: NETMOD Operational State Requiremen=
ts=0A >Document date: 2015-09-11=0A >Group: Individual Submission=0A >Pa=
ges: 5=0A >URL: =0A >https://www.ietf.org/internet-drafts/draft-chairs-n=
etmod-opstate-reqs-00.t=0A >xt=0A >Status: =0A >https://datatracker.ietf=
org/doc/draft-chairs-netmod-opstate-reqs/=0A >Htmlized: =0A >https://to=
ols.ietf.org/html/draft-chairs-netmod-opstate-reqs-00=0A >=0A >=0A >Abst=
ract:=0A > This document captures consensus on operational state require=
ments=0Aby=0A > the NETMOD working group.=0A >=0A > =0A > =0A >=0A >=0A=
 >Please note that it may take a couple of minutes from the time of=0A >=
submission=0A >until the htmlized version and diff are available at tool=
s.ietf.org.=0A >=0A >The IETF Secretariat=0A >=0A=0A ___________________=
____________________________=0A netmod mailing list=0A netmod@ietf.org=
=0A https://www.ietf.org/mailman/listinfo/netmod=0A

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

Looking in from outside the current problem dom=
ain I'm not sure I'm sufficiently informed to comment, however I have a=
 couple of queries:
  1. The requirements talk about both synchro=
nous and asynchronous systems (1(D), 3, 3(A)) but really only address th=
e behaviour for asynchronous systems. Would it not be worth clarifying t=
he relationship between the intended and applied configurations for sync=
hronous systems (i.e. they are the same), hence there is no need for syn=
chronous requirements equivalent to 1(D) and 3(A)?
  2. Why does 7(A)=
 limit the scope to IETF-defined modules of others are now defining YANG=
 modules?
Thanks,

Jonathan

----- Original Message -----
From: "Kent Watsen" <kwatsen@juniper.net>

To:
"netmod@ietf.org" <netmod@ietf.org>
Cc:

Sent:
Fri, 11 Sep 2015 22:16:40 +0000
Subject:
[netmod] FW: New Version Notificati=
on for draft-chairs-netmod-opstate-reqs-00.txt



=
=0AThe AD and chairs thought it best to formalize the consensus on the=0Arequirements a bit more.  So we created the I-D listed below to t=
rack and
=0Acapture final consensus.

=0AAdditionally, we=
 want to use this GitHub issue tracker to track issues:

=0A=
=09https://github.com/netmod-wg/opstate-reqs/issues

=0AConsis=
tent with Tom's earlier email, we want to collect any issues with
=
=0Athese requirements before EOB Monday, September 14, 2015 at 5PM EST.=
  If
=0Ayou have an issue, in addition to posting it to the list, p=
lease consider
=0Aadding it to the GitHub tracker, and let people k=
now you did so.   Our
=0Agoal is to close the issues as quickly as=
 possible, some will go to DEAD
=0Awhile others may remain OPEN, ba=
sed on WG consensus.

=0AThanks,
=0AKent & Tom
<=
br />
=0AOn 9/11/15, 5:36 PM, "internet-drafts@ietf.org" <intern=
et-drafts@ietf.org>
=0Awrote:

=0A>
=0A>A n=
ew version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
=0A>h=
as been successfully submitted by Kent Watsen and posted to the
=0A=
>IETF repository.
=0A>
=0A>Name:=09=09draft-chairs-ne=
tmod-opstate-reqs
=0A>Revision:=0900
=0A>Title:=09=09NET=
MOD Operational State Requirements
=0A>Document date:=092015-09-=
11
=0A>Group:=09=09Individual Submission
=0A>Pages:=09=
=095
=0A>URL:            
=0A>https://www.ietf.org/inter=
net-drafts/draft-chairs-netmod-opstate-reqs-00.t
=0A>xt
=0A=
>Status:         
=0A>https://datatracker.ietf.org/doc/draft-=
chairs-netmod-opstate-reqs/
=0A>Htmlized:       
=0A>htt=
ps://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
=0A>=
;
=0A>
=0A>Abstract:
=0A>   This document captur=
es consensus on operational state requirements by
=0A>   the NET=
MOD working group.
=0A>
=0A>                  
=0A&=
gt;        
=0A>
=0A>
=0A>Please note that it ma=
y take a couple of minutes from the time of
=0A>submission
=
=0A>until the htmlized version and diff are available at tools.ietf.o=
rg.
=0A>
=0A>The IETF Secretariat
=0A>
=0A_______________________________________________
=0Anetmod mai=
ling list
=0Anetmod@ietf.org
=0Ahttps://www.ietf.org/mailman/l=
istinfo/netmod


--=_e80e6c8bbd86fa60e3b0054ff63a6b9d--



From nobody Mon Sep 14 03:24:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17421B4A63 for ; Mon, 14 Sep 2015 03:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level: 
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nR48y6GgFaKT for ; Mon, 14 Sep 2015 03:24: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 37F871B2D2B for ; Mon, 14 Sep 2015 03:24:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5285; q=dns/txt; s=iport; t=1442226294; x=1443435894; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Zs/E4FX2YKY2nNdsMDoXpuZ3T1JS1xtU2e8bvcPWRwY=; b=eRV29ICTERXKbsMsAf9krCxa+C1oHxC0BLXypfJC2brD3OhE6yUrhdG4 16y7cRgcIk62VEqii7O+/cPoeEVcsoCqGPRd+qQT+hOoQ8LNJfk6Ynsb/ W3R83wpQPgpG3Y9qqrLEXZbDzgm17Lw8Pn6feVboEjis1mWl0EPR0LnqC M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CtBACZn/ZV/xbLJq1dg3dpgyq8DQqFL0oCgX4BAQEBAQGBC4QjAQEBAwEBAQEgDwEFNhALCxAIAgIFDBUCAg8CFjAGAQwGAgEBF4gLCA21c5N7AQEBAQEBAQEBAQEBAQEBAQEBFgSBIoVRhH2EQlIKgl+BQwWVV4x+gUyHMYlMiDVjhAI9M4p9AQEB
X-IronPort-AV: E=Sophos;i="5.17,527,1437436800"; d="scan'208";a="605107983"
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; 14 Sep 2015 10:24:52 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8EAOqrq008335; Mon, 14 Sep 2015 10:24:52 GMT
To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , netmod@ietf.org
References: <20150911.093846.709202940600841233.mbj@tail-f.com> <55F2A4CE.70608@cisco.com> <20150914081042.GC46546@elstar.local> <20150914.102155.1446687883167410013.mbj@tail-f.com> <3F839161-A126-495B-832B-BD5533346AEE@nic.cz>
From: Robert Wilton 
Message-ID: <55F6A074.80508@cisco.com>
Date: Mon, 14 Sep 2015 11:24:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <3F839161-A126-495B-832B-BD5533346AEE@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 10:24:56 -0000

Hi,

On 14/09/2015 09:31, Ladislav Lhotka wrote:
>> On 14 Sep 2015, at 10:21, Martin Bjorklund  wrote:
>>
>> Juergen Schoenwaelder  wrote:
>>> On Fri, Sep 11, 2015 at 10:54:22AM +0100, Robert Wilton wrote:
>>>>> Then Lada brought up the example of ip addresses.  It was mentioned
>>>>> on the call that for ip addresses there would be three lists; one for
>>>>> intended, one for applied, and one in derived state, where the one in
>>>>> derived state is what the box *really* uses.  So for example if it
>>>>> gets an ip from dhcp, it will be in the derived state list, but not in
>>>>> applied config.
>>>>>
>>>>> Why is this ip-address list different from the interface list?  Why
>>>>> was it enough with two lists for interfaces, but we need three for ip
>>>>> addresses?
>>>> I don't see that they are different.  I think that you have 3
>>>> lists/leaves in both cases:
>>>>
>>>> I.e. I would say that 3 IP addr leaves are required in an async system,
>>>> at a given time t:
>>>> - only the intended leaf can indicate what IP addr config the operator
>>>> wants on the interface (if any).
>>>> - only the applied leaf can indicate what IP addr is actually being
>>>> used as the configured value on the interface.
>>>> - only the derived leaf can indicate what IP addr is actually
>>>> operationally being used for the interface (which might be due to IP
>>>> addr config, DHCP, or perhaps some other mechanism).
>>>>
>>>> I think that in the both kwatsen-netmod-opstate and
>>>> wilton-netmod-opstate there are logically 3 interface lists as well:
>>>> - /if:interfaces is logically split into 2, either through being
>>>> present in separate running and applied datastores, or through having
>>>> separate cfg-intended/cfg-applied leaves.
>>>> - /if:interfaces-state, which I perceive as logically the derived
>>>> state for an interface.
>>>>
>>> My personal requirement would be to be able to find all IP addresses
>>> of an interface that are operationally used in one place.
>> Yes.  I am trying to understand if a separate list of operationally
>> used addresses is needed even if we have the "applied config".  I
>> think the answer is yes.  Then the question is if we don't need a
>> separate list of operationally used interfaces as well.
I may be off the mark, but I don't think that the Open Config 
requirements are saying that they don't want/need a separate list of 
operationally used interfaces, but more that they want the config and 
operational data for an interface to be under the same per interface 
container, so (i) that you can easily get all the data for an interface 
in a single request, or (ii) easily get the config and operational data 
for a particular feature on a interface without having to request the 
interface data from two separate lists.

So, one hypothetical solution (which YANG doesn't currently allow) might 
be to have a single list of all interfaces, each with two leaves to 
indicate whether those interfaces are configured and/or operational.

>>    If we do,
>> what value does the "applied config" idea bring us?
> In my view, it provides just information that intended configuration was taken into account in an asynchronous system but, despite the definition, it may not always provide the parameter values that are operationally used.
Yes, this is also my thinking for the applied config.  In fact I think 
that it is analogous to the config states in a synchronous NETCONF 
commit.  I.e. the cfg-applied status doesn't give you any more 
information than a  request would against a server after a 
sync config change had been committed.

Ignoring errors, all the intended cfg vs applied cfg really provides is 
the ability for a client to determine how far through an async config 
commit a server has reached.  It is instead of the server blocking the 
commit request until the request has completed.  This equivalence is 
also one of the reasons why I don't think that applied cfg should be 
used for templating.

Specifically, I don't think that the cfg-applied state has to guarantee 
that a particular config change has been programmed everywhere any more 
than a synchronous commit has to make that same guarantee.  I.e. at the 
point in time that a server is happy to reply indicating a sync config 
request has completed should be sufficient to update the cfg-applied 
leaf in an equivalent async commit.

>   If this is true, then IMO the use case for applied configuration is too narrow and doesn’t warrant making applied configuration a general requirement.
I just see it as a way to support clients that want to process 
configuration in an asynchronous fashion, or for servers that want to 
adopt an eventual consistency configuration model.

Thanks,
Rob


>
> Lada
>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Sep 14 03:56:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7467E1B6195 for ; Mon, 14 Sep 2015 03:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7ZoCNa2i1Pz for ; Mon, 14 Sep 2015 03:56:52 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 10B951B6192 for ; Mon, 14 Sep 2015 03:56:51 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 96283C4175C2 for ; Mon, 14 Sep 2015 12:56:50 +0200 (CEST)
References: <20150706171427.3438.31431.idtracker@ietfa.amsl.com>
Cc: netmod@ietf.org
From: Jernej Tuljak 
Message-ID: <55F6A7F0.2010400@mg-soft.si>
Date: Mon, 14 Sep 2015 12:56:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150706171427.3438.31431.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 10:56:54 -0000

Hi,

current text in 6087bis-04 (Section 5.6.4):

    XPath expressions for 'when' statements SHOULD NOT reference the
    context node or any descendant nodes of the context node.  They MAY
    reference descendant nodes if the 'when' statement is contained
    within an 'augment' statement, and the referenced nodes are not
    defined within the 'augment' statement.

This is OK. But the text never mentions an analogous case, which is when 
a when-stmt is defined for a uses-stmt. I think this should be 
corrected. Note that finding the initial context node for the expression 
uses an algorithm that is virtually equal to the 'augment' case (first 
data node ancestor), therefore the first sentence in the above text 
discourages use of 'when' statements within a 'uses' statement, which I 
don't think was the intention.

   grouping special-params {
     leaf param1 {
       type string;
     }
     leaf param2 {
       type string;
     }
   }

   container foo {
     leaf enable-special {
       type boolean;
     }
     uses special-params {
       when "enable-special = 'true'";
     }
   }

In my example the expression references a descendant of the initial 
context node, which should be OK. What would be problematic is 
referencing descendants that are defined in the grouping.

OLD:

    XPath expressions for 'when' statements SHOULD NOT reference the
    context node or any descendant nodes of the context node.  They MAY
    reference descendant nodes if the 'when' statement is contained
    within an 'augment' statement, and the referenced nodes are not
    defined within the 'augment' statement.

NEW:

    XPath expressions for 'when' statements SHOULD NOT reference the
    context node or any descendant nodes of the context node.  They MAY
    reference descendant nodes if the 'when' statement is contained
    within an 'augment' statement, and the referenced nodes are not
    defined within the 'augment' statement. They MAY also reference
    descendant nodes if the 'when' statement is contained within a
    'uses' statement, and the referenced nodes are not defined within
    the 'grouping' statement being referred to by the 'uses' statement.

Or something similar.

Jernej


internet-drafts@ietf.org je 6.7.2015 ob 19:14 napisal:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>
>          Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
>          Author          : Andy Bierman
> 	Filename        : draft-ietf-netmod-rfc6087bis-04.txt
> 	Pages           : 52
> 	Date            : 2015-07-06
>
> Abstract:
>     This memo provides guidelines for authors and reviewers of Standards
>     Track specifications containing YANG data model modules.  Applicable
>     portions may be used as a basis for reviews of other YANG data model
>     documents.  Recommendations and procedures are defined, which are
>     intended to increase interoperability and usability of Network
>     Configuration Protocol (NETCONF) implementations that utilize YANG
>     data model modules.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-04
>
>
> 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/
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Mon Sep 14 04:03:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC41B3EC8 for ; Mon, 14 Sep 2015 04:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh6SxjbHHmEj for ; Mon, 14 Sep 2015 04:03:42 -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 A090C1B3B00 for ; Mon, 14 Sep 2015 04:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20045; q=dns/txt; s=iport; t=1442228621; x=1443438221; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=CvSYSY3P9c0BCFheNG1+/1DouwKfDZwdLiymQrFFHe8=; b=Zb9TZLHvoPhgogqofSi9BTyRO+pZELPWsp2NfESB7ZH0tD37WTuvje8+ /4rj5X0dqewQMWDw89P69ZunEMfzfHu8s7ZONMFBrPJ3841Jqoj05c3Pn xNZqGMdvvBaTe+G76fUqCMx3boC86VPA0udmtGYfH/02YHtPxD9Tt0OJM I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ChBADKqPZV/xbLJq1TCoN3ab83AQmFL0oCggIBAQEBAQGBC4QjAQEBAwEBAQFrCgEFCwsYCRYIBwkDAgECAQ8GHxEGAQwGAgEBF4d+AwoIDcR9DYRtAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R9glCBYBJLB4QsBZI0gyOHNoNbgW2IfYpFhzxjghEcgVU9M4p9AQEB
X-IronPort-AV: E=Sophos;i="5.17,527,1437436800";  d="scan'208,217";a="605108777"
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; 14 Sep 2015 11:03:39 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8EB3dhf026951; Mon, 14 Sep 2015 11:03:39 GMT
To: Andy Bierman , Martin Bjorklund 
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: <55F6A98B.3030509@cisco.com>
Date: Mon, 14 Sep 2015 12:03:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050307050900060300010108"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 11:03:50 -0000

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

Hi Andy,

On 11/09/2015 17:42, Andy Bierman wrote:
>
>
> On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund  > wrote:
>
>     Sam Aldrin >
>     wrote:
>     >
>     > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
>     > > > wrote:
>     > >
>     > >
>     > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
>     > >> 
>     >> wrote:
>     > >>
>     > >> Now, think about configuration parameters that have applied
>     > >> configuration located in more than one place. Lets say you
>     change the
>     > >> IP address of an interface, it is likely that this
>     configuration will
>     > >> be passed around as input to a handful of subsystems (e.g.
>     the DHCP
>     > >> server, some routing daemons that may bind to specific IP
>     > >> addresses). Is the intended and applied in sync when a
>     specific subset
>     > >> of those configurations are updated. What happens if theres
>     a partial
>     > >> failure?
>     > >
>     > > This is a good example. Another example, and somebody on the call
>     > > today started to ask this but got cut off, relates to
>     interfaces on
>     > > the device.
>     > >
>     > > Interfaces already exist on a system. As such they have a
>     > > configuration (default values) that exists on them. They are
>     enabled
>     > > when configuration gets applied on them. They will have applied
>     > > configuration but no intended configuration. Should this be
>     reported?
>     > >
>     > > Yet another example is of a BFD session that gets bootstrapped
>     because
>     > > of a ping. There is no intended configuration, but the session
>     exists
>     > > and a query of configuration in this case would return a valid BFD
>     > > session.
>     > >
>     > > Could we get some clarification (with examples, preferably) on
>     what
>     > > the expectation is from a openconfig opstate perspective?
>     >
>     > Section 7 of draft-openconfig-netmod-opstate talks about
>     > that. Specifically, #3 talks about the interface question you
>     raise..
>
>     I think it is important that we understand how this 'applied config'
>     is supposed to be populated on a device.
>
>     First it was said that it there is just one way they can be different;
>     time (on async systems).  After some discussion I think there are now
>     four ways:
>
>
>
> IMO it would help to think just a bit about the operational aspects
> of these issues.
>
> There are at least 2 outcomes I can think of:
>
>   Outcome 1) Convergence:
>   Intended config eventually matches Applied
>
>   Outcome 2) Non-convergence:
>   Intended config is not going to become Applied
>
> A system needs to decide if/when outcome 2 has occurred.
> When is a fault raised because convergence is not happening?

I think that this same issue exists for a servers handling a sync config 
commit as well.  Presumably these would also block forever or require 
some timeout to determine (2)?


> There are probably other uses for all this extra meta-data.
>
> So how do these 4 types of differences relate to these outcomes?
>
>       1.  Time (in async systems).
>
>
> Obviously the main use-case.
> Nothing in any solution proposal helps the client  decide Outcome 2 
> has occurred.
> That is out of scope I guess.
>
> For most systems, this time delta will be too short to worry about ( < 
> 5 sec.)
> A good solution would not impact this vast majority of servers.
>
>
>
>
>       2.  Hardware.  If something is in intended config but there is no hw
>           present, it is not in applied.
>
>
> This is usually handled with a notification that the line-card was 
> plugged in, which
> causes the NMS to re-check the config.  The solution proposal assumes 
> the server
> can identify all the resources or other reasons that some specific 
> leaf is not applied yet.
> This seems very complicated to implement in the server.
>
>
>
>       3.  System-controlled stuff.  If the system auto-creates an
>           interface (for example), it will be in the applied config but
>           not in intended.
>
>
>
> There is no convergence here because this is a case where applied has 
> more than intended,
> not the other way around.
>
>
>
>       4.  "Template substitution"; the draft uses the example of an 'all'
>           interface that exists in intended config but not in applied.
>
>
> There is no convergence here because the template is not supposed to 
> show up in Applied.
> However it is worth noting than none of the proposals solve this problem.
> The Intended and Applied will never match.  The NMS must understand
> how the specific template works to know what actual instances are 
> expected in Applied.

Yes, and this is why I am suggest that templating shouldn't be part of 
applied cfg.  It looks like templating only turns up in section 7 of 
openconfig-netmod-opstate-01 rather than being listed in section 4 on 
requirements.

If support for generic YANG templating is required, then I would suggest 
that should be considered separately from the current opstate draft.

Thanks,
Rob


>
>
>     Then Lada brought up the example of ip addresses.  It was mentioned
>     on the call that for ip addresses there would be three lists; one for
>     intended, one for applied, and one in derived state, where the one in
>     derived state is what the box *really* uses.  So for example if it
>     gets an ip from dhcp, it will be in the derived state list, but not in
>     applied config.
>
>     Why is this ip-address list different from the interface list?  Why
>     was it enough with two lists for interfaces, but we need three for ip
>     addresses?
>
>
>     /martin
>
>
>
> Andy
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    Hi Andy,

    

    
On 11/09/2015 17:42, Andy Bierman
      wrote:

    

    

      
      


        


          
On Fri, Sep 11, 2015 at 12:38 AM,
            Martin Bjorklund <mbj@tail-f.com> wrote:

            
Sam
              Aldrin <aldrin.ietf@gmail.com>
              wrote:

              >

              > > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani

              > > <mjethanandani@gmail.com>
              wrote:

              > >

              > >

              > >> On Sep 10, 2015, at 12:43 PM, Carl Moberg
              (camoberg)

              > >> <camoberg@cisco.com
              <mailto:camoberg@cisco.com>>
              wrote:

              > >>

              > >> Now, think about configuration parameters
              that have applied

              > >> configuration located in more than one
              place. Lets say you change the

              > >> IP address of an interface, it is likely
              that this configuration will

              > >> be passed around as input to a handful of
              subsystems (e.g. the DHCP

              > >> server, some routing daemons that may bind
              to specific IP

              > >> addresses). Is the intended and applied in
              sync when a specific subset

              > >> of those configurations are updated. What
              happens if theres a partial

              > >> failure?

              > >

              > > This is a good example. Another example, and
              somebody on the call

              > > today started to ask this but got cut off,
              relates to interfaces on

              > > the device.

              > >

              > > Interfaces already exist on a system. As such
              they have a

              > > configuration (default values) that exists on
              them. They are enabled

              > > when configuration gets applied on them. They
              will have applied

              > > configuration but no intended configuration.
              Should this be reported?

              > >

              > > Yet another example is of a BFD session that
              gets bootstrapped because

              > > of a ping. There is no intended configuration,
              but the session exists

              > > and a query of configuration in this case would
              return a valid BFD

              > > session.

              > >

              > > Could we get some clarification (with examples,
              preferably) on what

              > > the expectation is from a openconfig opstate
              perspective?

              >

              > Section 7 of draft-openconfig-netmod-opstate talks
              about

              > that. Specifically, #3 talks about the interface
              question you raise..

              

              I think it is important that we understand how this
              'applied config'

              is supposed to be populated on a device.

              

              First it was said that it there is just one way they can
              be different;

              time (on async systems). After some discussion I think
              there are now

              four ways:

              

            

            


            

            


            

            
IMO it would help to think just a bit about the
              operational aspects

            
of these issues.

            


            

            
There are at least 2 outcomes I can think of:

            


            

            
 Outcome 1) Convergence:

            
 Intended config eventually matches Applied

            


            

            
 Outcome 2) Non-convergence:

            
 Intended config is not going to become Applied

            


            

            
A system needs to decide if/when outcome 2 has
              occurred.

            
When is a fault raised because convergence is not
              happening?

          

        

      

    

    

    I think that this same issue exists for a servers handling a sync
    config commit as well. Presumably these would also block forever or
    require some timeout to determine (2)?

    

    

    

      

        

          

            
There are probably other uses for all this extra
              meta-data.

            


            

            
So how do these 4 types of differences relate to these
              outcomes?

            


            

            

               1. Time (in async systems).

            

            


            

            
Obviously the main use-case.

            
Nothing in any solution proposal helps the client
              decide Outcome 2 has occurred.

            
That is out of scope I guess.

            


            

            
For most systems, this time delta will be too short to
              worry about ( < 5 sec.)

            
A good solution would not impact this vast majority of
              servers.

            


            

            


            

            


            

            

              

               2. Hardware. If something is in intended config but
              there is no hw

                 present, it is not in applied.

            

            


            

            
This is usually handled with a notification that the
              line-card was plugged in, which

            
causes the NMS to re-check the config. The solution
              proposal assumes the server

            
can identify all the resources or other reasons that
              some specific leaf is not applied yet.

            
This seems very complicated to implement in the server.

            


            

            


            

            

              

               3. System-controlled stuff. If the system auto-creates
              an

                 interface (for example), it will be in the applied
              config but

                 not in intended.

            

            


            

            


            

            
There is no convergence here because this is a case
              where applied has more than intended,

            
not the other way around.

            


            

            


            

            

              

               4. "Template substitution"; the draft uses the example
              of an 'all'

                 interface that exists in intended config but not in
              applied.

              

            

            


            

            
There is no convergence here because the template is
              not supposed to show up in Applied.

            
However it is worth noting than none of the proposals
              solve this problem.

            
The Intended and Applied will never match. The NMS
              must understand

            
how the specific template works to know what actual
              instances are expected in Applied.

          

        

      

    

    

    Yes, and this is why I am suggest that templating shouldn't be part
    of applied cfg. It looks like templating only turns up in section 7
    of openconfig-netmod-opstate-01 rather than being listed in section
    4 on requirements.

    

    If support for generic YANG templating is required, then I would
    suggest that should be considered separately from the current
    opstate draft.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            

            

              

              Then Lada brought up the example of ip addresses. It was
              mentioned

              on the call that for ip addresses there would be three
              lists; one for

              intended, one for applied, and one in derived state, where
              the one in

              derived state is what the box *really* uses. So for
              example if it

              gets an ip from dhcp, it will be in the derived state
              list, but not in

              applied config.

              

              Why is this ip-address list different from the interface
              list? Why

              was it enough with two lists for interfaces, but we need
              three for ip

              addresses?

              

              

              /martin

            

            


            

            


            

            
Andy

            

            

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

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

            

          

          

        

      

      

      

      

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


    

    

  


--------------050307050900060300010108--


From nobody Mon Sep 14 04:19:53 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBA21B5AEB for ; Mon, 14 Sep 2015 04:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaDcW58_7Yng for ; Mon, 14 Sep 2015 04:19:50 -0700 (PDT)
Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CF11B46AB for ; Mon, 14 Sep 2015 04:19:50 -0700 (PDT)
Received: from jva2tc211.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-3.webex.com [64.68.121.247]) by sjmda12.webex.com (Postfix) with ESMTP id A9B273072 for ; Mon, 14 Sep 2015 11:19:49 +0000 (GMT)
Received: from jva2tc211.webex.com (localhost [127.0.0.1]) by jva2tc211.webex.com (Postfix) with ESMTP id 683F82005D for ; Mon, 14 Sep 2015 11:19:49 +0000 (GMT)
Date: Mon, 14 Sep 2015 11:19:49 +0000 (GMT)
From: NETMOD Working Group 
To: netmod@ietf.org
Message-ID: <530306080.1130.1442229589424.JavaMail.nobody@jva2tc211.webex.com>
MIME-Version: 1.0
Content-Type: multipart/Mixed;  boundary="----=_Part_1128_219552120.1442229589424"
X-Priority: 3
Importance: normal
Archived-At: 
Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: netmod-chairs@tools.ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 11:19:51 -0000

------=_Part_1128_219552120.1442229589424
Content-Type: multipart/Alternative; 
	boundary="----=_Part_1129_635575294.1442229589424"

------=_Part_1129_635575294.1442229589424
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: base64

CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl
YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCk1vbmRheSwgU2VwdGVtYmVyIDE0LCAyMDE1
CjU6MDAgcG0gIHwgIEV1cm9wZSBTdW1tZXIgVGltZSAoQmVybGluLCBHTVQrMDI6MDApICB8ICAx
IGhyCgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo
cD9NVElEPW1jODA0ZmI5NGNiNWMxNmM0NGJjNmM5ZjM3Y2YxM2E4MQpNZWV0aW5nIG51bWJlcjog
NjQxIDUzNCA2MzQKTWVldGluZyBwYXNzd29yZDogYWlnYW5vNEsKCg0KSk9JTiBCWSBQSE9ORQ0K
MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1
MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2
NDEgNTM0IDYzNAoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53
ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRp
bmcgdG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U
SUQ9bTA2N2ViOTY4MDk2MzRiMGE2ZmY0YjY3MDFmOWQ4N2VjDQoNCgpDYW4ndCBqb2luIHRoZSBt
ZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm
L21jCgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZp
Y2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vz
c2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2Fs
IG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNl
bnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVj
b3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2lu
IHRoZSBzZXNzaW9uLgo=
------=_Part_1129_635575294.1442229589424
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64

PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz
ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk
dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs
cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh
YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6
IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7
IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K
dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls
eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls
ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy
PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls
ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ
CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0
eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog
ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0
cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp
YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN
T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K
ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK
Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0
OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl
Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj
NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ
CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+TW9u
ZGF5LCBTZXB0ZW1iZXIgMTQsIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJ
CTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjU6MDAgcG0mbmJzcDsmbmJzcDt8
Jm5ic3A7Jm5ic3A7RXVyb3BlIFN1bW1lciBUaW1lIChCZXJsaW4sIEdNVCswMjowMCkmbmJzcDsm
bmJzcDt8Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8
L3RhYmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9
ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxl
PSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJ
PHRkIHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJl
Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWM4MDRmYjk0Y2I1YzE2
YzQ0YmM2YzlmMzdjZjEzYTgxIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l
O2ZvbnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBt
ZWV0aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ
CTwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBv
cnRhbnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9
InBhZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8
L3RkPgoJCQkJCQkJCTx0ZD42NDEgNTM0IDYzNAoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJ
CQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGlu
ZyBwYXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5haWdhbm80SzwvdGQ+CgkJCQkJCQk8L3RyPgoJ
CQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+
PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0
cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90
cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtD
YWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJt
YXJnaW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51
bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nl
c3MgY29kZTombmJzcDs2NDEgNTM0IDYzNDwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgi
Pjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rp
b25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9y
OiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwv
dGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHls
ZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0
eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm
L2oucGhwP01USUQ9bTA2N2ViOTY4MDk2MzRiMGE2ZmY0YjY3MDFmOWQ4N2VjIiBzdHlsZT0idGV4
dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlz
IG1lZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48
dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i
c3A7PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0i
Zm9udC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAg
ICAgIENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53
ZWJleC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZTox
M3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+
CiAgICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+
Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6
MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4K
CQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJ
CQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNl
IGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Np
b24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBt
YXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50
IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29y
ZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0
aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJ
CTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+
------=_Part_1129_635575294.1442229589424--

------=_Part_1128_219552120.1442229589424
Content-Type: application/octet-stream;
	name="WebEx_Meeting.ics"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="WebEx_Meeting.ics"

QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg
MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP
TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw
MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G
RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6
U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF
UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx
MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM
SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q
QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049
Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y
ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDkxNFQxNzAwMDAKRFRFTkQ7VFpJRD0i
RXVyb3BlIFRpbWUiOjIwMTUwOTE0VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu
Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQyMjI5NTg5ClVJRDo2Mzk1ZjljNS0y
Yjk1LTRmYWItYmEwOC01YzY3YWFmZGM4YzUKRFRTVEFNUDoyMDE1MDkxNFQxNTAwMDBaCkRFU0NS
SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p
ZXRmL2oucGhwP01USUQ9bWZhM2Y1ZDBjZTNiNWI4ZWU1ZGQ3MTQ4MmFlM2NiMmQyXG5NZWV0aW5n
IG51bWJlcjogNjQxIDUzNCA2MzRcbk1lZXRpbmcgcGFzc3dvcmQ6IGFpZ2FubzRLXG5cblxuSk9J
TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D
YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu
QWNjZXNzIGNvZGU6IDY0MSA1MzQgNjM0XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u
czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu
XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw
czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug
bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y
bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg
YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv
biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk
byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp
dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU
WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP
TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl
eC5jb20vaWV0Zi9qLnBocD9NVElEPW1mYTNmNWQwY2UzYjViOGVlNWRkNzE0ODJhZTNjYjJkMiI+
PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l
ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ
WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U
PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg
RkFDRT0iYXJpYWwiPjY0MSA1MzQgNjM0PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh
YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF
PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg
IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+YWlnYW5vNEs8L0ZPTlQ+PC90ZD48L3RyPjwv
dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz
cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD
T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC
Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04
NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh
bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD
RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv
bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M
T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQxIDUzNCA2MzQ8L0ZPTlQ+
Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz
dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs
Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv
Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG
QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo
dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw
QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+
Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q
T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz
IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi
ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g
Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj
aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp
c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz
aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB
U1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo=
------=_Part_1128_219552120.1442229589424--


From nobody Mon Sep 14 04:23:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288491B349C for ; Mon, 14 Sep 2015 04:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.259
X-Spam-Level: 
X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ame5O9uVQ-mG for ; Mon, 14 Sep 2015 04:23:52 -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 E6E301B519F for ; Mon, 14 Sep 2015 04:23:51 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B36E29E4; Mon, 14 Sep 2015 13:23:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id t1zX-T7-i_YJ; Mon, 14 Sep 2015 13:23:49 +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; Mon, 14 Sep 2015 13:23:49 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB8E52004E; Mon, 14 Sep 2015 13:23:49 +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 urzv2qPZ5Ocq; Mon, 14 Sep 2015 13:23:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C76220048; Mon, 14 Sep 2015 13:23:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AB33D3708312; Mon, 14 Sep 2015 13:23:44 +0200 (CEST)
Date: Mon, 14 Sep 2015 13:23:44 +0200
From: Juergen Schoenwaelder 
To: netmod-chairs@tools.ietf.org
Message-ID: <20150914112344.GB47108@elstar.local>
Mail-Followup-To: netmod-chairs@tools.ietf.org, netmod@ietf.org
References: <530306080.1130.1442229589424.JavaMail.nobody@jva2tc211.webex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <530306080.1130.1442229589424.JavaMail.nobody@jva2tc211.webex.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 11:23:55 -0000

Hi,

we will use this etherpad to take notes:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-09-14?useMonospaceFont=true

On Mon, Sep 14, 2015 at 11:19:49AM +0000, NETMOD Working Group wrote:
> 
> Hello,
> 
> NETMOD Working Group invites you to join this WebEx meeting.
> 
> 
> NETMOD YANG 1.1
> Monday, September 14, 2015
> 5:00 pm  |  Europe Summer Time (Berlin, GMT+02:00)  |  1 hr
> 
> 
> JOIN WEBEX MEETING
> https://ietf.webex.com/ietf/j.php?MTID=mc804fb94cb5c16c44bc6c9f37cf13a81
> Meeting number: 641 534 634
> Meeting password: aigano4K
> 
> 
> JOIN BY PHONE
> 1-877-668-4493 Call-in toll free number (US/Canada) 
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 641 534 634
> 
> Toll-free dialing restrictions: 
> http://www.webex.com/pdf/tollfree_restrictions.pdf
> 
> 
> Add this meeting to your calendar:
> https://ietf.webex.com/ietf/j.php?MTID=m067eb96809634b0a6ff4b6701f9d87ec
> 
> 
> Can't join the meeting? Contact support here:
> https://ietf.webex.com/ietf/mc
> 
> 
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.


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


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 14 05:41:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D81B4FB2 for ; Mon, 14 Sep 2015 05:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMA69sp13rgT for ; Mon, 14 Sep 2015 05:40:58 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D6A1B3BC2 for ; Mon, 14 Sep 2015 05:40:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10585; q=dns/txt; s=iport; t=1442234457; x=1443444057; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Ob/2FPZcRMUiwzPwbmMxVk1rTxUIlxxPF8hgWbSXmOc=; b=BE8BysaVOFij6v2PFnzd7eK4q8cTh05Sc9p/QhNLBVTnqEXzhxPVnkxO 7CXovWUEjEjXYanNO9Pjr70zXzXLkYAlR9Jzqi2loeVsl4Kk2C2aEGb8k pgc7loS1Koe5WFpe45sB3X5AyTLZr68hv9SNaMqaGNUX2esOHX0YvtPoS 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQBBv/ZV/xbLJq1dg3dpvT4BDYFuAQuFLUoCgW0UAQEBAQEBAYEKhCMBAQEEAQEBawQFAQ0ECxEEAQEBCRYPCQMCAQIBFScBCAYBDAYCAQGIKg3JfwEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9hCoLBgFYBoQmAQSMeIhfhQ2HcYFMRoNtgn6SAR8BAUKCERwWgUA8MwGJNQgXgSgBAQE
X-IronPort-AV: E=Sophos;i="5.17,527,1437436800";  d="scan'208,217";a="611596008"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Sep 2015 12:40:55 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8ECesk7027026; Mon, 14 Sep 2015 12:40:54 GMT
To: Jonathan Hansford , Kent Watsen , netmod@ietf.org
References: <086460742009f24c7cb566cc4652d26bc9dcd52b@webmail.hansfords.net>
From: Benoit Claise 
Message-ID: <55F6C056.5040802@cisco.com>
Date: Mon, 14 Sep 2015 14:40:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <086460742009f24c7cb566cc4652d26bc9dcd52b@webmail.hansfords.net>
Content-Type: multipart/alternative; boundary="------------020302040803060409050904"
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 12:41:00 -0000

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

Jonathan,
> Looking in from outside the current problem domain I'm not sure I'm 
> sufficiently informed to comment, however I have a couple of queries:
>
>  1. The requirements talk about both synchronous and asynchronous
>     systems (1(D), 3, 3(A)) but really only address the behaviour for
>     asynchronous systems. Would it not be worth clarifying the
>     relationship between the intended and applied configurations for
>     synchronous systems (i.e. they are the same), hence there is no
>     need for synchronous requirements equivalent to 1(D) and 3(A)?
>  2. Why does 7(A) limit the scope to IETF-defined modules of others
>     are now defining YANG modules?
>
Good point. We need to provide guidance for the other SDOs.

Regards, Benoit
> Thanks,
>
> Jonathan
>
>
>     ----- Original Message -----
>     From:
>     "Kent Watsen" 
>
>     To:
>     "netmod@ietf.org" 
>     Cc:
>
>     Sent:
>     Fri, 11 Sep 2015 22:16:40 +0000
>     Subject:
>     [netmod] FW: New Version Notification for
>     draft-chairs-netmod-opstate-reqs-00.txt
>
>
>
>     The AD and chairs thought it best to formalize the consensus on the
>     requirements a bit more. So we created the I-D listed below to
>     track and
>     capture final consensus.
>
>     Additionally, we want to use this GitHub issue tracker to track
>     issues:
>
>     https://github.com/netmod-wg/opstate-reqs/issues
>
>     Consistent with Tom's earlier email, we want to collect any issues
>     with
>     these requirements before EOB Monday, September 14, 2015 at 5PM
>     EST. If
>     you have an issue, in addition to posting it to the list, please
>     consider
>     adding it to the GitHub tracker, and let people know you did so. Our
>     goal is to close the issues as quickly as possible, some will go
>     to DEAD
>     while others may remain OPEN, based on WG consensus.
>
>     Thanks,
>     Kent & Tom
>
>
>     On 9/11/15, 5:36 PM, "internet-drafts@ietf.org"
>     
>     wrote:
>
>     >
>     >A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>     >has been successfully submitted by Kent Watsen and posted to the
>     >IETF repository.
>     >
>     >Name: draft-chairs-netmod-opstate-reqs
>     >Revision: 00
>     >Title: NETMOD Operational State Requirements
>     >Document date: 2015-09-11
>     >Group: Individual Submission
>     >Pages: 5
>     >URL:
>     >https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>     >xt
>     >Status:
>     >https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>     >Htmlized:
>     >https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>     >
>     >
>     >Abstract:
>     > This document captures consensus on operational state
>     requirements by
>     > the NETMOD working group.
>     >
>     >
>     >
>     >
>     >
>     >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.
>     >
>     >The IETF Secretariat
>     >
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------020302040803060409050904
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Jonathan,

    

    

      
      Looking in from outside the current problem domain I'm not sure
      I'm sufficiently informed to comment, however I have a couple of
      queries:
      

        
    
          
  1. The requirements talk about both synchronous and
            asynchronous systems (1(D), 3, 3(A)) but really only address
            the behaviour for asynchronous systems. Would it not be
            worth clarifying the relationship between the intended and
            applied configurations for synchronous systems (i.e. they
            are the same), hence there is no need for synchronous
            requirements equivalent to 1(D) and 3(A)?
    2. 
          
  2. Why does 7(A) limit the scope to IETF-defined modules of
            others are now defining YANG modules?
    3. 
        

      

    

    Good point. We need to provide guidance for the other SDOs.

    

    Regards, Benoit

    

      
Thanks,

      


      

      
Jonathan

        


          ----- Original Message -----

          

            
From:

            "Kent Watsen" <kwatsen@juniper.net>

          

          
To:

          "netmod@ietf.org" <netmod@ietf.org>

          
Cc:

          

          
Sent:

          Fri, 11 Sep 2015 22:16:40 +0000

          
Subject:

          [netmod] FW: New Version Notification for
          draft-chairs-netmod-opstate-reqs-00.txt

          

          

          

          The AD and chairs thought it best to formalize the consensus
          on the

          requirements a bit more. So we created the I-D listed below to
          track and

          capture final consensus.

          

          Additionally, we want to use this GitHub issue tracker to
          track issues:

          

          https://github.com/netmod-wg/opstate-reqs/issues

          

          Consistent with Tom's earlier email, we want to collect any
          issues with

          these requirements before EOB Monday, September 14, 2015 at
          5PM EST. If

          you have an issue, in addition to posting it to the list,
          please consider

          adding it to the GitHub tracker, and let people know you did
          so. Our

          goal is to close the issues as quickly as possible, some will
          go to DEAD

          while others may remain OPEN, based on WG consensus.

          

          Thanks,

          Kent & Tom

          

          

          On 9/11/15, 5:36 PM, "internet-drafts@ietf.org"
          <internet-drafts@ietf.org>

          wrote:

          

          >

          >A new version of I-D,
          draft-chairs-netmod-opstate-reqs-00.txt

          >has been successfully submitted by Kent Watsen and posted
          to the

          >IETF repository.

          >

          >Name: draft-chairs-netmod-opstate-reqs

          >Revision: 00

          >Title: NETMOD Operational State Requirements

          >Document date: 2015-09-11

          >Group: Individual Submission

          >Pages: 5

          >URL: 

>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t

          >xt

          >Status: 

>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/

          >Htmlized: 

>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00

          >

          >

          >Abstract:

          > This document captures consensus on operational state
          requirements by

          > the NETMOD working group.

          >

          > 

          > 

          >

          >

          >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.

          >

          >The IETF Secretariat

          >

          

          _______________________________________________

          netmod mailing list

          netmod@ietf.org

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

        

      

      

      

      

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


    

    

  


--------------020302040803060409050904--


From nobody Mon Sep 14 05:43:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2831B4AFF for ; Mon, 14 Sep 2015 05:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbPxHVnRBxe7 for ; Mon, 14 Sep 2015 05:43:31 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9081B531D for ; Mon, 14 Sep 2015 05:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7516; q=dns/txt; s=iport; t=1442234609; x=1443444209; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=o3ZGD4RFCkrvE6sEmrAS2on1NyEcr0HQOHXO0SAH+Qk=; b=ZZQrFhrWo7/MqtUzUYZUw6uaP+AspsJ6LSxPbCVUepSg7tR7f6tEFLAt 15iKilfW6UCl9nYpZx+kXgo+2uLTQq2p2ljLMVfDmSFw83EtNyMht3d+B 65WRltwfKKXNJdm2ZrkXcgdYMfRL3gwibxwF7OMFL3WKLkmmbn1qTT0tH g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQCVwPZV/xbLJq1dg3dpvT4BDYFuAQuFLUoCgW0UAQEBAQEBAYEKhCMBAQEEAQEBawkBEQsOCgkWBAsJAwIBAgEVJwkGAQwGAgEBiCoNygMBAQEBAQEBAQEBAQEBAQEBAQEahnOEfYQqEQFYhCwBBIx4iF+FDYdxgUxGg22CfpIBHwEBQoIRHBaBQDwzAYk9gT8BAQE
X-IronPort-AV: E=Sophos;i="5.17,528,1437436800";  d="scan'208,217";a="611596071"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Sep 2015 12:43:27 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8EChQEL027646; Mon, 14 Sep 2015 12:43:27 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <20150911213636.11309.79529.idtracker@ietfa.amsl.com> 
From: Benoit Claise 
Message-ID: <55F6C0EE.4010404@cisco.com>
Date: Mon, 14 Sep 2015 14:43:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060402000907050800020003"
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 12:43:33 -0000

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

Dear all,

I have a clarification question wrt the requirement 6

   6.  Ability to relate configuration with its corresponding
        operational state

        A.  Ability to map intended config nodes to corresponding applied
            config nodes

        B.  Ability to map intended config nodes to associated derived
            state nodes

        C.  The mappings needs to be programmatically consumable

 From the appendix A, we can see that this requirement comes from 
draft-openconfig-netmod-opstate-01 
, 
Section 4.5 

Re-reading this section 4.5, I understand 6A and 6C, but is 6B also 
required?
Do we need to make the link between a config node and all the derived 
counters/statistics it influences, which might be in different YANG 
models btw?

Regards, Benoit
> The AD and chairs thought it best to formalize the consensus on the
> requirements a bit more.  So we created the I-D listed below to track and
> capture final consensus.
>
> Additionally, we want to use this GitHub issue tracker to track issues:
>
> 	https://github.com/netmod-wg/opstate-reqs/issues
>
> Consistent with Tom's earlier email, we want to collect any issues with
> these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
> you have an issue, in addition to posting it to the list, please consider
> adding it to the GitHub tracker, and let people know you did so.   Our
> goal is to close the issues as quickly as possible, some will go to DEAD
> while others may remain OPEN, based on WG consensus.
>
> Thanks,
> Kent & Tom
>
>
> On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" 
> wrote:
>
>> A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>> has been successfully submitted by Kent Watsen and posted to the
>> IETF repository.
>>
>> Name:		draft-chairs-netmod-opstate-reqs
>> Revision:	00
>> Title:		NETMOD Operational State Requirements
>> Document date:	2015-09-11
>> Group:		Individual Submission
>> Pages:		5
>> URL:
>> https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>> xt
>> Status:
>> https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>> Htmlized:
>> https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>>
>>
>> Abstract:
>>    This document captures consensus on operational state requirements by
>>    the NETMOD working group.
>>
>>                   
>>         
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


--------------060402000907050800020003
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Dear all,

      

      I have a clarification question wrt the requirement 6

      
  6.  Ability to relate configuration with its corresponding
       operational state

       A.  Ability to map intended config nodes to corresponding applied
           config nodes

       B.  Ability to map intended config nodes to associated derived
           state nodes

       C.  The mappings needs to be programmatically consumable

      From the appendix A, we can see that this requirement comes from draft-openconfig-netmod-opstate-01,
      Section
        4.5

      Re-reading this section 4.5, I understand 6A and 6C, but is 6B
      also required?

      Do we need to make the link between a config node and all the
      derived counters/statistics it influences, which might be in
      different YANG models btw?

      

      Regards, Benoit 

    

    

      
The AD and chairs thought it best to formalize the consensus on the
requirements a bit more.  So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

	https://github.com/netmod-wg/opstate-reqs/issues

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so.   Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom


On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:



      

        
A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
has been successfully submitted by Kent Watsen and posted to the
IETF repository.

Name:		draft-chairs-netmod-opstate-reqs
Revision:	00
Title:		NETMOD Operational State Requirements
Document date:	2015-09-11
Group:		Individual Submission
Pages:		5
URL:            
https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
xt
Status:         
https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
Htmlized:       
https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00


Abstract:
  This document captures consensus on operational state requirements by
  the NETMOD working group.

                 
       


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.

The IETF Secretariat



      

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



    

    

  


--------------060402000907050800020003--


From nobody Mon Sep 14 06:05:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7721B345D for ; Mon, 14 Sep 2015 06:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d9Ebz4e_UWw for ; Mon, 14 Sep 2015 06:05:40 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74621B30FA for ; Mon, 14 Sep 2015 06:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2440; q=dns/txt; s=iport; t=1442235900; x=1443445500; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=uFX2KKG6hFbR0LXcRes2BBuFPsztkpXLpz5dAeLszUQ=; b=Kvxj8h2wkyDS5lXCHJx+OEUSRfSPF9fI9Eno53rzE/3Mh9wtT8DLsrs5 Xn0CwedwBp7vhxIihDo+DyArLT3m2e1K6UFSFy/P+tRoZvY5XC61gVnf1 r5fKY7TYUpWZGcQYUZPo8ZJV8BEMLeQzZUM2YfqMnR/dQDjH/USh21LGw k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANAgAlxfZV/xbLJq1dhGCDKroUAQ2EO4M2AoFtFAEBAQEBAQGBCoQkAQEEIw8BBVELDgQGAgIFIQICDwI4DgYBDAYCAQEWiBS2AZQDAQEBAQEBAQMBAQEBAQEcgSKFUYR9hRSCaYFDAQSVV4x+gUyHMSORXh8BAUKCERyBVjwzin0BAQE
X-IronPort-AV: E=Sophos;i="5.17,528,1437436800"; d="scan'208";a="611596573"
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; 14 Sep 2015 13:04:58 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8ED4vDF018543; Mon, 14 Sep 2015 13:04:57 GMT
To: Rob Shakir , NETMOD Working Group 
References: <55F141E3.50002@cisco.com> 
From: Benoit Claise 
Message-ID: <55F6C5F9.603@cisco.com>
Date: Mon, 14 Sep 2015 15:04:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 13:05:41 -0000

Rob,
> Benoit,
>
> I want to pick up on this very specific point. I think Lou’s mails imply a similar position, but I want to be clear.
>
> On September 10, 2015 at 04:40:30, Benoit Claise (bclaise@cisco.com) wrote:
>>> A common architecture includes a central configuration data
>> store that is being updated by the manageability framework and
>> updates read by the subsystems affected by the change (e.g. the
>> BGP service or the interface manager). In this case, there is
>> no other source of configuration except for the content of the
>> data store.
> The configuration file/‘store’ of a system shows the intent of how that system should be configured. We can agree that all implementations need to have this.
>
> The applied configuration is the value of those configuration elements a daemon/software component/programmable memory is actually running, which can be compared to the intent. Essentially, this is *dynamic* information which is the *state* of the running system. Implementations *do* store this. I think the point that you are making here is not that it is not supported. The point is that it is dynamically built at query time, according to a different schema.
You're right. Good clarification.

Regards, Benoit
>
> This different schema is bad news, programmatically. How did I know that the static (IOS-alike configuration):
>
> router bgp 65497
>   neighbor 192.0.2.1 remote-as 65500
>
> Needs me to run:
>   
> show bgp ipv4 unicast neighbor 192.0.2.1 | i remote AS
>
> and then run a regexp that extracts the following AS number after the words ‘remote AS’. Today - I probably need to write a mapping table that tells me that.
>
> The requirement is that we can determine, for a particular leaf - what the intended value is, AND the value which is applied, PLUS be able to “easily” retrieve the state associated with that construct - in a way that is deterministic, and does not require per-leaf mapping tables to be maintained like we might have to today.
>
> The point about identical values is that *in cases where no such retrieval of the actual applied config values is possible* a system can simply make all the applied leaves pointers to the intent. This would be akin to the ‘show’ command doing the equivalent of ‘show running-config | i 192.0.2.1.*remote-as’ and extracting the remote-as from there AFAICS.
>
> Regards,
> r.
>
>
>
> .
>


From nobody Mon Sep 14 06:19:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AEA1B3EC8 for ; Mon, 14 Sep 2015 06:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEeeNwPi4-b6 for ; Mon, 14 Sep 2015 06:19:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E0DC51B4121 for ; Mon, 14 Sep 2015 06:19:09 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id C43101AE0492 for ; Mon, 14 Sep 2015 15:19:07 +0200 (CEST)
Date: Mon, 14 Sep 2015 15:19:14 +0200 (CEST)
Message-Id: <20150914.151914.2175290465760083078.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20150910.125522.373110083925215588.mbj@tail-f.com>
References: <20150910.125522.373110083925215588.mbj@tail-f.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: 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 13:19:11 -0000

Hi,

Martin Bjorklund  wrote:
> Hi,
> 
> I think we agreed that is ok for a YANG 1.1 module to import a YANG
> 1.0 module.
> 
> But should it also be ok for a 1.0 module to import a 1.1 module?
> 
> If we make this illegal, we might run into problems.  For example,
> ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
> and the new version use YANG 1.1.  Is it ok for a server to implement
> the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
> answer is no, it means that we either have to update all modules to
> 1.1 more or less at the same time (including vendor models!), or we
> keep existing modules on 1.0 "forever".

I suggest we add this text:

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

* Coexistence with YANG version 1

A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
and vice versa.

A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision.

A YANG version 1.1 module or submodule MAY import a YANG version
1 module by revision.

A YANG version 1.1 module or submodule MAY import a YANG version 1
module without revision, and vice versa.  This rule exists in order to
allow implementations of existing YANG version 1 modules together with
YANG version 1.1 modules.  Without this rule, updating a single module
to YANG version 1.1 would have a cascading effect on modules that
import it, requiring all of them to also be updated to YANG version
1.1, and so on.


/martin


From nobody Mon Sep 14 06:29:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BF31B4995 for ; Mon, 14 Sep 2015 06:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Level: 
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h60UOcz0qMe1 for ; Mon, 14 Sep 2015 06:29:19 -0700 (PDT)
Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D931B37D8 for ; Mon, 14 Sep 2015 06:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=277735; q=dns/txt; s=iport; t=1442237357; x=1443446957; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7gzqJWf6czQqlL0EZqtuYjbFpnvUuqAXguyy1C9i2GU=; b=mSNnVDMoj4cwIfqC9Ldn4LewtDjWDhzTuQ1EprF3PSirqk6VHnd+t7tT PBcLdAvbWfcTyK9eCrzPSVn8c7iU3sKtA/gvQrLsuC7fV2LZyzT/+8wqR 89YbpmTtJQN6Ej16pkRP5T/LxImIpobpvzbWuMiYDER10a+pgnqJuo2Nv 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBACIyvZV/xjFo0jMfQICAQI
X-IronPort-AV: E=Sophos;i="5.17,528,1437436800";  d="scan'208,217,150";a="24726896"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 14 Sep 2015 13:29:13 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8EDTB7g012301; Mon, 14 Sep 2015 13:29:11 GMT
To: Nadeau Thomas 
References: <80DE07EF-5EE5-4615-8AEE-E488E8D13209@lucidvision.com>
From: Robert Wilton 
Message-ID: <55F6CBA3.2010203@cisco.com>
Date: Mon, 14 Sep 2015 14:29:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <80DE07EF-5EE5-4615-8AEE-E488E8D13209@lucidvision.com>
Content-Type: multipart/alternative; boundary="------------050000050304080003000008"
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Preliminary Meeting Minutes from Interim Meeting 9/10/2015
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 13:29:28 -0000

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

Hi Tom,

Do you know when the follow up meeting will be scheduled for please?

Thanks,
Rob


On 10/09/2015 21:57, Nadeau Thomas wrote:
>
> These are the preliminary/draft meeting minutes from todays meeting.
> They will be neatened up once we are sure what they contain is 
> accurate. Please
> comment ASAP if you feel there are any inaccuracies contained therein.
>
> Thanks to Mahesh Jethanandani (mjethanandani@gmail.com 
> ) for taking notes!
>
> If you were in attendance, and are not listed in the screen capture 
> from WebEx
> below, please contact me privately so I make sure you are added. There 
> were others that
> came/went that did not make it on my initial screen capture nor were 
> listed on the etherpad.
>
> Tom
>
>
>>> Requirements Discussion have been captured in the e-mail send to the 
>>> mailing list.
>>> Tom: Question - do you agree/disagree with requirements posted on list
>>>
>>> Discussing the following requirements:
>>> 
>>>  1. Ability to interact with both intended and applied configuration
>>>
>>>     a. The ability to ask the operational components of a system
>>>         (e.g., line cards) for the configuration that they are 
>>> currently
>>>         using. This is the "applied configuration".
>>>
>>>     b. applied configuration is read-only
>>>
>>>     c. The data model for the applied configuration is the same as
>>>         the data model for the intended configuration (same leaves)
>>>
>>>     d. For asynchronous systems, when fully synchronized, the data
>>>         in the applied configuration is the same as the data for the
>>>         intended configuration.
>>>
>>> Tom: who disagrees with #1
>>> Lada: Who is requirement 1.b. for. NETCONF client ? The example of 
>>> being able to change the /proc entry in the Linux kernel.
>>> Rob: That is not a good example. Take the example of a flash light. 
>>> Asking to turn on the light through some other means is not changing 
>>> applied configuration.
>>>
>>>
>>>
>>> Carl: we need a concrete example
>>> Lou: applied config = show on the CLI
>>> Carl: Lou's example is not the correct interpretation of applied 
>>> configuration.
>>> Carl: A concrete example would help here.
>>> Kent: 1.d Is the applied configuraiton = intended configuration. On 
>>> a sysnchronous system, if during transiition from applied to 
>>> intended, the system simplified the configuration, would that be 
>>> acceptable, or does it have to be a carbon copy? Rob confirms - yes.
>>> Martin: In the draft, for 1.d, the applied configuration may not be 
>>> the same as intended configuration.
>>> Rob: For hardware that is synchronized. If the hardware is not 
>>> present then it is not synchronous.
>>> Martin: Will interfaces show up in applied configuration that have 
>>> not been intended?
>>> Call-in User 13: It will show up in applied configuration. Not 
>>> everything that is applied is intended.
>>> Martin: Maybe it is the schema that is the same between intended and 
>>> applied configuration.
>>> Rob: We are at the same point we were in June.
>>> Tom: Do we agree with the requirements or are they minor edits?
>>> Lada: The requirements are related to definitions. If the 
>>> definitions are not clear, the requirements are not clear.
>>> Tom: What have we been doing for the last three months? Can we move 
>>> forward on agreeing on the requirements.
>>> Kent: We have consensus on 1 a, b, and c. But not on d.
>>> Rob: How can we say we do not have agreement on d.
>>> Tom: Is the general sense that d is a requirement is clear. Are the 
>>> requirements 1 a, b, c, d clear. No negative responses. No 
>>> disagreement on the requirements.
>>>
>>> Tom: Moving to 2. Does anyone disagree with the requirement?
>>> Alex: Will the applied data indistinguishable from dervied state?
>>> Rob: In the draft we say that applied data would be retrieved from 
>>> derived state.
>>> Lada: IP address on a interface can be both applied or dervied state.
>>> Rob: The BGP example of hold time has both intended and applied 
>>> configuration.
>>> Christian: The draft says that we can get both in a single operation.
>>> ??: Need more examples for each of the requirements.
>>> Tom: No objections. But do need examples.
>>>
>>> Tom: Moving to 3. No objections
>>> Tom: 3a no objections
>>> Tom: 3b no objections
>>>
>>> Tom: Moving to 4. No objections to 4, 4a and 4b.
>>> Kent: Will add the word state to derived.
>>>
>>> Tom: Does anyone disagree that 5 is a duplicate of 3a. No objections.
>>>
>>> Tom: Disagree on 6a, b or c. No objections
>>>
>>> Tom: Disagree on 7 a, b, c. No objections
>>>
>>> Tom: Will be taken to the list where comments will be welcomed 
>>> within 48 hours.
>>> Christian: Can we make a call.
>>> Tom: Not here. On the mailing list.
>>>
>>> Tom: Moving to solution discussion.
>>> Lou: Can the chairs share the slides they have prepared.
>>> Kent: Is that there are no questions?
>>> Tom: No. It would help to see the comparisons.
>>> Kent: Sharing slides.
>>>
>>> [Kent to paste his comparison e-mail here]
>>>
>>> Christian: Are both the kwatsen and wilton implemented using RPC.
>>> Kent: Yes.
>>> Christian: Would like to hear from OpenConfig folks on the two 
>>> suggested solutions.
>>> Rob: Would be interested in implementations that do not support a 
>>> particular datastore
>>> Andy: Instead of changing the schema, add attributes. Client asks 
>>> for particular attributes. Would be happy with tha solution.
>>> Aneesh: In the extreme case, the reply could carry all the extra 
>>> attributes?
>>> Andy: But the schema would have to maintain the extra leaves.
>>> Aneesh: Do not want to debate the solution.
>>> Andy: Most platforms do not need this. So keeing it as attributes 
>>> makes it part of the protocol instead of the schema.
>>> Aneesh: So is the solution is for the server returning attributes?
>>> Aneesh: Like the idea.
>>> Benoit: The two suggested solutions. They are based on 
>>> NETCONF/RESTCONF. Are they using it for other protocols?
>>> Aneesh: We are using other protocols. Will share primitives.
>>> Benoit: If the solution is for NETCONF/RESTCONF, will it work for 
>>> other protocols.
>>> Rob: If the solution is mappable for NETCONF/RESTCONF, would it be 
>>> mappable for another protocol.
>>> Benoit: YANG is currently not protocol agnostic. Currently, it is 
>>> tied to NETCONF/RESTCONF.
>>> Benoit: If the solution is for NETCONF/RESTCONF, is that acceptable?
>>> Rob: No. The solution has to be more general.
>>> Christian: Is the intersection of NETCONF/RESTCONF good enough for 
>>> the other protocols.
>>> Andy: YANG cannot be decoupled from NETCONF/RESTCONF without making 
>>> it Information Modelling Language.
>>>
>>> Tom: Need another meeting. Call for consensus on the mailing list.
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------050000050304080003000008
Content-Type: multipart/related;
 boundary="------------070906010909060804060007"


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


  
    
  
  
    Hi Tom,

    

    Do you know when the follow up meeting will be scheduled for please?

    

    Thanks,

    Rob

    

    

    
On 10/09/2015 21:57, Nadeau Thomas
      wrote:

    

    

      
      


      

      
	These
        are the preliminary/draft meeting minutes from todays meeting.

      
They will be neatened up once we are sure what they
        contain is accurate. Please

      
comment ASAP if you feel there are any inaccuracies
        contained therein.

      


      

      
	Thanks
        to Mahesh Jethanandani (mjethanandani@gmail.com)
        for taking notes!

      


      

      
	If
        you were in attendance, and are not listed in the screen capture
        from WebEx

      
below, please contact me privately so I make sure
        you are added. There were others that

      
came/went that did not make it on my initial screen
        capture nor were listed on the etherpad.

      


      

      
	Tom

      


      

      


      

      

        

          
Requirements Discussion have
            been captured in the e-mail send to the mailing list.

        

        

          
Tom: Question - do you
            agree/disagree with requirements posted on list

            

            Discussing the following requirements:

            
	
               

            

            
	
              1. Ability to interact with both intended and applied
              configuration

            

            

            
	
               a. The ability to ask the operational components of a
              system

            

            
	
                 (e.g., line cards) for the configuration that they
              are currently

            

            
	
                 using. This is the "applied configuration".

            

            

            
	
               b. applied configuration is read-only

            

            

            
	
               c. The data model for the applied configuration is the
              same as

            

            
	
                 the data model for the intended configuration (same
              leaves)

            

            

            
	
               d. For asynchronous systems, when fully synchronized,
              the data

            

            
	
                 in the applied configuration is the same as the
              data for the

            

            
	
                 intended configuration.

            

            

            Tom: who disagrees with #1

            Lada: Who is requirement1.b.for. NETCONF client ? The
            example of being able to change the /proc entry in the Linux
            kernel.

            Rob: That is not a good example. Take the example of a flash
            light. Asking to turn on the light through some other means
            is not changing appliedconfiguration.

            

             

             

            Carl: we need a concrete example

            Lou: applied config = show on the CLI

            Carl: Lou's example is not the correct interpretation of
            applied configuration.

            Carl: A concrete example would help here.

            Kent: 1.d Is the applied configuraiton = intended
            configuration. On a sysnchronous system, if during
            transiition from applied to intended, the systemsimplified
            the configuration, would that be acceptable, or does it have
            to be a carbon copy? Rob confirms - yes.

            Martin: In the draft, for 1.d, the applied configuration may
            not be the same as intended configuration.

            Rob: For hardware that is synchronized. If the hardware is
            not present then it is not synchronous.

            Martin: Will interfaces show up in applied configuration
            that have not been intended?

            Call-in User 13: It will show up in applied configuration.
            Not everything that is applied is intended.

            Martin: Maybe it is the schema that is the same between
            intended and applied configuration.

            Rob: We are at the same point we were in June.

            Tom: Do we agree with the requirements or are they minor
            edits?

            Lada: The requirements are related to definitions. If the
            definitions are not clear, the requirements are not clear.

            Tom: What have we been doing for the last three months? Can
            we move forward on agreeing on the requirements.

            Kent: We have consensus on 1 a, b, and c. But not on d.

            Rob: How can we say we do not have agreement on d.

            Tom: Is the general sense that d is a requirement is clear.
            Are the requirements 1 a, b, c, d clear. No negative
            responses. No disagreement on therequirements.

            

            Tom: Moving to 2. Does anyone disagree with the
            requirement?

            Alex: Will the applied data indistinguishable from dervied
            state?

            Rob: In the draft we say that applied data would be
            retrieved from derived state.

            Lada: IP address on a interface can be both applied or
            dervied state.

            Rob: The BGP example of hold time has both intended and
            applied configuration.

            Christian: The draft says that we can get both in a single
            operation.

            ??: Need more examples for each of the requirements.

            Tom: No objections. But do need examples.

            

            Tom: Moving to 3. No objections

            Tom: 3a no objections

            Tom: 3b no objections

            

            Tom: Moving to 4. No objections to 4, 4a and 4b.

            Kent: Will add the word state to derived.

            

            Tom: Does anyone disagree that 5 is a duplicate of 3a. No
            objections.

            

            Tom: Disagree on 6a, b or c. No objections

            

            Tom: Disagree on 7 a, b, c. No objections

            

            Tom: Will be taken to the list where comments will be
            welcomed within 48 hours.

            Christian: Can we make a call.

            Tom: Not here. On the mailing list.

            

            Tom: Moving to solution discussion.

            Lou: Can the chairs share the slides they have prepared.

            Kent: Is that there are no questions?

            Tom: No. It would help to see the comparisons.

            Kent: Sharing slides.

            

            [Kent to paste his comparison e-mail here]

            

            Christian: Are both the kwatsen and wilton implemented using
            RPC.

            Kent: Yes.

            Christian: Would like to hear from OpenConfig folks on the
            two suggested solutions.

            Rob: Would be interested in implementations that do not
            support a particular datastore

            Andy: Instead of changing the schema, add attributes. Client
            asks for particular attributes. Would be happy with tha
            solution.

            Aneesh: In the extreme case, the reply could carry all the
            extra attributes?

            Andy: But the schema would have to maintain the extra
            leaves.

            Aneesh: Do not want to debate the solution.

            Andy: Most platforms do not need this. So keeing it as
            attributes makes it part of the protocol instead of the
            schema.

            Aneesh: So is the solution is for the server returning
            attributes?

            Aneesh: Like the idea.

            Benoit: The two suggested solutions. They are based on
            NETCONF/RESTCONF. Are they using it for other protocols?

            Aneesh: We are using other protocols. Will share primitives.

            Benoit: If the solution is for NETCONF/RESTCONF, will it
            work for other protocols.

            Rob: If the solution is mappable for NETCONF/RESTCONF, would
            it be mappable for another protocol.

            Benoit: YANG is currently not protocol agnostic. Currently,
            it is tied to NETCONF/RESTCONF.

            Benoit: If the solution is for NETCONF/RESTCONF, is that
            acceptable?

            Rob: No. The solution has to be more general.

            Christian: Is the intersection of NETCONF/RESTCONF good
            enough for the other protocols.

            Andy: YANG cannot be decoupled from NETCONF/RESTCONF without
            making it Information Modelling Language.

            

            Tom: Need another meeting. Call for consensus on the mailing
            list.

          

        

        


        

        


        

        

      

      

      

      

      

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


    

    

  


--------------070906010909060804060007
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-ID: 

iVBORw0KGgoAAAANSUhEUgAAAY0AAAOoCAYAAAAtWah9AAAKqmlDQ1BJQ0MgUHJvZmlsZQAA
SImVlgdUU2kWx7/30hstEDqE3qRLFwidANK7jZAECCXGQACxISKO4IgiIgLKiA5VwbEAMhYE
FNsgoIJ9QAYRdRwsiIrKPmAJu3t2zp6959y837m5777/9733nfMHgHyXJRAkw1IApPDThMFe
rvTIqGg67ncAAxVAADpAi8VOFbgEBvqBv42PAwCavd4xnp31933/NaQ53FQ2AFAgwrGcVHYK
wmeQbGMLhGkAoARIXSsjTTDLxQjLChGBCNfOcvw8n5/l2HnunesJDXZD+A8A8GQWSxgPAGkC
qdPT2fHIHDKyWmDG5/D4CDMQdmInsDgIZyO8JCVl7SwfR1g/9l/mxP/bzFjxTBYrXszza5kL
vDsvVZDMWv9/bsf/jpRk0cIzNJEkJwi9g5GrDLJntUlrfcXMj/UPWGAeZ65/jhNE3mELzE51
i15gDsvdd4FFSWEuC8wSLt7LS2OGLrBwbbB4PjfVI0Q8n8v0E2tI9hdzHM+TucBZCaERC5zO
C/df4NSkEN/FHjdxXSgKFmuOE3qK15iSuqiNzVrUkJYQ6r2oLVKsgcN19xDX+WHifkGaq3im
IDlQ3M9N9hLXU9NDxPemIR/YAieyfAIX5wSK9we4AR7gAy5IASxAB97AHYA0bmbarGC3tYL1
Ql58QhrdBTkxXDqTzzZZQrcwM7cCYPb8zb/e9/fnzhVEwy/WspIAYFwDAPZYrEUg33F9HQA0
lcWa9lfkGBQC0HaTLRKmz9fQsz8YQASSQBYoAjWgBfSBMbAA1sABMIAH8AEBIBREgdWADRIQ
3UKQATaCrSAPFIA9YD8oA5XgKKgFJ8Ap0ALOg8vgKrgJesE98AgMgVHwCkyAj2AagiAcRIGo
kCKkDulARpAFZAs5QR6QHxQMRUExUDzEh0TQRmgbVAAVQWXQEagO+gU6B12GrkN90ANoGBqH
3kFfYBRMhmVhVVgXNoVtYRfYFw6FV8Hx8Do4C86Fd8OlcBV8HG6GL8M34XvwEPwKnkQBFAlF
Q2mgjFG2KDdUACoaFYcSojaj8lElqCpUI6oN1Y26gxpCvUZ9RmPRVDQdbYx2QHujw9Bs9Dr0
ZvQudBm6Ft2M7kLfQQ+jJ9DfMRSMCsYIY49hYiIx8ZgMTB6mBFONOYu5grmHGcV8xGKxNKwe
1gbrjY3CJmI3YHdhD2GbsO3YPuwIdhKHwynijHCOuAAcC5eGy8MdxB3HXcL140Zxn/AkvDre
Au+Jj8bz8Tn4Enw9/iK+Hz+GnyZIEXQI9oQAAoewnlBIOEZoI9wmjBKmidJEPaIjMZSYSNxK
LCU2Eq8QHxPfk0gkTZIdKYjEI2WTSkknSddIw6TPZBmyIdmNvJIsIu8m15DbyQ/I7ykUii6F
QYmmpFF2U+oonZSnlE8SVAkTCaYER2KLRLlEs0S/xBtJgqSOpIvkasksyRLJ05K3JV9LEaR0
pdykWFKbpcqlzkkNSk1KU6XNpQOkU6R3SddLX5d+IYOT0ZXxkOHI5MoclemUGaGiqFpUNyqb
uo16jHqFOiqLldWTZcomyhbInpDtkZ2Qk5FbKhculylXLndBboiGounSmLRkWiHtFG2A9kVe
Vd5Fniu/U75Rvl9+SkFZgaHAVchXaFK4p/BFka7ooZikuFexRfGJElrJUClIKUPpsNIVpdfK
ssoOymzlfOVTyg9VYBVDlWCVDSpHVW6pTKqqqXqpClQPqnaqvlajqTHUEtWK1S6qjatT1Z3U
eerF6pfUX9Ll6C70ZHopvYs+oaGi4a0h0jii0aMxramnGaaZo9mk+USLqGWrFadVrNWhNaGt
rr1ce6N2g/ZDHYKOrU6CzgGdbp0pXT3dCN0dui26L/QU9Jh6WXoNeo/1KfrO+uv0q/TvGmAN
bA2SDA4Z9BrChlaGCYblhreNYCNrI57RIaO+JZgldkv4S6qWDBqTjV2M040bjIdNaCZ+Jjkm
LSZvTLVNo033mnabfjezMks2O2b2yFzG3Mc8x7zN/J2FoQXbotziriXF0tNyi2Wr5dulRku5
Sw8vvW9FtVputcOqw+qbtY210LrRetxG2ybGpsJm0FbWNtB2l+01O4ydq90Wu/N2n+2t7dPs
T9n/5WDskORQ7/Bimd4y7rJjy0YcNR1Zjkcch5zoTjFOPzkNOWs4s5yrnJ8xtBgcRjVjzMXA
JdHluMsbVzNXoetZ1yk3e7dNbu3uKHcv93z3Hg8ZjzCPMo+nnpqe8Z4NnhNeVl4bvNq9Md6+
3nu9B5mqTDazjjnhY+OzyafLl+wb4lvm+8zP0E/o17YcXu6zfN/yx/46/nz/lgAQwAzYF/Ak
UC9wXeCvQdigwKDyoOfB5sEbg7tDqCFrQupDPoa6hhaGPgrTDxOFdYRLhq8MrwufinCPKIoY
ijSN3BR5M0opihfVGo2LDo+ujp5c4bFi/4rRlVYr81YOrNJblbnq+mql1cmrL6yRXMNaczoG
ExMRUx/zlRXAqmJNxjJjK2In2G7sA+xXHAanmDPOdeQWccfiHOOK4l7EO8bvix9PcE4oSXjN
c+OV8d4meidWJk4lBSTVJM0kRyQ3peBTYlLO8WX4SfyutWprM9f2CYwEeYKhdfbr9q+bEPoK
q1Oh1FWprWmyiNG5JdIXbRcNpzull6d/ygjPOJ0pncnPvLXecP3O9WNZnlk/b0BvYG/o2Kix
cevG4U0um45shjbHbu7YorUld8totld27Vbi1qStv+WY5RTlfNgWsa0tVzU3O3dku9f2hjyJ
PGHe4A6HHZU/oH/g/dCz03LnwZ3f8zn5NwrMCkoKvu5i77rxo/mPpT/O7I7b3VNoXXh4D3YP
f8/AXue9tUXSRVlFI/uW72suphfnF3/Yv2b/9ZKlJZUHiAdEB4ZK/UpbD2of3HPwa1lC2b1y
1/KmCpWKnRVThziH+g8zDjdWqlYWVH75iffT/SNeR5qrdKtKjmKPph99fiz8WPfPtj/XVStV
F1R/q+HXDNUG13bV2dTV1avUFzbADaKG8eMrj/eecD/R2mjceKSJ1lRwEpwUnXz5S8wvA6d8
T3Wctj3deEbnTMVZ6tn8Zqh5ffNES0LLUGtUa985n3MdbQ5tZ381+bXmvMb58gtyFwovEi/m
Xpy5lHVpsl3Q/vpy/OWRjjUdjzojO+92BXX1XPG9cu2q59XObpfuS9ccr52/bn/93A3bGy03
rW8237K6dfY3q9/O9lj3NN+2ud3aa9fb1res72K/c//lO+53rt5l3r15z/9e30DYwP3BlYND
9zn3XzxIfvD2YfrD6UfZjzGP859IPSl5qvK06neD35uGrIcuDLsP33oW8uzRCHvk1R+pf3wd
zX1OeV4ypj5W98Lixflxz/Helytejr4SvJp+nfen9J8Vb/TfnPmL8deticiJ0bfCtzPvdr1X
fF/zYemHjsnAyacfUz5OT+V/UvxU+9n2c/eXiC9j0xlfcV9Lvxl8a/vu+/3xTMrMjIAlZM1Z
ARSScFwcAO9qAKBEAUBFfDNRYt4fzwU07+nnCPwdz3voubAG4Gg74kWQ9EGyIhsAHSSpyF+B
DABCGQC2tBTnPyM1ztJifhapBbEmJTMz7xFfiDMA4NvgzMx0y8zMt2pE7EMA2j/O+/LZwCL+
vUgDBpjuTjAD/jP+AREFBJCldVMzAAABnWlUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6
eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40
LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIv
MjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0i
IgogICAgICAgICAgICB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4w
LyI+CiAgICAgICAgIDxleGlmOlBpeGVsWERpbWVuc2lvbj4zOTc8L2V4aWY6UGl4ZWxYRGlt
ZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+OTM2PC9leGlmOlBpeGVs
WURpbWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94
OnhtcG1ldGE+Ck5kImsAAEAASURBVHgB7H0JQJTXtf8PGFZBVERAUUGIigENRoNGMSEhVqu+
iP4TY3zELLVZfdXXlpr6Uk1bmzybVvqM2YxprC+1JnF5VZ8+JZpIjBrXCHEFl4gCIiAwwAAD
/M+533dnvhlmhl0Q58I3313OOffcc5dz98/l9OnT9a6urmBTV1eHS+cv4Or5bMRP/REO7dmH
73d8hV5hoZgx/zn8QGH7P9oInc4FLvUuoH+4uBGuhweuXs/DjZuFuCs2BolJU3FX1FDoy8rw
ccoyJL36CvqHDcA7Kb+DsVSP+LkzMfL+OPzf2k8RNjwKQ0cOx8ZVHyH/1AUY62rx5OsL0bNX
ANYs+A2IOTz15q+Jt1ps+I8/wc/bB64ubnBzdaGH3i70Jh6IG9TBFW71OsKpR3298hCnFFIP
8oCLC/FKPNfX1YOT7ELwdfRXX0d2SowL0XIlmnWogQvRdyG0uvpaehN9cpMNtbVGgjeiRg0z
utTBSHhXC/KRf6MAkZT+h2dMwWBOf2kZ0j76FNMXPIfvj32Hr//6OVFwQaG+hH7rEeDbA5N/
MQ+hA/vjg1//Aa76KoqvHs/86TW4e7iLPNH+pH2yCYPvuwcD7hqk9Rb2i6fP44ezWXhg+mR8
s2sPMrbuRY+wfpj18xdw4fQ57F/zOclJRykmaVB66yg99To3XMm/huvFRRg8MtqC7w9//gfM
XPyikm+/+D1q9BWIT56OkePuw46POd+GIory7fN3PsaN05dRQ3J5Ysl8yrdeWL1wmZDrM//5
KyXflqyCj6c7dK7uQr6ulA+cfyLX6t2oDFESSI6EpOQVS0nklQuMtbWEQ1yTXDgPUUdhBF9H
echOAhT5RtmKamMtdITn4kYuCucc5jJNIAKGfTjvXXSc+ZT+WiozHE5/DMvlWbUKfC5zRobn
PCY+qmuorNQbYaitRvJvX4Z/D39cufQDhRlRXlaO0ye+x+H/24/e3Xtg9I/jkfDoRHy5cw++
2bhXlJ9X/vhLuFJZ/dP838PD3RPevXzxszd+gR+yL2Hdm6vxb39eBB3l0Z//7Q948lfPINxG
PmefycaBnV/jXxfMxcmjJ7H1g00goigtuylk17NbL0SMjMTjzz+BjKMZ+GLtThEXy7yO5OhO
j4urDiR10A+ljWRBhuXJZZzfbFwIjtOv5JLwUuQtBCTdFEpkpFy5riqypHAuZELOqp1ym2IR
9F05Q9ibMUnotSTbOs5/ylCu/zU1NTBUV+GV38+Dr68vFr3wH3jzvd/jxo1C+Pt3R0FBAfZs
+xJzX0rG9ydP45P/+gyDhg7Ao8lTERDYi3hyhdFopPLuhiUv/QGPzZuOmHvvxtpVn+DC91RW
qZyUlZXA28cHnh7eWLoyBcU3b+LP//EeXnz1KfSn+rgs5S1UlFTh0bkTcd/9o/HZx1tw8tvT
mPXTRxF9zzD89b/+jotnfsBjP/kXxIwcho+J9sXvc4h/I372+jz0onqw5KX/xMC7QzDr6Zmi
rHCaDZUG/PMfO3HiYCb+8P5/4NrVXKz63V+F3H7xxovEkzfe+uW7cNd5MriQSx3JZ9KTD2Dk
fSOwbcsO/OPjz0lU9ejm2w0ffLKS2lk9fv/zv2DQkFD89OdzcT2/AH95fTU83BQaM5/7MfEc
ha9278fhPd+TvzvJhh7KPM5fzgbO73rKF1e1XnJOch3hNlG8uX2k9sKV4tVtWkuJP3UetVQZ
CBNuVGiiRo3A9evXUVpSgoqqKnhXVgr3dcqsMkOFyAwXKhRcviLiRiD2Rw+gOP8G/vlfa5D7
/XmsOvYH/PIvb4iMKzWU43rBdbh7eZDAKmGsqcZNyqDc3FwUFBWi9nwW/EMC4eLtAT3BciUu
JWVzs7QUNysrRAHIy8sjIdVReIVotHVUGF1cdFQm+c0FlxOv/LlRwmqpMVBaAHqTUX4peWzh
8upSK9LKhVStIxSm4pAMWE4Cjgs+I7EHF25Os0DgxgQwkkIZSIUxJnE8ivMKKP0f4VrmObxD
CoLTX2OsQVZ2lkirgdJdVsGyc8UDs/4Fnt5e2Ltuk5Crm4cOFaRMqVUSjdOly5dIMevwwbI/
KVETM+7u1OhW1sKNGhp3X2/8zyef4vKZ88QXZSIpGHdSbDFxo0RcxUXF0FPh9KioFO58zsty
vWiwuaJyUjnfRkxU+N7yl4+QQ3yvPHwCi95+U/B9s7xM8Kajxr68vBzGyircLCkW9G7Qm/Ot
B+Wbq7c7SjlfqLKXllGelZagpEJPHLtC5lsZuaur3SktriI/3SjfuFC6ueuEoFmBCsMypfx3
pU6JbFhYzgRJEKQ8KBuE+EW+EBYXZPLjMkBNHsmCgbkccJPIeVurerGL85cfguPKQg/nJ2cv
N2eMypVGocfxkMKqqxHx1RNP/NTUkvLgRs1Yjfz8fFRQ+fzL0j+itOgmkXSDt4cXdWq6odxg
QBEpYi7jNykvDNXVzA0uXryIgIAAGOmvxmBEr+6BAiaLZFlC8mZ5cUPH9uysbHhRPm/878+Q
RfWTJaSjcqKr01E83gKvylhFdaJS4Ex6cio1OF7YvnYbSigfOO4bRTcob8qho/hFJ4jk70EK
g2lxh0soDbXRYE8j8SgVtGgsyFPIlmTDhiXLkqzlTFBlrqgcVgckPwHF8mQ5EiR33iiAGyIu
H2xEZ1OEs7wpkP45W4zc/lC9ZdnUkqyrqd1hGeup3FZQh+XIkSMYMGAANe7F2Lfna5Tqy0Qa
C6ht0VeVImF6PKqqDfjP375FyjITv/rdzxEYGEjlvgQXLmSjd99ecPemekby8vH1wdxnZ+Py
+Rx8nXZQyP0mtXXlssyTnLnMG6rMbVUxlfmKSj0KCgtEvKWkdJi3rPPn0TukJzyoHlQY9Kgl
hcT1oITqgaG6HIX5Rfj1wiXw7d4NEx4eh5GjYxE7Phr79x4w8W8gvllm3OZ6eHpQO1FGSqNS
yJiFWkeyKbxxQ8DXkjLs3SOIyptS7zmfy/XlKK+kuleitKs3CgrJTXXOtQrde/nBr4cPcq/l
4sg3x1FWWkFtiSe4neS843Ir8lzkDtdPziQX0bZyZ4Q7Ye7uXtTZoE6sUO6Ut1/t/bL+WFo6
+g4Ox4wnZyk5z4hkTL07ShD/C8M5bG24ptkzDC/DJa50M4423JqGTXhroI50q7LQpseancbS
J3FlWhlf+jWHVmOwWvoS1l48HK7lW+Jq4Tnp9rLdHryM97Z/a8s0J0YpBxYisZCVUFmiIbWX
dK5rSkOt1DtptwWvhbUOtxmmsGcN2qndQpZq+bJOkyO3zTBt+2WVai28pZ0BzXkiXJo8MpGx
yHSTr7A4omcZphCRRUZWHy01GcZ+2nDpr6WnxdPaGc9eldXCWZe9ZT97G14e3YRyYQI6/549
kPDYNKHleFjYIHLBIUHK2LQcm2LShJv81MLPbnPKlFDpZpdIiSSuBItfbTxaeIGjgetwK+eE
Df6JLyFLyZ81jEyf9Jduu/AcwIWLjMRRXMqvtRxtubXwbLdFh7xNfMtwyZt0M641ffYjY8Jl
hxZeBPJPVzCaPBdZouaLNmnatKvyYyjrCskoLDM2MszaLQLVHxmmhZfhdsNssCdxOutbkZXC
nUyXVj7SzhAcrnVbpIkIscq2Fe6IrpIllni24rHlJ3nit614uRpreVL44NGZwrlaHESTK7NO
him0FTj+lf72+JCQpjikRzPe1TVV8HL3ZraJJxqFvP7ThegRGID8q9cwbv9uQUqJQKGqpIOS
SBiVNL3E6xQVNM1STUNeD1rL8KF5QT8/P3h5ewsEhjclVCFhrhSNuNVg8bJohilyS5oWoVq0
jrFb8WfJq8KSVqbsI1Mg/aVbJkD6S7c23DrMRE/lwwRrxZcmVoWsVbg13zIeSc+eW/Jo4kP1
kPBmf0lJi3E72mnqhWRnTlfDNMhwaxitvxbLVuNiD1bi2QpnCTNn2jCu6Lej0aaB+de6tXbr
MFtptYZXYBRpacO0dq4vjt0KFUsYy9ibFqbkjxnWnGO28lNbj9ViKCI141vyoLjMNG2FOvKr
o2lZLlUuYm6YRhoRQSG09lALj4Agh0WL1zcKCwvF3Lqnp6dQFryAVUVzj3q9XszV+vv7i7it
i2hz3bYSYKZhttmCu/V+zA8JVBOx1i69bflxWHP9HeHYCjPTN9vMsTrmW4vhmDaHNjSW+Jau
htC3l49SBbl5tp0uxVeqYSVtWkjLkIZpl7BaOOknoWWY2V+xmd0S8vZ7cxosSyenQaa4OenR
SkPia/20dlt0rcOlm2lJu8SzRZ/DpL+Es8az9LcOZXdDWTCONaSk0/DddMiGuMp6npEW0D1o
ZOMKnQ8t3tXreJHKOmFmZB5hsMLw8vISC7QyhBft5MPhPPLwVkccEqbt3q1JdttxYZuSkq22
wzrStzGZyXD7ed8y7iXdlmEzVl1FLvYeOGVJoGcYRt0dDn9PufxqGWzLVV9TjoKb9egd6EsL
f7W48sWXMI6egPDuDXenKfhNgZExNZZOq/D6ahQVlMI3sDc8RJBG7mQ1j6clfW2zYEWLQBr6
mPG6go3Tp5FQG6S4aRJrGK8tadqiZcuPcW372/a1FVdDClIuTEParTGbQ98aV+um7SS0GM9P
He1WpcVy3qXC20xdaVeFPVNGU1Ji9w7t6GHDwyD5sJt3+nA4wzXPNJYsDpdP8yjfeujm8Clh
G3vbSwXjsdG+bdFSoBr/lbi2IGWYfEsY6bb1ljAtf/NuOcAXw8fGIz6envFxGOx5CUfO5oud
Ok2lXF99AxknC1VwVwSMikUQ7aKxb5oCYx/bcUg1jmd8B4NFLWf5mRWGIs32kalj3jpnqLUk
rLmU4Vp/6dfSN9PS4lq7tWGtsWt5bq5dxuuIt+bStAsv6iLtHKUdW7w1mnav8t5s3mrFm+Vt
G17D4CkpNlplIaF5PpYVB8M1bji5WqN1y9qk9dPC3g52W7y3NF22aEkZyDD5lv6teWtpMc9a
t6Rry0+GtfXbGz60FVvplXsgNGwwzh2spvEClcOKQpzPOIGrtFMZ6Ilho6MR0t0D5bnZuOHW
HcaLJ3HdfwBcr/4gmNp7qBpjRg9C+fVc1Pfzh4+7G6r1+ThzKBMFDBFIo5ihNIrxqIdewrgZ
cP7EWVT76JB3laF8EXlPDAYG+AiaFYVXkHHiHBQWBmBUdITAz6fzTEZfD5w5lSXgBg0fi/AA
4PzeQ8J9mN7DxoxCsIcBP5zLRFYeU+iJwbT/v3+Al4Bx/tiWgL3SZ8/fNpXm+bYn7eZx0jHQ
YgQsVtzZRmfcPHS0/58OQ/FBD3uGF715GsqR4XCGs2+Yvv04FLymwNiPofOG3C7pYkXRUgXX
HtLnjRcVMNC5h4ryIlw4ew4I9qLjBTXIOXACCB+Lhx9+GGNjfHDqcC75kqkrR1bGSSAsFiMj
whEzPIw8wzAmNgw+NKtVVZQHA50DQE0JjpPC8I6Jw4MJExDrfwNH0q8IGiYYkkVlcTHy3IIQ
/+CDGBfbF1knDuB6FcmotgQHSGGEj5tAPExAjM8POKJoMBjLfsCZXGDshAcRHzcUF06eIcXi
g4FjY0jt+CJmTCz6+Lih/BopjNoBiH/oYYILwbkTp1CqHGfglDiNUwKdQgK82M4HDPlgLK9v
0Ekf2iFA81Q8V2XP8FoFL3o7UhwcznD2DTdGUmlo7fYxbs+Q2zVtnZFvPTJPZ1Azqxjf3kMx
ZkAfcRCqf/w4OsBYQbv+CnAj/yp11IeKw0qgE7kIG4WIIGVTRp2PUia96AAkHTEzFanaqpvU
kEdiZB9fPuOGXgNHI75vPaxXOowU+6hBQbQIyED9cc+Ac7h8owJ9aLQSP24MKitu4mp+KfFB
g5XBSh2iM4GIvDtUjGag60FjCJpSI/F6ePkQfXcxeuJD6+6+fUAn93D8VAUG9OmJsfEjQLrE
aZwS6FQS4LUMRWEoXUo68KecAnegM8ROKd4l5UZTUGJroGafl9wqyMf2fbp1I70gFQOlWwNn
4c/Kg9uozmo0STCxKNJCAdZhDdKhgRFh/KPxMxEkSwNcTaB1PBzkCF6D2sBqi5YE4nSJPNMA
2c23VvAg42vWuyfiRo+Er3V/pt6Ai+n7caPfIAyiU+kDPaqRd4HXQBQR+dJpV2mEyKTWkZ6m
N59MVw2dHjdW0zUkfH0Li0I+bJWioTcNzOlkOPW4qgqQvv8k+kUOQ0jvYLhXX8JFhQWVIDuI
D60s1RD58gwIw4T4ELquogQ3rp/HKRog3TP+PgR4ygglZCveWlItLT+tiN6JevtLoJauZeDB
Od9qIK4aUTSIsjpuL3l8DoMP/rFiYMOKQj7sZv8aehjO0mhLrGVI27vaqEY4YtlWmPDjhpdS
JB9T4lSebOEJGDs824U3EW47i6lF1JK8lQxo421oV7eGWwbUVeMG+UQOCkOgvzcq9UUi3KLN
lhgsYn01qsRec+lJ1yd48LrEOVwr4SlVWse4dhoHDuZqxiIKrA5lyLpyA7UkkpqK6zhyARgQ
6IM62pUFhGHQwBD4e7mAZs9oDGGTA4UQ/4oFxWJU0nUxzFbhmT3Yd7kcfoFBiIiKQT8a+5RW
KXXMjOS0OSXQsRIQTYSrWrZpsK7je024ANNyuF3OeBst35lTWFRk2kXF95XwlBQ/rFA4vMF2
W257BHFbjRAHsFHDbIFwsBUYe1kYEU4/Nhs/gpT4FkiNO+RBGTmSMvHJJNXeozmscXoCQvbq
Tb1Pe4lW6RHvvPBkiofBW5geyWGTeJfx2JQpM6DhW2OVcYi35LOF4cpFenzBog3j5o2wfr44
kb5HBAb2CybFQApAH4ze5OOuQXLz6YUBvgdx4MtyxD14t6DHJd3FI5DWQsJw4Eg6qQ42gbRT
a4CYnmJ0c21wQU1hFr7M/k5ABQ+mBWxaHHGpDiC63yJ9zyXy90Vwv54ozs5Caf8RKs9EhdOu
fdy60eWUvji5fx8Gj3kQoRGj0G/fEey9Ikij58BoDLK1FdiRDJsTZg1rlZWtLVtKKpy/XU0C
dK2dUuPV8uKybNZPRfUurSzHkvUfOExvJS1I8rZacSKcpqvEiXCakuIRhlAY1oWQqcmG0pqy
qeFUA2w2UGqYPRqSpqNwkToJ2NibgCUfkj+tW2tnUiY3O7h5Zy9NzbSmwWBaI8OFn8RzwAPD
NSs9KkJzeBK8cDwaPqSfICcZUPmVbGthpN0ejaaEy2gkrI0338LKU0DUf6Eba8lOmzEcsWOD
BCHWiQv4XAWuVZrr9Di29xyGPBiLbrTVkHapi7gEHTVtvEDI8QpFQ6MZvsVWG247Tst4lHTw
DkY73NvxVgqczRhUHuhlhcudBosyqqILf2tgB6SdQXeOBH71k9/TbcN0KSPdwOxOSxQ60aOi
OQB5JbIjUbBiaDCaUBHastA11htuWPDNNaMxXEfpEzWMGwNhiKaZbKNoXIGbCm5BrEFD0SIq
FiQdOqziayhLh9iaQI2cVN/GZN8wLnNaG8PVRGyy8vkiaVyo4W6R4U0g9lBJoRTTH18Qzjd+
qupARMOpFzfkEjLzzm6TwiC7CBeQrH8VWcnGWrg0jbdMh5CPg1JkTcca1DpcjFI1QDJcxKMt
B8RQyy+ZUBPpfHVZCYjyyjunqJ7wJdE6/qYAL3CInmULky0KoT1cbeG0B2Plb25KrAJUZ4Nw
jYfGahu5Kb5WPDtMH9MzKRrbxGVllaGy8TCNVGRAk96chW2SStGY2aVkJYOmsGaXlooswrXs
axA01qZEdWtg3HzpYOEE0JEOYawbW9kom/KzFVzZL2NagbUiAgeoMh0OQJxBd7AEuClwox4S
X99O+0VIaQhh8NcK6pGVleVYNJqGRNsQmis82VSHdQUTDasGv0FDaytM+nGjLO3MoSO3bMAl
vEhgUytew3gsME00BVEzTzJO5k3CSD61fhJOwqhkpMwY1GHaZLgFgsCy82PFpyAvI1VQRHZJ
ftRwi0bQlqy1sWlwTXkq/WzhyjCmoQ23JxttXO1uJ9lo+bOKT1umtXYGc+TmMDZSrtZuEcg/
FlnDDqqk9NconkrAmq4tnhhUjCrMlVbBtohbJeh8OSUgJECDCm7aaZ84Fxvdwz+bi92pH4mC
FDN8uCIkUYDoR1YgazdDyUquYCi/El4Emwu7CNQ2EOyhdWvtAtjqxzq8MbcWnWGFsa4lWiBp
16RZesk3k7FHwhQHw2iApL/WT9LjtwzX+gk70dCQMQVLeEnPOmnWbkZkHAkv3SaCqkUTbquh
kY2WgNbS09qtabLbOtzKbR2XBQmZFgvP9nZYysqaP61baxdcOUgbw7KRcmyAK0LVHwbV5L0j
WEdhTM1WuC0/EXOHyFvE7Pzp5BKgD1PSuh8pCyN1YdxoxMEFuZYORBkttiS2vgRpyn3rRKJW
uMaIcGVoV0MJshlHU+K1xZpDPFsI7Zo6u8RbnI8O02eOzqZMzcG32GY/tTb51GaTRvE2xrR2
/YDp2qTdGJFGwiVN+ZbgUnGx2yLMftIlqvN9h0qAi7ko6vQlRv4CpO7tlCUI69OXVvHMhUiW
H1morN0sO+lnIUeuAKoHh0t89tK6Ja4Ml24VtQGe8Fdpm2Ct4pKVwUSzGZVYxstvia/1YzvH
y491uIkfBmJjxZfqyd4WpgGeKVTE4jAeyYNCw3znv223Jc8247XiWdJnlgQ3KvMSV4ZLt2Rd
+ku3FtealnTLUZDElflIXBOIdQyScvu9JR8yBkduUdqt8lXi8dsRrqmiqAgWsHZoWsBoI7JF
QxPuCE8bplVmGnSn9Q6XANdCvmZK+UwzjTgig/qLesuV1bqKNua2JUstjtbOsI25JT1rOHv+
tuDMjY7E4rctSG24tLMM7NRYFaQplGzB2PKTsSpvLYQjPrRhCo51zjV0O04Tx28Zu33OrGG1
kFoa0t/az9ptgmuhkpf4bfVWZGcpL3ZJvmWItVsbv3WY4uZfpVOl2BQMc17ZoqysaWhpt53d
HHPb0XRS6pISoALLt07zdSJcE3Qe9BF1ca9UR1da0ZvVVqdmil925dV0cA+KqTXfaLFkRXZE
RcJLWOm2xtGGs90enMRzFO4oTOJr302Bl/xp8aztTMcKrtF8kziSB0t82dOVyt7kto76lrot
eZUuZkFrt3RbhzSEZR8JJd/mZFn7SDe9NSJjX3YyJVZBSjmXXR2Jo1A1w5pjcdqcEmiuBPgu
W67mtNGWCl49dDRNRXtv6VAUezTLaAuoRJbFtKmErOElHS2+Nh6tvy1YCleVhxnLbNNiN82u
5a8xOs0Jbwy2ady1LVRTebKG43yQecFhbLeG0bq1doZUcKWSV0ItYdo2nc2h1vF8MAfK+ERR
FMy95MqkOFQZmlWSOY0S1uzjtDkl0DwJ8AeYhKE3lyedmxvdwEanWvlakIZGKbJmf+m2Lopa
t9ZuxjTbrBsVCa8yZqoSZgzbNonHoRLXGlILYx3WVHdb0GhqXLcjnLV8rN2NpUmBby5WY1S7
UrgtZSDT5yhMwjjfTgm0RgI8eWOqn3S6j+4DpVun+ANMJl9JXnrIt7W/dDf3bU1P4tvzl+GO
3q3BdUTXGeaUgFMCTgnc2RJQRrTm7onYcstzVvTR1ztbMs7UOyXglIBTAk4J2JCAsn7Gn8/g
h5c0yMZzVdreutZug4bTyykBpwScEnBK4M6QACkJoR/44imy63Qu9PE+2krlysMNp3FKwCkB
pwScEnBKQCOBerrhmQcW/O0lNsqny2ilQ2511MA6rU4JOCXglIBTAne4BMTOWh5t8O4pcuiU
8YVyg2FzZVNbchlf7T2A7IIyBVXnhyGjxmNcTKj47nJz6TUd3oDjW7cgL+xhTI4JbIBWkLED
Oy8F47FpsfBqENq+HkaDETovnVUkdE0L3d+io7voW2uM9E0TioBoNaRkNFIYpdg6zFBSiBtl
lXD39qOPZfnTh+E1hhgzfSuOmfQifE2wtVV8vZHv1NcE2Eozw7VFejXRtJvVoCf53KyEt18P
+Pv7WqSt3SJtCmFDIXJKPBEaZPd7tU2h0mQYQ0k+ShCAIH9t7jYZ3QnYVSVAgwodX1aoc6VN
U2JNQxly1Jump5o4TVWTh62f7iKFAQwbMwGJCeMQ4VeJswd3YNfZknYXX8XNMuQVV9iMp6qi
BIabtsNsIrSVpz4DL0+dhOR3DllQ1J9ei0mTnkGGnrwJ5vnERCQ2eJKw/9A7NvxV2KQ10Av6
UzHpmTUotIiBPrmbs43ioLCX19FHQ1VjyMG6V5MwdeYsPP3005gzayYmJS7A3ksSQo91L08i
PPWZSvjE16vvbEO+SZNIYvwuwdrHJuGZNRkmTxEvpXnB5ixLP6K51zYRE5ylRY81FPc7GQ3L
jj5jDcklCcck25aILXcZ87Hh9WRMna7IZ9bM6ZT+ZGzIsJZuy6NoOaYeG+bNwlvf3MDpdc8j
kfLfUjIUnpyIJE1etCSu/Ixd2HYsX6Aaf9iGOTNXNihbLaHrxOk6EuCRhvhGOL15Rkr5niZ/
AI1PiFsshjtOtOHaOZC+wPDJMxEXSmc9yIRH9kPV6k+Rk3EBNUNixaczRUATfmpqaulTsuqH
C5oAzyD2+kOhcU9gXlxDIrX0WVqKpP1GQcSQN0WbvWkxNiRswawo2UP0MDOjMh2/YAVeGd0T
lcSSYtzRu7cXPv74X2hEAHy3ej6WH5qAle89CT/Bdw/46i4qoLnrse/SHCSFmcdRJ/9vgySk
vguxZt7TWJ87GotXLsDYuwJgLLmEzW/9Est+8iLcN6zD+AACZd2amIKP540AKitRfOk41ixN
xZxN5/Fx2kKEWlD1R/QEP6z/8hT0z8XQR06BnBP7BUTmVxkwJEWKkV2e8EvEsCB7OWRB1OTw
oE/MV5lcZovXgAeQsiAaEVKc5qBW2PTY/Is5WJ0ZjZQVb2BCVDDJJwe7V7+GVQtnoc8nO5HQ
TP5bwUwD1JKMv2F1bjw+SQpD0TrOJI8G5baafFsrkqL05UitWoGpI4PgGzMH80Km4q1dj+GN
iZY534BBp8cdI4F60ho8lOCpKb65gT7CRE76CKz4EFMLxGCsqSQsRWkA/ogdEwGUUu0nk3d8
B3acrUJoNwMu5SlTWIERY/DIQzHoJiAI5tQ+7N5/FjyxAl0wJkx9BEMClcaw4OwhfPHNSZSp
vd7AIeMwacKwhlNO1KPevW03cowD8ehjD6H25FZsuxyC2dNH4eaRrThYEYqQkhM4macQCo2d
jMmj1EpRU4D9O7/AKZW/0CERKLlcjvFPTKMGMw87/rEVxqjJmCbhVb7tvSrhh9GjgdXz38a4
tEVWja6CxU3AoKFRCLDRKIWG+gug/v360Ls3+gdRZVbQoAgJiAgBNm3+DkkLVc1ovISt63Ml
lHjnf72aFIYfFm94AwmsHNgERCL5jQ9RljQLS9/ehZ1L7hfeIYEhCA0IEvbQ0DCkbghE0qyl
+OzQU1gYJ5FFMIY+8Aiw/QCuGGYhyoumCdMOI4QSnHv4K5w3JCHGy4hT+w+TIlqKIGL40IZU
vLk6DZz7IaNn49eLnkMUJdGQtRmLPtHj0XtvYFnqGSzf8idwIyhN4bENWJDyD4xd+h6eDb2A
/03LwuDEOHjmbMbP1uRiUuQVrFpP8YDyeekbeG68kp/5hzbgN2+uRjZFGJE4A+EXv8OQX/4J
SZEmKYooDFnbsSoTWPDhW5gYpiq3gDAkLXob+rxXcPp8HimNUGRtfhOf6Onb3Rc2YG3Wg9i4
bg7OOEjTz94G/pSapOSZ4TRen/cpHl+9BOF527Ao9TzuHXwdazcx335InPcafjFrpI3OjwF7
3t6EiHnvkQyBIsGxdSdJR2qEBq5qGBcOe7IGjag2r3wDq7ZTgslET1mA1xZORfHm1zF/E/ss
RNL1l7HujSRMWjgFq1M+Q+HEhTRR5TRtJQFlPoepmW0NaVvuYW0Y3jE+rDLEmjevh5PSEAvh
/OHw5hqvoEHg1YRTaRvw18+3Yv+RDFzMK0JAzEOYPC5SqBFjRTmMZQW4VN4HidOmI3FUGAqy
D+LT3WdFdEWndmArKYzesRMwbXIChvjlYd+WLbhMGqQm7xC27DsJr8HjMG36dCTEhqLg7H58
y4HSeHpSXbmIz9ftwKWyYDwy/SH0osFKVdlNGGnqigdQxqpywjuCUxiMidOmYUxET+Qc342z
pUykHPs3biGFAcQmkmJIjMWNs9koM5TzIXnGBi8TVAk7uxs3FeiDJ3/xR8QjDa+uOWYTwYd8
v961E4cOfY2vv+ZnL77OyDGvLQgsVi0NTQWi8cTzs5G7fT2yVGVacnIz0pGIl2dHA9cVnOtn
v6d2aQZGN6j5AUiYQYr9xBVKvR0TcA9mkGLad/RaAwD/iHupucvEyRyK3HgRO6kdevbl5yj2
THx7npuwPOylNnFKQhSyNizCYlIYcS8vxYrlKQg4vB7zn35HTH8Ya/TITF9LCuMYpsx9AgPV
QZOntyfN4K3DrJTVCJj3W7w0PgjGyivIzDyAIo6S8LIPb8Kqb/tj2cqVWDAFWL/0LWRRPhlz
dmHO4tWomLAA7723HCMubkJadjaKKhtm4MUDe4jXGYiXCoPzmtd3jN2QnLqO4lWUUI3+ItLX
pmLttUjMe/Z+5DpKU2URsjNlE8+iMyIr9wQqme/KYkrDdqzd7YWlK9/DMhoKp61OwbJdOQxo
aQznsTMbuG9YsOpPJabsFPYdOqSWl69x6Os0HKB+glSFjmR9ev1vSGGARpzvYeXSucjcnopf
03RiYOwkzKAig+gZ+LfHYkRnzH9YIqnh7TjZGWboLKXSKV2sAsQdYI38KsrCkcLg5DUW3kEi
IGVRT9ttmTtWa2oXS65jKN5NYs0rFNPnPYmLGZk4k30Rp44fpIcxdRgyYSomDAkkO9UWUi3T
qPcfzDNPwY9gWu0WbD1+nBTDQOQcpQrTczjGRQ+kq0yAex8Yg7NbDuLk+SKEDuyHMWMCMDAm
Et1o8dctoBcR4ArGDYAbdDS4MZz6Ev84WYYyXQRmPfMQulOIMBwXwYiX8AjDjGnjaBxEJnAM
vs/egavF5RhC9M6JHuk0jArvRoGhmJFQjL/vJS3Cxj0U0+bNU+xN/qXG3j8SP18+A9NTUrDt
R2mYJAdiKg2ewsrclIrFopenekbMw5b3Z5kaAfvRVSL4nh9RI70eW48W0kjAH+l/246QeSsw
1GONCU3nwQ3NVTHdIxsWGVh6lVok3/Ea+cgQ81tMqJFObmD8h+IRGkgeOJOHmbojyCZOhodS
JyGeetjfXsFzfa/gMKmVZUN1+OrNTITMXoFFSTGCzFsfVmPST1Lxv6efQpJK+OX3VtMogDWG
Hh7E6K5P/hPb0tMR/fJKpCZFqVCCG9N4lnvpy/70EuI4Yf0XYs32FSilonZ+70bymIJU6kWz
roxcvgy7Zy5WaVi/KJ9C/Ewy0Gd8gOkLzRnCfK+jKTjFTMEn7y+kXn8J1iQ5SJNamyxjspR+
yntLQHoQiFqEpRfTsHTdXugnJjfI9wpKY/QAicsl5jCWL+YRiqUh9U+mBF/9wz5fo6q5A1KB
m9RRGj3mMXzy3j0o8wuGf1AkJt4bgt3VCUgYGSko8Q93ak5fK6ERqqgxJv87yaI038rvnZRu
W2mlZQwyypbbetc66HiBgxc6WIcoD9sbN4aSPORX+iA8Jk483JiXF+Xg0J5dOLtvJwYOTKYK
SRP2XuEIMLfe6BHIjf9lWkO5iSIeNBhOYsO6kxYRlheXwW1YDxgLjmDD6r0WYRYOIykM9jAW
oZC6zd253W9giAedD0ztX10tcyW0paE4n9SaHwaHmhG79elHoXnKEk8DWk3zqKF0+Y78KVLi
N2H5/HUY+gel0ZPYlWSZvWILnouRjYIMacq7AkZS2P9vdgheWH8UL47ojTXU23/xtRh4pzFl
xRi5ofDrLnsF0lu8fWg6CvpqoX4tAkyOclyjXuxAX26srI0/xpDW2HT0BI4Wf03TUMmigb5r
QjzKPjqCjEFXCeERDPUswHrKnLH3hZsI6IIjwI1ctZEUv44noxJxv1AYCgjruVxSGGwKz+ZR
3kTZ4J/xiL4UHfUepBWUZr8ZD5inVfzDEEfQVUzQ2ojIruIm+TO+b/gsGp1MpM1jNdj7u/nY
pcKzHP1mJIppIhgKkOEwTdaRaN3M92gMZm2mmrvGJwKH2N+W8YWPqd4UUl7OxZbNWuVCmxiS
pyt8NsJX1Jw3MC/nd1i1+AWs4qgiErHstQVgNVHJ0Vdx5041xhqxzGWqL9K/i77lZZBdNHlt
lCxSEPTPFxeSuqAT4Yoa0RAXGkTjtm3NP7oVu7buQQHVf8W4oVuvgXho/DDhZOJircNwXVRM
4aSfilLeA0Jdb9ce6MUdzNAJmEe9eeVJRuKYMRg7oi9yDv4TR7KNSHg8WQl7drKyluGm1CQq
29CFJdCUwTT0RDHSth6SU/4yqkbfXj16E0wZLlwjjaOakhxSaMRfC2bsJAn1rcPEny9HRNla
vPDr1eTH/TfFcL/PRmuohjb+qqE6Hjk1mYYr7+Ld1Pep1zgb91NjVCl6lAp++P0TKWmb8M/T
PGWkMTTPvobWP0KmxiojLxGk0wAA+V9vpAkK4IG4UAt/6YgYMxVIp5HS2mwamSmjgaDhD8Mv
dy1+sywNEbPj4e/lh4GEcOUyN8uqqSqUs2eKh1+gaW2LPaqvA/GLP8bGlXORm7YMHxyjxtKm
8TSNELTB3PSV7T5unucvuYRD5GerAbwrbhqFpOGfh9Q4fAMQGRmJ0FA/8EDMpmksTaLtrTIp
Y+ONyyDdqxruOJxBvrmoQUwhkq+pCklQQUePEpvaTgJp3o3wVULrdXELViEtbRuNMpbRWCwN
i+d/YpaTVkCkhLmkNjVqDRdOaxeVAC1jKBNn1CjyUgZtvGUPpYlvTpr7xowi8AJs+fsOnLqc
h5KSEuRdPI7Pt54if9rpI6ZkuDHKw5Yth5BXUoqCi0ew/SBN/QQOQV86DxAxuCfNOO3DnozL
KC0vQdaR3Ug7eBB51PtR1hToXVmF0qLL2Ld5h1AKVTQKkUbnSZG4BWNy4hBqLU5i5xF1WkkC
NPb2D0UEsXh21w5kUBpyso7gn/tzzFi0SL77H3/FjubSlRR8R+K3ixNZLwnDIxw2XCmzTn6P
S5eykJWlPKdPX4JeNBYCxPEPwwXdj7khZdielo34F39k7m2rmL5RSZgXDayd/yI2HyPaNMVX
mHMMK+bNp9WHCCykBVhpcnPOIOvSJWSdzsCuda9jzlKapol+GY+EsVZvaPwHx4oRA3VZMeZu
tescECWmrTip4+/n0UUQ7p/hh8Opr2Lb6XzoC7OwZslSEkU8HuaVcDbmrBRO7vQG9qazElGz
sTieFvtTlLUKEUg/Un7Sbf1WFOV6/GnzMRQWXsK6JYutozCh6MISaSRIcSyehXVfZwn5lOST
Ql3wNDWplEeWg0MVz3GadN48ZtmEnRn5MJRkYe3vUpmSZlqtDIvf3IAcPeXF6W34DSvvGfdp
lLcaDSmBUOL87DUrha8GN3w55it783z8ZOYyZORXIYCmEu/qa0mhLOMEsgrNG3q5UzO87507
NWUpHadLDCxIcfB6Bt87pRNdNt5BRf+KMVmkh823e2AsHk+sxY6049ivXczzC0Xi5IkIpAGB
srSrQ0/DKTrToU5B9YzAtCnKdtzguKkYV74N+w/SeY+DSjRhoyYiLtAdtR5jEXh2L/Zt/VQE
+AWHIdjrEi4d3IaLd80Wfu7qqKNb+DhMCCPFQru1Tt31FLrzggfrKwWK7CaH9IGbwO2Gh/51
OnT/sw0Hd20VYcFhtGfqUomqRqtQQlu3Kita3u8KSngF8/4njbZ2esNbZYMnfQ6vXkyPiFL9
CaEdROswktsdNjx9Iu2Kj9WvLyY+m4i1yy5i2v2hahjjyNbOF7Pe+gQeb9EiaMpPlGkJhgqh
qYlPFpji8Qggv/RVeEGZFWIAJM5djBeTE+xH7xuB8RG0tRjjMdjEYwDGTI3ApvXetD6keMb9
9D3MK/gFUufPATefpImw+MOfI4zkIJpDP+Fp+mHOlX66Dgk/X4H/SV+I1z86hncTGIQaX5mN
VniSgG9UMj5cXIafLEvhJNFurURSa6wCbBkvTFyyEXhnCZYvfQFrVRA/2uH18uwM7FQVGkfp
q+mJO0oTIqdgQfw/aE2FtvISXsjoaBKSnDJklRhNE3Lb8PR0JeP94ufhreQYNWbNSxeKhNHA
xlO0RhQTBXcuCzaM1tsRX2HPrkDisYVYOEdmMueDsn7WN3Yi/NbTaPgn1di4+Tna2ZJOo6PR
CHbqDBsSvzO9eDJKXCFCQw4+z+fyVvKC+ppaI26Wl+LNzbLqNE84BsKtpjG2h3c3eLm7mZBz
9q/DjguD8XQyzSxTT7eWNJSXlxiCmGCEhc4hGIiAG40+NOgUVEto1L+kb34IurUER06bNCwp
Ns1VW4Lj+7+DT9R9pm2+JWd34NN9N2iqPhnhtjvaTaPdiaCMBj3Ky0nx6brRiedbnyiO32DU
wde3feM2XNqLj74AnnpOVXj5e5E4ZxnmvUdnZqy23FpkD/FXSPLReZJ8msijozQZ9HoY6dS+
r+ZmAP3pNZj+aw9so3UJHcuDJlu14Rb8kMNweh2mzr+KT9IWKesp1gB23JKvbpQO6+5fDcVb
5TAfjNi2YBI23LuS1kuUaUc70XQZ7862ptEZN92+NOtX6NG9Fzw9POiOQtqExF1qVx528MRV
C41Xt+7KeoMVfi0pIxiqxP77bqwQrMJNTjpw50VPQ8NKxqyEhPLQOBvCN9PHTYeKy2dx5OxZ
/DAsFj1rc3GcFmARPAYD2rd9ayajrQPXefnSGoNpSNA6Yi3A5vhvRew6b3fsXr8Um7b9D6ZM
6Int29Opcz8PUxwpDE4P8RdgSz4OqgRPRdlLk5efjZDaUhpeeaKKaHo5wJXi9RqWhLndpyP1
y3/FGwlyJClD7b8d8eVO8TaoZZolTMOlrUjNDMGKN+8MhWFfis4QSwnwUIMWMXjIQZcWurw1
Z0G9sZ5HGmV4Y/PHlrCtdJXQGsZ3hQEYOyq8YWFtJe02Q6fKfPb4CZzLuY5y6oX1jRiB+2LD
bSrBNovTSajzS8CBwuj8zDeTQ43iaCbmbQ/uHGk0noWvPLkI/t16woNGGi70hVe6RoTERlNL
ivC49LRdbfEPH4UJ4Y0z1aEQbt3pksUJ9HQoF87IO5UE2rYedKqk2WDmzkqtDQE4vRxKgBfC
xboGrX2LxfA62qZUR4c1avnAhtM4JeCUwB0ogTt4qHEH5nazk0yf6xP3TtHQgo8i6G7yVR90
4E1Pl9UppqMLUNuNdJotnHZF6Gi52kscy1v2NZvCo4TX0uuqeaZNo9PulMAdKgEeZpC6UD/c
B92Pf/Ecqqurcf36dZqZ6iSVvylt1+2Uf0KsnUS2NuUmeZNvm0AaTztwXSTfOBl2UqiRgdPq
lMAdIgE+y0eVQlxcSElu/cHndpFbF2l9hGy6Uloay+w7Ka2NycIZ7pRAV5IArWtQT4o/wiSP
S3Wl1DnT4pSAUwJOCTgl0EYSoCUNMrQEXquuaTz7q7/T0IMu8aspx6OPPqpGc4sG5zIa6qBa
zIyJOTQZ2EYp7zAy1onrMEbaP+Iukm+8k5C/G3CnGN4d0xkPld0K+Su7Rm9FTE2Lo1Pmg7pH
SlnToC/3PTNtECmMGro7qpQO0nWSE21dpPFRikn7Kw3tpZMd2th1kXxzKo2mNXBdAcqpNJqS
i9yJolGGG7dlpDTi7rsHNdVVuF5Q0BRsJ8xtKAHKarFB6g7qPLd5LmkVc5sTv8UEO7RjcYvT
6oyu9RKgY3ziG+EutKDhQndP6Tw8eHThSp/O7iSjjNan8Y6mIBu3Bg3DnTPb0ur8d4qq1SLs
UALl5eV0y3Eh3ZTNzZ1j05KRBl92GhAQgG7dzN/h0cbSnPi1eGxvyvRUY/Fb02ytm9c0+OFZ
Kjeao9LtPpxFn9CsQWHRDcya1VryjePLXq+ApNrprKCNy6w5EA2UhURmwTuFLaXh8O0UlUPx
dOpAbrD5+ICfnx969OhBF1w73uvTXKXBxxP4MxAcR58+fRooDhm/j4+PiN+TP0ndDNOY0jDQ
xa+O4m9GVE0GVT7Sp5zmYnnpAv296bvIOtTXND7SaIvKJNqtVjRedXRh1nVDPbxJ8/l7iWX9
Jie+KwOyspCjDOt0tlbm1vScbqcEOqsEeITRvXt3MRJoDx75/qXevXsL0hyX9WiD/VhhsEKx
24FrBWO87syKiJWWrfhbQdouqlBkovEnlcFrGvcM7qcc7uvuWCMzxVa09XYZam4AD5EO5hlR
QAfYH4/Uwd/TqThk4ZTv5srUCX+nS6Az1Oy2yQOekmKl0Z6G6xmPZPR0Bb61kfG3Z11k2v7+
/sjNzbWOvl3cPLqgLinR5jed08i/cZ6UBk1PFRe1S4TNIWrqKYtdOKSkbKzcupFfNzcXbLxW
jbv8XTGhL13rToszTtPeEmiLcWZ78+ik75QAfazZ5mcW2lYyjqadHIVZc/HZZ5/hiy/oIzBk
eJ3kxRdeRP/+/VFRUYE///nPyMnJoW/Xv2eNJkYbDTzbyUNtjoXCEEqjuCSfpjWMKK/UfMu5
kcjLq2pxvsiAokr6XgaZXvRJuoieXvDTfvuiERraYNbYLJxr166hku7AYsbc3T0QGBiIsLAw
oVWlAmE9EhfihsxiHfbkGDGyjyu6ezCG07SXBFhdiI4G9zQ4A5zGKYE7XAKO6oErXR/eFKNV
GAzP002sIJYtWwYO4zYxNNT2t1Qcxd+UuJsDw1W+jus+Hwfn3VOD+t+LGmM1vHSNb7nlYcrG
jBKkXynH+esVqKdvGbNxranEyGB3jO13EZOixhHdpgmNcXlRZ+/evbh48aIQmtFoFB+EYu3G
Q8CBAwdi/PjxGDBggKnB6u7hirHBOrx11EDTVPWkNJiS07SXBFhNCMWhvp1qo70k3VF0naPI
jpC8HGFo42bFwSOMc+fOCYXx7//+79rgDrHzNlt++FOvQml4ePAXq93o+8uOF8J5AfrNfXnY
f7kCtToP9PLVYXBgLd2QC2Tm6nAqfzcuXt2EM3kjsSBhSZMUR1lZGdLT07F//36xuBQbGytG
FW6kqfmw4YULF3D06FExdzhz5kzTAhRLrhdtSiitqacPJzUuR6PRQEBelp8KJ+VkIFwv9ZOc
rKwaGPaicB3DkrXhqo8AEHQVfHKTHC3hCNdA2pk96ccizEifGS28icoad/j1DqKF/QYcNMuD
eVBYlrGQmxPJ8QoGiJxIt5HcVvJoYkxG2r3h0kLcJkbhEKykMB9ltJ7l1yOAPs0q0+kQ5RYG
0iHZogr49PLvvB8da6Y0aspLUEHfKPTv1pafzGwmE20A/u677+K7775rQIk7wlrj7e2NFStW
mLx4mujq1au46667TH7tbdEqDF5U72hjrK2jcxokJ15QJr2hq6MrRJSHfeybDRlF+PKCHl40
FTRnhB9mDvWnnr8Cb6DFp//aexZHc27gm4t7MKBnBP5f7FP2iVEILxidOHEC33zzDQYPHowx
Y8aIuTzONP70bEVFJYYNGyZgDh06BH4SExNNc3l6I+2gorUNL3ocGT19a3n6/LUE4oeUjz/D
xFCloTm9/mXMX5uN2Svo+9G6zSpMQ0qzV2zEfd+mYOH67IaB7BMyF3//NfCkiIPcEXOx5f1k
9VOgBmx7dQpSjyg8Mq3nYvwFndPbVuDXqdtRJlzKz+gZi7H4JfX71tDTd5qnY63VWldIRDye
/eUCJEQqdEzoxiy8NukFHKZ0Lv7kMyQE6VBy7APMTNlESZ+BDZtfQgABH/vgGaRsyqWvoL6H
1FmRJvTGLDwclrIMmb0C656LsUQxZCB5ygLk+j2JjZufgxV3lrAtcOnp+9/LFi7DYY3AQkbP
xRtLkhHaSmXbAnZsohRlbMfGg73w5NMD8Y+Pd2HQ5GSM0zBnuLwH63bp8OS8CbC9w98mWQvP
2vIcHM8sxeBRw9D9FrTjtTe+w6e7qjBr3iNo3+Vli2S2ucOWwrAVCU+PS3PlyhWsXbvW7rqC
hGvrN09J8QijMygMTpsYYJC2kOqV1pDdyJMf+1NKuaXV2Ha2RBzweDYuEE/e7QdPnQs8qMHm
p7uHDj19elKPuopXr/HFma0oKMt3KEve77xv3z7q+Brx0EMPISYmxrSvmReyeHcAK5OEhAQE
Bwfj22+/RVGRslhfRRdnnSioRWQPF/Ru8jboMiz/3XqUmLjiERYb7QEgP0RERyNafSJCImi9
xg3eQeEIiSD/iBAFhX6FOzoC0XcHmfyEJXsTDudzf5+M/jy2Hlas2t9L217HfFVhRMdPwZTE
0dTUA4c3LUPyiq/FaIHhPdROhoyLYXKz07HshZnYnGW1c0MXhoTRDFGGE+cLGR3ZBw+IN8oO
4LTwKsHxA4oWeiAuVAlrwi8XFrkYxuA2+z66npgxYwpmPBGNJmdJE+IWIPl7kfwTRWH4RYzG
lBmJiKCk5h5ei6cXbSD12glMbR72HCzA8GljhULgb3Erh8s0nRr6Jj2b1rT1dcUXcPzkIRRb
9PE0cYgY2u7Ha+BYDPe6hD3UabyTzJ49e8TaAq8r3ErT2RQGp5078dxpdCMVwXalFFOAoZIn
YGybry7qcYPmgYJ7emByBPUhrcsotSq19CEnXgCqp2FMkaEQ+y98gekjnrRNkHxZaeTl5Yl5
O3uLPYzMOwrCw8PFFJbc4nacFMY3ebX4l3DecmvNjN0oqRVdi3d3JWDRRDsNZsQTeD91VkMC
kYuwbip5G09jwaT5yEQEUv6Sihi1h8s9cLMpw65vLiEhKRKF36ejwfiERgSpqekCfMrST7Bw
vKJ05v/rLjz29HKUbV+KrUnbkBQmKWrjKsG2119BanouVv1xOx55f5Y6omFYHYYl3EOaJx3H
Dl8CxnvhoKogqHnF4awSjO+WjW+FzohHLPeADTnY/O4q/G3fYZSVkcKMn4oFC55DFGWxIWsb
fvbLNDz0b49Cv+u/sL7yCfz9ecmTUmwOrXkdH32bBe+hz+LNF8NRdOUyriCalJ4Bu1aQzC73
xIMx3fHltu3EgR/iZyzC4uQ4UeiM+cfw1m9WIC07FyGjp2BiZCl2feuJX/9lEaIsRg40Wktd
JkZkfvEp+GzJRKXQPvsoXp06H4cz9+CcfhZG6rKw4mev43L4RDwQeAGr1hdjxZZUhN/Yi7dT
P8KhTEq4XwjiZjyPV5LHk9xUHs8Em+LMotHf62vOIOmPb2FG/3yi90ec8e6Fvt5F2Efp9AsZ
jReXLCJeeRxlWe4KTu5HsW4IJgfTAluNC2oIws1Nqk8F1p06WlpTevk49uw7ggIxe9oTseMf
wahwpg3kZezB7oPZyrSoXyjiJyZiYPV3+O8dZ0X4ro//G7HTHsOoYCksS9piFYoU2Y7PDiP4
7j7IPHiSaOkQOjwOYbUXsP9UHtHxwpBxkxAfpZw7KM05jl27j6CYZzT9wvDgjx9CeHd3RI8P
w8m0oyiNub1HG0JwTfiRawpNAG1TEG4HZ9EJ684ywjAnTpzUUKaoaLxhGl54Oris8IeSari4
e6I/neX46oqe1jHkQEUhazBW4oY+l+bJ3cUBs3rXOmTfOGOO04GNe2M8b2jabmsFyycg5ZCR
YfmztGdv1mKgnwvup8V3Nx47NcOkLf8dMqhS0OashiZ7G96k+Uye01yx4k28/uY6XNLqUl4f
UE2N2Sq9TO/Dm74Svd+TO3eTHzXGITwCUIzh0lFSOmT8puBJUhjcg+fHLfR+JEUoMEVlNGLT
GHNc/kicw9qLTEUhLKGA4BFjxYgl99g5FJZk4zuhIBTwY0ezUZLzvaLE4sciVKfHhp89jVXb
SWH4jsZoijs7fT3mz1wB7lsZa4qRXZaJ1bSTYz3PCRVWK4To19u3EhmbX8Xi9aQUr9Ma1osJ
8DKW4dvDmTh8IJ/Gbkbkn8lEbmY61q/fjoCBRJzXr9Yuxk4h0HysfCFFKAz5uAYtAABAAElE
QVQa2iEgZzvWEq3c7ItQN+SZ4gKlUu4GnzrjfkXhGPQoqeqLRRs2YMOGP2CwaDcrcYYUUGba
WlIYrJQrUVP4NV6kEUoaKYw+o+PRpywXaWuX4sU1xyhc5VETZ03xGeSWZdOuQB59Mr1sZGce
RjqNFuOjQ1CWexjLie8MMbThOmB+ivKKoYsYSKMMxY9HGlfOZSAr6wzOnqUn6zxOZdNwT8fh
1MkqycCGXdRA9xiGxMmJGNajDMfTPkVGEZXxouPYSgojeEwipk+jkXZlDvZuPIAav4G4J6In
YbsgLPZeDPLjWOwZqhc1VSgpy8ORg+cQnTgZ44b4IYeU2/4LXkicNhmjwoCz+7/AZSrjtSWn
sGHHEZpeHYPJkxMwEJeQtmGPGJl3Cx1M6uUSckrtxdW1/HlN4VYbqTDeeeedWx114/FRka3n
nVOkLlhhuBbmX0JxwWVUVdnfcmug9QMXGkXoqKd0IrcSuy+XopqmiISh16nckziZc5SG3W7C
i0YwtGZiMX5WYDW/PNzhxdni4mKxGC4VgwZEfLucF8KzsrLE8IjhXWgaLba3DnMGe6K3dzMU
xuh5WPZyPJHPxvKVe1EqNgBoY2M7NSrbt2O7eNKQnrYJRVrlYBqXkdKxRiW3X3QiEqN53uRL
6tkfw750amwjpmLmxKEmaGOlOpni21tMY7CsxEPVclC4Mv2Vk6uZuCdMbVxeocOoL08m9ztc
U0lJ4rqgYYgTYUexb89XQkFMWbAYM4hs7ncHkX7glABNnDAMyPkSq3kYRMrr43Vv4I3312Ge
ILwd/0c75MxmNJZ/sg1p65JN01KZq2mNZxW1pCGE+9lChHGjTbIRE340d8WlQOrkGcs20sjq
fSxNVNKWTwrRmH8K+ziJIbTW8n4qUtd9jCmqXtWmVfBgKKDGlm0hGNLXV3id/igZvDFiJvXK
uGf2t9MKv3LCccbSD7Ez7X1471tHOUpZMHs53n9jCd7fsJSokCzW/w2nqaGUPJrjlBRENEp6
SNortryPJal/xYJ4ZpJGaxe18mFYA27kqfVBQRXKrSz7CO0M3CemYffRDsGDpwpITkodyc38
niBDMWPaOISHhmPctBnkAk5kkspmnUXGUFENN1IUiY/PxMTJNO3XLRDDh/WlED9ExQ5Dr8YW
p5WoEJbwKGLDQzFs7GgqZUDsFBpBBIciNu5ectWImpqbeZTsoRh/31DacDIQcQ/GkvsSbWzh
MZNSBvOKy4W9q//wtHh7G+4oS8MKY+7cuWCFYasdlHAd9RZT03QSXKxgkNbQ+foHoLqqhnYS
WVcEM4t9/XSovazH1WIPRIV44kQe9WCqShAf2gPdXEvwf2c20bW5BM/1hhrBmiojgny5cNs3
vG7BR+15zvDAgQOIi4trMCyro1HFV199Jbbi8vZbPkLPA4vhvdXaYJ98wxCakh2R9Aqm/C2d
lMIy/E5tpCwAqRH78O2n0NNIDZsIoOkvpZ2yALPnKEM4Jv4Y1LNNo3WHFAE2etIDGOQiWj2F
op+6BpJ7AXSwHZEmRVSOs99zE0dVN6SHeNv6MeScUkYqIbQNuQFvVOmpcU5Ly8SqVTye8cM9
1FC4Z/phEynAVMGGH+KGBcNwPV+Qj5gxSTRWoAmbe8dGY3Um45lNxOwnMTJIdOXNntKWexnX
qR0JVWZUpK/mHYF7acMEm4B+AfSrpM9w/YKYbop4MF4szgM90JvTYqkrGY1mUIIxLIJm3WgU
cZKn2AL80fPepzCDaJ3bvQmZhOOpQCq/IbMxZ3yYaLRVNYb77lMbgYBRmEq0VmdXakY0pChM
eaAlpNojxuIu5q1eh+h7afqPdvt9++0PtKEhxhKYlaanmRMuP0MmJmPCQLPsanL24eMdqkao
pcY4eJBmw4A/BpHW4DLhFjgcE2NvYM/xfdh4ch9R4mmkR6j3T4qECVNDz+iNL44o02SeFsNq
LwT6qfXHu5tQIkxRkVUOtpIC15qqKhph0u4Zjs6RmLQ4t7udF6F5TePTTz9tl6TIg3tMnBXG
Sy+9ZFIYykRQu0TbYqJihxkpC74enZpfuHrSWQtPb1+afzX3t6ypDw/2ho/OFddKqMCT2vGh
3tIPZS74NCMHK3Z/iC8yvqBekQgSCyU+tIJ7dwj3VOwbvqmxb9++YlqKhcgKwtqwH5/j4Dev
bbRqro96bUZqoub9dq6IhmZLGhofP/QmLeFPcXF8AdRANauiVHogIm6i6M1K4gkTqAGrrpRO
eIXdg3jhSsfbGzNM/vmHPsd60ab6YVAfc0PD03bV9PC75uZ5rFn+gcDxuzvU5g6cqPEjTTSB
e3BXgC/uGkmNnTR+EzCMdlbpKM/ZZH990rSQfOVioQKldC4Vu41fv+gpmB3PffZMpLy5jfrZ
9o2PDf3u22eQmEbLpqmrLG4E9RdptGqPhhfChyqjlE0ffQ7eYxAal4SXfvpjBNtC8fEwtaVG
Ve45l28okMYcnMiWSLWg5pBMJi5zS02m8KqafuFSf2j6SsVG0Q/XhOfQaNkh4iqkGiJRWVUl
XaKRNQ0ZVF+aXTUZYc27CnPf3YD8PA6uQy1tc/UcFI9n5s1D8qzpGDPEm6aRaEu7VtA25Goi
brJwL46NJmJy0fJjA1NbS2XUbzjt7JqHp59+Fs8+/TgSxkxAdFA3Uk50CzZhKFJqgNolPR56
6CEsXrxY7Ohs6wTKHVlahSEX3G/FKKe56VEOEnJZp4dniMrK81FNt9yWV9qoMCr1+/r7YnyY
Hruyy7HvfBlGh3nCpeo0jpzaiHNXv6ZtuJ7o3qOOeny0EE44cQMfxL0Dxjrkjaea+OAeL4aH
h4eLg3yMwGc36qh2+fr6kSJzEyMQPvgXFhYG3o7bGsN1xT9mNlLiN2E5Tx1ZG1oon5641sI3
eu5KpCZHmfzMzb/Jy2yp0MPTf5jamyVv2uoaF6AD3XiiMaF4LiUR6cvTkLl6IZL2RGOodyEt
6CqtZggtFvN2WbPJRsr0RLOTbC4ufvi3Z+JtKrSAqNGktLZDNG+j7kUQZYjLMM6LdLF2EhJ/
P8RYJ/JBTMFqbM9ejf94xwOJfieRmsY8ROO+wTQ6uGIRpYWjz73T8FzyNGQkvoDMw6l49+vR
WDjKAkRtkC39TK6g4XjED9hUloYXJqWZvG1bdBj/7CuI2L4Y2dnrMWfSlxgdH4oztNBgIwct
SIQ/MAlYvwrpqa9hDZKB/e/SlmQyo2diuK8/algZ0QhmTepKlN9bitUi/RYkyJGG+a8GIjnq
Ov62KVsE3t1PDq1ko+yFINJg56xRrd2ahj5o0CBaUDiFPYcG4KERIbhOC/pnqVUeFtEHNTcO
YeuubNrYMB33hfdAcG+K76yaWqF5jCi6VoS+ob3gXleAfdv3wy1qAq1Z9LKOscnuvjwlc/Yk
vsnohweHBSH31DfYezAHCYOGoBfxzf2Ifj1Jgdym5p577hHb922zzw2ikpcMJw1f57Fw4UJx
TkP6tfbNCoO3/7LC4BHN+fPnBUlu2zjuxx97vLVRtD0+i0eVD791hUUX6ES4ETdL7U9PMcoz
IwOQed2A61R2s/MPorZsNcrqCtGvny9NTdHWWzqlzeseQd36Ys7onzKKQ8M7rXhrK98YyVNV
vLbBCoTXMLh1u//+cUKwDz/8sLiYi2+T5Bsmm29UnADZA9Vh4oLX8L/pKWKaR/G1T7fSon+l
U+e5rZWXOQ6eSnjwiURaQE7D6CcmiumHayrTkoPQiYvwoXsgXlu2nhZ/afFYhNPuonmL8KtZ
cQ6TGEE7jZ575SXEWSgWDUpAFB6ktpBHLaPHR8OdMzx4MFjtpJH9wQeHqsBBmP/JMpT+YjHS
N61Sprz8orHgD68jhgYhcrnEm7ZTm42aTtGDj8Gri6dgzjJaA1r6HqZtmWEGI5vNJSP2F+MA
f/z045Xwe/dTnKIF5D73PgDPo3/DJpoZsznI8Y/DX4jX1N+8KRbPD9PuMV7jmDL7buxbn6bS
tIheOHwjk/Dh4iIsJDmvT10u/Phsx+/UHVgjkpIRsn05Ldhvp2k5PzH64aZZ5pOk6HtmPVZ9
qzQqUxa8ZzrrI8P5HTI0DMa0bJROGCjOM3DPnDs9DYwqTq/QcZg8qgI7juzF308qUKGxtFg9
kBvm+zEuogj7927Bqb1KWNioiRhAA1A32v4d6nUWR3ZtRBlPf/WtEB9Qq+xVZkNp6GiEQFsl
1a2+DXhRPWjmAe7BcTQlVoRdB3fg44NKQMSYaYgkdsov8i6uQDrgZ49C5/d/4YUXbDKpHO4z
Kw1rIJ7daMuDfTwVLxUG0x4xYgR69epFxxUMIp7OOD1FB/kUnUHTU9Q0w+V/d3xGtjoU3CjE
U8kvWsvMwn21tBZrj2XgTM4fUW64QMpCmdKqozlPT3dvDO87Ck/f9wqC/ftZ4Dly8DmNjIwM
8D30N2/exM6dO8UUV3LyUxg1ahT1qoWac0Sik4exlO2lwQg9Tb9V0dX03ehcino4/Zanx6An
Hmrd6GyMMmXVYga4RIlZz0Yo0EHA56cuRHZIPJa/9SsM153Ca7NSSHlGY+W2VKstt5a0mNfy
KjRTXgaSMyF5doNvAyHz9wmqKMgsf25IXKoysYB4zIyYh220tbmGyiYNIwnfkh+zqwBbVm9B
yPSnERdof6rXDK/aaHHCUFMLN/oImru1jlHD3GktzzJIW54MOP75Oty490k8Em6vVed8MRvr
OsVTn6bGqgE/tUT/I2SGTEbyuFAzkU5q41mJcJq5aKoRSoPrpyi7TcVS4GzFZctPS5UPDFpP
tcstvnzvlCkftEh27I3FZQet2d4vz/4Vuvv2gKcnrym7gVYqaEpJLHJoC6Jtuv3oCOqvHojB
ubwU7Dm/A5eLsgTgwF6ReOiuyRgcHA03ItocwwWYF8RZefCbp6fqaQ2D7V3f6MAbEVrZVLda
TF40VWO3LWw1dRsEvGKwgHayzV+VjpQ56SaAKSkLHCoMBhS8NltgXiRneyn0ImVpI8xINz9z
hNf1Ymtzd1Lqjk0gJowKxMadxzCSzqI0WW1Qx8vL3nqizTCrelpzA8W9RuF+mwrDUlk45l8N
tYqzpuA4jhR7YeKjnV9hNCl9HQzEU17S8KiD1zJYkbDhq06GDhkqDjtLmE7x5u229PBaGG94
0vFHNYSWbWL5YqUQFTJCPG2RIB7C9+tnHpkEBdHZBVIafn7du8Aooy0k1DVpRCUtwbaH8pFz
7TqdiPBGn/5htONOOxXWwen2HYa3N3wCo66bmGJsSvXoFfsIJvrdEOs5TVYazUqmlcJgXPdQ
amSsG/SmcNvEiD2CMXF6FAa2T4KayETzwMTIye7ovnm07EFzHPZMU+Pn9Q2t4bWOk9+dbJLS
cBS/lmZb2blzz7uneJ5Kx1tYxeDURnlsqwibQ4evD1GGip2EoeYw74RtlgS8/IMQSU/nNDQC
CbAxAnHIbDcM5EWADjP2G7KWsuTuHyq2+rYUvyPwamhjT8vWP5vOLa9B2DNVtIuOjwc0Zmx9
J6Op01OO4m8s3maHC2XBE8+sOOj7RYqVl8L4cRqnBJwSaNK6TIeISenpWUYt/VqjMLpOB41n
LnibfnNMS1JfWlpqc6NDS+JvDq8S1l78MrzN36Qe6l15BYiuEakw3EQZXUmhryxu83icBJ0S
cEqgPSTQFopCy1drFI6WTsfbeZGZN9UUFBTQLRdVNGnRdmljWtzDz8/PFye3OS5rw358qpu/
4c2wtzp+a37axM1aVd05xdLUudV7oY4+wuTh1uzVxTbhx0mk80qAC4jNXhhXRBtzxnbhO28S
nZx1MQnw1nw2/DEjecGpoySKnXJUlpvTuPNogr8qKuPS0pd+HD8rr+aapkxPOYq/ufE1HZ5a
Aq7gVPdp9xSzSfu5dZ5Nx3dCtpkETB0hyhObDXSbxeQk1HQJONVf02XV+SC54ZaNd2PctWbL
rT3azYnfmkZTlIY1Tru764krrhJqC6Xr0XuAuKa8Wr2LqN0ZcEZw20jArhKzMcrgRNmFv21S
7GTUKQGnBBpIgBQGHeUjw5qDLq4tK7pOH4uhe43oA0o8B9gpjOh+d5UmiARtp5HtFLJuSya6
SL7JKQutaJozfaHF64x2h4f7OiPD7chTe4w0WsNuZxxp8NE7/kY4G27KdIeOnRQH63g1/l/p
et5OYbpI46PI0qk0OkWZagYT3J+6U/Q8i4UVYmdsrJqRZS0GFUpDjJE51zvetGc+8OI8H2lQ
zlzY7pTLDoW2k8SQ7Obzc/V0/ZOOv7vNX9Fjgk7jlIBTAiwBoTaconBKwCkBkgCpCvHHnwS3
+NyrUzpOCTgl4JSAUwJ3lgR4e/APP/xgOtvSo0cPDBgwwOJwohh90KKGMkWl+Ub4nSUqZ2rb
RwK2h7ztE5eTqlMCbSWBzjE11VapaSod/o7RqVOnxPKExOHbxvn+v6ioKNP3i3i1wIVuMldG
4LTl9sPFy+mb3/Sd7moDHn+84+9yV5qdrtT4UFp4PlDmShd+t+d8bBcWmzNpTgl0iAT4okS+
KNbasB+HDRkyRAnSrnlRc6brGxBEu6foiu7K8lZumeSGXjaNXanRtxZpS9zO5rQlUnPiOCXg
lED7ScDRdSsWYTzUUP6JGRppdPPyoW9sGMXKuMJeaxr8luGK3Rt30naV9isHTspOCTgl4JRA
kyRg6xPbEtEiTLbN4k1rGnzNrbGObqMS+3Bb1ujLiFry5l1bZ8+eFSc4+Vp07TXpLaHnxHFK
wCkBpwScEmhDCZBa4MGGuNaWFIcrXVxIhu5eaeXkVEtZvHbtmvha37Zt28AfJXEapwQ6XgK3
vvPUsWm+09LbsdK+3WJXznWQ4qBzGnX06VddHekPsqJeDkFucYr4FDpfLFZUVCQOndzi6J3R
OSXQQALchN4pU6YinR3UYWwgeKdHp5SAONhHOkKeeKXzGnQ/uljlEEOOW860p6enqYLyrZAW
c2ltyY3xEl6ng4yJSSuQ35Z0G6Wlx7qkRCStybABqcc7xNOKY827/58J6TPeQWLiGuhtUHV6
tV4CvHVBVBbe+daFH55lcJr2k4A8fS1PWrdfTO1HuZ5GF0JnUBS8iuHqIi6iEl9jar9YHVD2
8fERIwyumLym0V6m5Oj/QnyNumw7dp2+xU0t3Tpv++J5LyQsTkHiwOZ/7c3L23krcXuVFUmX
FUdX+lMUhHWKZGqd7+ZIoClKQMLITod0NyeezgDrypqC/vnT4Kw/XPmb4Ww66rt9PXv2hK+v
L63I6xAfH99OU1QG7PloE0LmLkVKIrD202+g3Z2cf2wzFtBogK9USUx+FbuyzD3/wtPbTGFJ
z6/AsUKJacChDW8iiXHoWfDOLpixFJk2/mtA9qG9uFxMn440ZuHN51/Hrr0bkKzSfH7FNhNN
Y2EGVixIVnl8Heu/ygL8ZAz2ecna/CYWrFhDuAqfya+uw6GvN+N5ybcmDknN+e6aEuCqrlb3
rpnAW5wqVgL2HlussPK4XY2LqxvpCPqQBi+E03UiVJJIg/AUVQeY7t27ix1TzEyfPn3aR2kU
HsGqbGDWxPGYMGU2kL4OJ9XBhjFnF+akrEJh3MtY+eFKvBx5BstfSEEGt+P5ezFrfiowNQUr
Vy7DI9iOlFkrxfRW1ubXsXj1IcxYvAIrls7D5U3LkbLO1hSUY6HmHzqMHyprAUMlLmanY/my
bZi6lGguno3s7an4pxgVFeKDnyzE9suRWLryPSyb4Ym16w8DfTwEcUe81OgvInP7epSOXYaV
y+YBh9di8dK/YfzSlRTHDApLxecZzVd3jlPlDHVKoGtLQI4e5JtTK+0NlcPtraq5babE0RQV
TUvRUINXwclD/HdILvOaRlxcHNzd3cXuKb48sa3N6bR1RHIKRtPsl9dd9yMaufjsy0simvN7
N9I7EW8tSkJUWBSSlryHl2ePh45uiT+/6yMR9sqsCejffwTm/PJlcm/Hl1nX8dXfDiNi7mtI
GhuO8FGP4rfzIpC9Nh2FgmoLfnQKTuLSVMwaH4OYhDmYSyOJMmMtjDlHsakMWLByMcZHRSIu
aRGWzwgBxB2TJY55qa4A4hdjyaw4RMU9iqmE5jf7D0geH0VxPIvZFAcl1WmcErgjJcCTdW0x
/mqoKMxKpONa1zbKUlIYdXT3VC29OZ06oUVIborw2iiSZpIZNmwYYmJicPToUURERCA2Ntbm
R9ubSVYFz8HO1TTMQDbmJG43k9jwBQqnPgdwozplIsyrKUFIei5ZwJ0GfwM4DS9MTzPjkU1f
lIVvqRHPXpuC6WstgnCZRjABthcwLAFtuIgTBPrLtQojpPo0FF+hkGgMDVY1C7mGTZwIbCII
/Q8OeXEnWL/A3vTLRqHpa5qcM4LHKk6lIYTj/LlDJcBqw57iMM+/mG13npiUq/Pl9JSOhx3K
0ljHicLb2xsJCQngMxtffPGF2EHFfjdv3kRISIiYvvLy8mrR1JX+9F4aG/jRvP4fEe3NzaYO
NVe+wPxl67Evaw4iOdn7vod+4UhlsZp2Wa157R+IXvAL+FTTuCFiHja+PwueBsYsxNF959Fv
2N1iPaHvix9jycRgUBCMhedx+JQRw+wqDHOD71jSNFVlZXR+vcgnE3k0ixTJeoxMXsZR4iGG
VtgH4D4aLdjj5bwCbvdXKia7AM4ApwTuYAkoCoUFYLZpxaGokq6tUOQZPl7K4JkqVz6fwUnu
6GT3798fkyZNEoph165d4MN+8mE3377YfGPEN5+upU76U5gUE4mwyEhERoYhKmE6TVYBq7Ye
wYDYB2kOaC3e3nWaGn89Dq1Pxfr/z963wFdV3Pl/k1xCEhIChKeAgGD/YMFWtwhVtIuCZQtu
RbuiS5G2SNG19APbllapFGxTXXQbtpTWLoKl1CJ9SB/StfxRFHzW4tpCxf4JL0EeQoRAQl43
yf/3m3N+58w5d869597cPIA7cDMzv/f8Zs5vzpk5jzf2oaA4gks/MYUuJ1ZiNeEQiWL31iew
cOlivNdYjJHXFWHb0kfx0n76eHztUWx8aC5KV78daOKRQ++gfP9+lJeXq9+uXftRJXvqgVwW
Im/waFxLxcXfXov9lbXgzfkHVuy09zSSt8XezkmgNYPOeCDjgUQe4KnEOumO/Rs00SSS2eHw
9uRgfVWDQmEzb4TzLVTc+nZM2fRFqMsvv1zdRcVPhnNw5Vf37t69G3v37sXw4cPRowefcSeR
anfj13Sf7eTS6+gqQU8luGn2SGxc+SscvudRlM48RJPBXGxeyjRFmEmbxKPyqDhsGsru3Yf5
hNuocMAtCx7DmGLCzV2Ome/PxeK7bmUmYhuN0sc+DWbzp1y+Oti2AneTLW7qh6W/+ZG2PBRB
ASFzIzkOSS5dtVhLRwPwlccW4PDdS3HXrTQJUho6ki4vKizSMXFs8bab5JOS3rkuNLM8Zfkw
8zfjgXR7wAqp7RxY09AonjOyKD5n0aWGmhofmvnvzY30KtzK6jNY+jRv/LZv4o0W/ijIzp07
sZ/OzI8ePQr+UMi9996LIUOGtJ5x0VpU8RIU3f4bE/gFl0c4N94qW6K1VWp5im8bbv1EbyOu
qkXEYAfrbltbWr+1GQ0ZD2Q8kD4P+D/3+tprr8UIV3vcBOU4PHbsWIX/9xnfRFFhN+R3yqP3
TuXQCTjfPcU3UbX3+pQyj2Y0Wi4bNGgQevbsiePHj6urDJ40+HmOVk2RPHpeJEBDHBwH8CC2
AGktAEfUMy1BAtrWliArMvCMBzIeON88wNdLvJ9BUwXdPUUzBxrpU35wl0U6QoO7dOmi3nzb
t29f9aEQ3hjPpIwHMh7IeCDjgbb1QLOaLLLQSBMGzxJ0pUF743SVYb/utm2tCaGN75rKpIwH
Mh7IeCDjgfbxgFqE4j/8cF8O33jLSW1y8HSSSRkPZDyQ8UDGAxkPaB7gqYG+Ea52MqhIr6Ki
p/1oBqEH/jIp44GMBzIeyHgg4wGPB9SVBW2Mq3uneFWK3znFVx7NmVnD46hMJeOBjAcyHsh4
wPJADu2Cq41wuuqgt9zSX/rPW+GZlPFAxgMZD2Q8kPGA7gF+Ily/uza7iS47mpobeZFKp0ut
zPPOhTz3nKvtP1ftTm2UZrgyHmgfD5yrxxnZzQtRNFXQH7p7qpFut22k1x01OlMJY7h1SSQ/
udRZFCd/3YKG/9tS/vCaUqMU+4Rb6tJ+gXe0XOwUu6QudvvrQhc2byl/WD3tQSdtM+kW/5lw
8WAiM1V+kS1yuN5SWSKzPXNTe/wwfz2evYlo/Xh/PZ5sE07nZ7zUpW/8dZOM9oSRnfyFV7ab
3yASaaRN8ChdaTTQVFJXRx+R8CRpjQcYW4lHxo4RvDgpVkJ8SEv540tvOVbsM0lKtc0mWemG
JbJb8Km2oaX86W5vOuVJ20wy29tfum2p2mJqV3vBfO3hJqn1ddsePgN26mHa65MX0ywN75HN
hGHk6wI1WTpYlUkWixPbla4YomCA4g1GezCNfGWQcrJeiZ7Fz2bQ/8j4u/6Z8iz1htnO/ExE
jJc0TWylKYljlEz7nYgeTwiBj1nkmdBhcD5x7VYV+43tt60SGjEyUfuC6Jnfj2MYyzPBBce5
Pwm9bTej9dcISNnPpnQp4hiMZUcinIHtnAPZvtO/o+D4K6AvAg8t31hgOk5yCFk1+6/QKgIP
JngM6Dw+lo5eZdP9fvD70VMnBsXDDZPxrTfSQepAuxwPZyCPOQ6YX0+afuM4IVrd9lD9rsnU
VYXhrapqwatK+ZOv1D7+5Gt2A33kZ9dfd9LylMxEAVaxhUaU5inCqwOHe5nB0hK9dWHLRl0s
M6yAdqALar+pLSaYmGzCmWBCnyhPxEt47jfVdzwwLrR+S+S/OHh+gRsfGM6EQTXrfsRYJn/w
0yn8wzpelylaEwHD/IJ0JedJOdaPhkab/JPIPSH8px8b/n4wWKF5nIVbP5YhP2+H0Ql3gN0s
KL58S7qm0C3GkekSJSiRct7/5hTZ+j/P4/0Dh1HYl97tNHNmjGZunH5AmEQbaZSh9McXgDy0
vsYwjpOrj53r1hWveeYymdVmME+bRKun/VZDTe3THe7H++v+pnv0Gnzp+lGM8uYefkGRHA6E
olvAHlqDLqYTfaoXtXGjeP3Gi+BzMOf2OS5Q/orfCPGl4x//OGdhCiZS1aB3hPp9z6sEkmJk
U2ixJjKL4nzyvccP4gBDLl5klN8/fnK/TJ7wY/wXEMkDwDj9xiYcXfMgfWPnPUed3eVO3ZoC
VMe7x43vmGFiGTNcFls79eyP3nc+gK6jb9TwccYMM7cgse3qRw1meyL/9C83gT+xym9ANCXV
ATxInZ7wVBRCNd32inK4Q+uTyE7xgfSqCafD9M7U+dq7zHY5g5Nb6DHarUjJpdUs5z7XqlzU
B4wPparx8H5ZRv54dmsMYq8GSqrYUfstqUaEJE7GV3zIBAUeXV1MPxs619XrR/rruuTztBy3
yf74RT4wgJL1jOX/LFTShHGi7B4URrKQl+++ElvwLFfvc4ZL//rLlg109NjtEXzd6aNKB+b/
CMVXfdJoqsg0IpMEZtGdU/xjR/FzfZE//Pr32LtrD6prqnHbbbcpcTEK43WCjVOBgRzA//h/
jIwkDT1nyBO13xAZHN8wLk6yBpqXwOElsB+v47xchppmN8uJ129qUuRODZ2SoQ0ttEMS+vsg
vJFuMEjEE6sjllf63j+k4h26ifR2RDz7QtoaZB/7QAJtEI0HnqSTzDZYQo498SAK6ZUbndkA
XvG3ZWfRW/+co0LXx0Cp+8uMYpww2niW3Uw6WFfQpOEdM6KAZKWS2Aj6ZfFbp8iGyJhPXE0f
AuqE4n7dE3aGpc9ngN5QJTieVboHbDoffzxu5Vym70jJZ7/PO6q/HRg7P4kUc3D4IkIMPgnZ
umEpydHabebX2srFjtZvyfgqDm3shJq4sWZ/BSvx01sBwfKvH2c5+sLwfbDH3MEZ659gLhMm
Wf764+8hNz9HndDxiRiPD3+Sw9gb2KnnBKEx6DC9nEtiWVdQirG7Bccfb36rt9rayrK7de+G
6266Hr0u6qNAumFmg/zaqe4H2YyJZTEr/UvgrCb6gl/1S68h+gF98tXug+j7x1H9pzfRVOu/
TdhsdXtAnXYZ2keNDjTJ4dMpbDcbcUQXBNdFeMtJ6vcyq37zgVSV7eADJeZQiQGYuM8NWGxT
GCI/boOfwsIF9ZEJboKxZIFLzjBJApNc4OdbHqZ9YWiC/JIsr4eel3GcH10RNNJx5tRdHD3l
oOD5M+5DyU/L1a9b2RZkDxyq4Fn5XVD8nd8rOPMHydHb4LFDQwTBNZLERRrC6oKDxnZk0fyv
oqh7CY4dfR//+q//qph1JTzc/XWvBkVhjIGM4ST8/jrjjtNeyjt//7v6dkafPn3Qv39/BtuH
ncXRUHEKx7+/El2uuhIls+9EU0MDPvjxT9FAE0fnby1Adnu/Pp0CpYRgyxuqCU7oUDjfJOH3
hVWXv+aJ1M9jaXF1iZ8ZosK2xy7hFi53H0Yg/lyXxzi9zvL1up/XRG+iOVdhbtvdCVLGgL/t
Mppj4W7rY84MCeXqcOn0khnP/ewdP66FOve5U3bbKWPY2z5uiUtjtUv8KXCpm2iFxuK0/ppg
gtdlCUzP5UYFazwEHyf5M+9HwcQvOLbnlAxE0fyVOPXl8SiYcT9yBg5Hw4G36Wlsd2T57UpU
t+wSv+lWhi/z3bY8hsWKSI9uxfQ51bMo6sJfqI5NQhhfrQohscwKouMsKdZflszPhxzBH5/9
Izp3zsVll12Gz3zmMwquC8sh2/IuHoDKX/wOWTk5dHVRhzO/fxbdPvsvyMrtpJO2U1kOS8tb
Xl95cZaBLoXbFS7MCvnieWmSi3d5BMe56EkEc/HCIVOepcHVw8HHSjrMzC+yXKzZIh1/LpfN
7dVb5PYSe887MsSvOn3Ysr8vRJYFt3S5NG4prPyORedvj2WdtIrbLmXGSF18Qti4S8I6ryXZ
+1fkWFZ4dVmUVtDW5NCVhf/dr3ztbVPbuVUvuHFWDDyn5GIUPfAkcoePQfTdt1H54O22PF2G
VVZXK0q2tNsWpzIXJpw6NpkyS1ITlxJJVxrZdJmUS4G4ge6gipeY3k2uG1xYPNNicdKkuro6
+u51FT74oJ46mF/CG0sboSW0HvfOQrTyND5Y9t/qmZKiqZPR7c5pyOla5JrQ7qVY212TgnDJ
wlliEI+rzSrRt98rKnAmCjopKEFxoXs3h05pCoAWPpyeYH5dy4VX1r3HZRnz3H/+44kBMnkn
8r0u1zQWvPhz3+/SHq/PuF2CkTZKnfxrX9nLpCH1WB7hNeUij3Fu2RIt1lhwB8tgQdkiGWeB
HCobI5kXnjt8rDVhLLkDzdU1RKTjtbKjR4OJSOIxQR10EgWrvdZLC7OpQq9Gb6KPavAgdixI
KE6MYQ7355Z0qFmYpYt1du7cWXUwd251dbX6toeRhz4U1UyTSnMjRUC6XMuhL0ipRTYjsQEY
3Y8lEyZgwtQyHNPQVbvWYsKEGdjRgoclNXEtKlbt+CHZsgrpMKWqfBPmTZiEW6dNx+emT8et
N0/CjCXrnbbvWDUVE374ZovszTAn5wE5bphLylbuP/4E68oXiOQu5sIpcdv9v+DWW57iySKZ
CSOcf6345faiZoVh/8K/p6FuX2W6gBSlJanKRXSFceas2t8Qfrn11eE3yND9EyA+eTDFZj6f
l1P67LxOEXSmJZ4ueZ1DC9NdltjI2MlE+FlhQUGBuoTkjuU9DVNqPFWJkz96AnX/+1f0+PIX
0WPOnTi77XVUPvkrNJ0JF2Irt/8B21j4mY3YtCscj8mW1oTl5Yfvg7h2VLyEGXcvxYFrZ+Px
9b/Bs88+g5+UzUPBtpWYvmQLaNqlVIgiumsuk9rPAxKgrGOIzwzlaDIHR6FvP4s7nmbxmD+3
LDVD/a0QKoZzbJK65AznsptcjFuysLyMw5vW/h94Q9yGN9llPy9L4D2MU4um0YRR7dDrvCJX
wUiXyJDctTF9JZatJl9bSXZOJEJn7XQHLgOSSP6pIAlWDynfvdWlsAsikRxce+04++JBl06T
bfVZ1JbvQ1dakup+12dRMudzKPynG3D2b++giZa3EqdaPL/6afSbuRgLJgBrfvGKHThjOSt2
PYN5U+mKhK5Kps4pw5sVHGKjeOmH86i+CoesiIs3196n6nzVUlW+BffNoDN3vpKhq5ayDTss
+dFyPDxnCTZtWY8ZCjcBc8qeQaWtNlqxA2XzZlh8M5Zg3YvltI7k2mS2BSjf8DCWrH0Ga5cQ
74xVjjyLM4pNP1iMM0V34CffmobBJYXk2zwMGDUF3y2diZG17/vomasWr69/GFNtG+f9cJND
w7rmla0iOy2fzLhvLV5/aQPmCK20x27rM5ukrVPx8Pot2LJ2ieOXVVv2WyZm/ho9oAcsI0EG
GNoDehANG9qEh/tBT8IvueD8dQUPcaXBVw7qVePEoOviK4zq1YuA0+4VhueqwiRbjGnlPJuf
M2G7yeDsZnrLbTZde0RoX6MlSW98IjnSOZx37drVumOKLoF69e6trjqYn+VZMmkpqltXlNz7
BfS4awZ4fyPSuyd63PN59PjsbcguLGTy+Kniz1ixB5h24zhcN/kOYNta/NVwsRE9tgXT5i4D
pizA8uWlmIiNWDBtOS3pRDBu2h0o3LMO3163A5Xl67FgzRuYMudm9KFg+c27S/HOh+/E8scf
x+LZw7BxxSJLfm0N9u3ZhqWlz2DK4jKULbwDezYuw+/UlU4F/vuu+dh4YBgWL38Mpbd0xpp1
bwC9c1Vbgm2hs5Gqfdi2ZhnWHB6G2V+4Gl08ra/FsbeAflOuQrEHDpSMmYFlD01DiQ9evmEJ
Fq58HbcsJBsXz8aBp5diwdodiop17dy4Dqc/XorlpbOBN9Zg4eKfYtzi5dSeWwi3DL/aQdOg
3dZlS5/BtKXLsfCOQdi8shSlm7pi6WPLMW8ysK70oQ6xDOhrfvtU9YMgngVh6eLJuIBx7D5O
8dzoxhor5giPxen9G0+OolQTAl1p8BWH/WuiXH4C41xPfIVx5vFFKP76aodPpzWV1bKVLqQV
y9ZkQdfCtAeenU2XGOwIbxMs7eIgvy28/+D8YpHUQ8TJPz0JTHIbl0d7GmPHjEFup0549dVX
1StNGCXcbFc23T1V+I/XINKrB9WoM+hfp369UfDxf6DbbRMv6ezavJb4JmM0rX7lXXo1RuII
fvnCfoJ50+5NqwkwAV+6/ToMvPgjmL7gXjJkI17YQ8+ClIzBssW3YM9P5+PWe1Zi6L8uxax/
4PBbhE/fS5PMvKkYMaAvBn94OPHQRMYNsPedJyxehmnXjsKo66djZldaIaPXFEff246nzwDz
li/EuBHDMGbqN7D0ln6A/TaX3f+XbMny2UKT2Avl8lzKZDz5429h2vgRosZtDKk/cpzOViSx
LUE/uqZ4ce0bGPq5BzD16iEYMvrTeHD2UOxZsw0VzN9Acq5biG/dPgYjxn4aU8jEoju+ixnj
RmDU+C/gDroyUtd6dlsnly7DlCtHYPz0WSBS3PvQXFw5bASm3PkFqp1FA8tsz+T3g26LjtPh
6S6zHkNSYLHBgHcOChMuVZjoC7ApVbEdks9uqy8EKVNVuCK85Lr9ptio4z1lngyYwf6pO6lo
IuEAL8/IqbygixMm+S6pqmXz0O3+1RTrKEAwr80TP2fCtklKE/uP5gu6wODPhVN8441lXwpl
EnuZpiGWEZNsXAzcB+BbbUeNGoU3t2/HsKFDccUVV9CSmfnKR2yS3PKwJdBrg9QO4dmVdJmB
PZg+YaOref1zqJgyC94phyaBrM24++bNLh2Vqmo4LOah5NppNKU8DcbeevOVFk2nPhjY7SDu
u2kCTUWShjq7BRy6e3UTLVHIPWq1Jw8SZiSG97WjLdUuu/FG4GmiUKbzhGS2JVpPt0jfMgHm
HSBio6uool6xt1BHD23BA4/uwqyH/42I7FT9Lv5Ek9eeNQtw8xobZjv3AMnhXY+iXj1thGV/
obX4RrAovU3AnjQo57Z2LZC2UoWmjWE97fZ16akmEYZ2yCTDpZWNY9fqqvgMTtV1INE445vx
Plwrm3jBiGe3On72tdoPl7p0hdR9bGoJR70+RBA6oc2cVUQP7j30lKJo2M+31c5C8aJVyC6g
CYMTnc2rpPPaIE/GE0tbJJoI2XT50VZChCYMvkXN/JXwRHYnsln4xdlCL3Cu5+XnY/z48Th8
5Aiee/559QrefIKdOnUK/fr1Q/+LLlI06upGBNi53Bmh5BuOrqq3n6fz80Jal38UI/M5zEXQ
cPA5zC1dh63l02kJyk3Rejq3Hjobv/7xNOTWNBBlBd7cVo7+Q6yFnv3P/EBNGH3pSP+P+57C
1f99OyLla3E3ybpjyeOYPm4w8qI7MGPSUleoKtmjgCMEJ8ojRfRWYezEUVrZGcbzA6WjO7ZT
hB6lysqWS2bjVz++DXl1jcqW7Vt3K1tO/kmRBPwpxIeuK8KZdT9H+cyHMMydk/DX363Gn3Zc
ga90bgbfyKdS4cW4iq4WLrrnJ/jWjX1RS3s20YrdeONvUVxG8N1CF5DXy0hycmqr1tkN3HQH
p5VlAGi0HhWC9wBbp8Kq/GY4MD+CTRDbTDjBC84RxAhKwmvVbIAQO0Ct4BegobgYxCp64uH9
OH/dr1pk+kw4Z6vcXmqTIWyoJhnhRC9uMOGtZSTXI1Z88ioq+soj6DT4MvCEcWrx51H8rdWI
DBpBYaEZ9W+/Zk08LEIUueI8Jf8SlweZxoqELRlr2dFoVAXprICdcG6uPpY4cPuT7ZLANpp4
/DIGDByISZMmUQdmYdOmTXjmmWecH9dPnqRXiBiSI9tgF08Rr/xiDZ3Q34lJo4Zi8LChGDZs
EEaM/zQtVjVjxe9pD0FZ3UzLJs249BO08L5nJVZv2oWsSBTlW3+ChUsX4z0KfA3Hnsddy7bh
2oVP4mfrFyKL6Eo3lCNaY1079O5TiOZTB7GhdJG64jhxSpaRNKPFRsrzhlyFawm1+Ntrsb+y
Frzp/cCKnc6exqWfmEK2/Dee2PQOXQZGsXvrE44tmkRjccydX6FFszdw970/xI5DlaitrcSO
Z8qw4OkjGDpzEnp6erQYI2mS2bb0Uby0n+7YqD2KjbSk9J3VfzPKZiBdgCROscPEy5MI76Vu
vZqyw3R0EizIRoKbOMRID06X4UEItXW7rbo7xTk6Bce5LkCHJygnsFGJNdgjJ2FKuqbaaFoC
EzoS2tBU27wgTADc9okcyv428pq/vqTELyq0lqWIka4MCr/2EPKvmqQmjJP/fhsiQy+jrqBn
IKpPo/q59aj8Ju0b2ktT+tKWwDw562qTxI0Wf9DyVF19Heob6uk74fEt0NnYTh5cnoAdMKoc
GkPjdJm0uYLLL7+c7vSJ4JVXXkF5eTk9qV6D3bt3Y+/evRg+YgR69OA9DZ9un1wZ9Epv7W78
ahvwqdLr6ExdTyW4afZIbFz5K/z9+n8gRAHpBToPm4bv/ds+zP+PL2Hjf5B19P+WBY9hTHEV
1n+tlCafL+Ir42lRqLk3Hrt3E+5e8TXaF16GO0atw3/dfTv+ixzbb9RVtAzzBko/9yRG//5q
kkwPT9KdYZJyab9B7QFgAL7y2AIcvmcp7vrMGoUeOopO7SssyjyypezevZi/dC42PmLBLFuA
XVQt1FeBLLT7t2QcfkKyv/W1pZj/uaeduDOa7h5bOOMyRSf+YH+N+dJyzHx/Lhbfdaslo2g0
vvujm2lBztmWcWTnUoN65wo3tY0wVnsiyCdZnbRlTt570hPr4uUuU/L0m4mgFWGBY5TNpzFg
ts1GEkksnlpOaL9c1x8k1JO47vWVVffTBUEtYSY7nM5nDWwUJbGL7bF2NBXYwTOd0CgMt8Ui
OSf/+j3rbUSClhGz8pNnlmCJFl+sT4net8mt6+tywzTU73sbH8z7F9CrxVH34gtoOn1K6Wh4
k+5g4R6xTbK7S2f3lBPhPcQtqGSJIjUuaGzcMWEiPeKXjbMUoDdQAySx3bqzVTukNUKk5THO
Uwrs1mt0UlQD066IHh6oDD9w4AB27typ8qNHj6rJ495778WQIUMUh8Mr9nCj7LLfDnX0Epfb
zWKBm4t+gWQ10lPqtE4TyStEHsVHv75YHXSCTk+1R+nW1kJ+h360ClVRKne2gqsbLCwNngOS
roaqqmodXWKDytmwaC2q6lxbPJ3iITZXqiorUdcYRWd6IryQZwEt+dsRra1Sy1OF8e5Ii3GW
K9Avz+90y480JgzDwsjrik5fyaBbhCv7gsaRENl5PNqYthCPwJhd738eum5yg7VFbxkrw5zp
vPTOsFciRIfI57qULV5LmcCC8EwrNMKnTy4MO9cSt1z3YyL7/b7R6XUcl/X0l2sGom9n99RI
x7NPc/7PUDTRMnxTZbXj4z7P7yMRzTg6fogDY5ksOs5wxbH6KD7yMu+Nhkv8zaTi4mKlg215
7bXXYhil39nusWPHKvy8z96P4qIe6EQ3K+Vk0XZGIz1okk0vMeGnwvXkdQU3KX4DWJnuIF1W
UNmvg+lYzqBBg9CzZ0+cOHFCXWXwFUf37rwHYE6JbGMub+u8chgntiincfCnKwJuD3ccp3g6
eFLIo2dNnBQppI+wMJPFJR3hCBNCJTtCukiZJF0RG8a2uGNQqELnhTRICrXGx+sjniS7SINt
DUzv2K9guoHxzVBnaH7Pa7bEdWp80W2C1dsd64fkTGBZ8XwfLC2ev+PhgiUmwvgnCOUHVnUe
JX9/+uu6D6Tf9PHgd4XgeDnKCSZM5PNb4zt7LFaC598+nZanRqkjhMmK7n8YjXt3ouapJx0a
qxDw1yc7gKrlYLqooCBA45ffykHLU19asgjf/+YiNDXSRjgBOMU4iQKHbp/gmVZ4uBwv+TuF
aXVev0wOpPzr27cvGuittvzkeJiky2R63W6dX49dDOe6n9YjSwumHrgtlHn9Mi2UhrH9a7NQ
ZmnURFsyeOCJMMmZSRFqODFYaPx1xcN/0pxsfapPHUO9/RlGoz6pmHwaRkZLaExjMlieODmY
QseY2sMwfZzr9OHL7iSujxvmN+nU5YbBK/uSa6qu4vwp+3wQ5Ds/nJ/2Vq8xtz3h6W9NJsOL
7/6O4y+epApvvF3Vzz75M3ucaAwOpVuwXljo1luzRKOOJgxqG5kU4SsMtQnOtYCkwl5MwLOI
ufF+x4mYeDihSZTn0WvP+f1UQTqEP56u4JYJt5XHpbMPeL8drFeS8pNU9NyEUGyWxli9JgYW
GEupqwlTds+glAExE2UiGUGW+fl0v/hxej1ev+l0rV022qs1NmD4G81yfczzvOVnd9wk24fJ
0lsmiV6jgQQUPOeubd6Jx4NjM6ymBIk8r+B623X/SCN1vMBUzj7S/aSXdUKCHxk3WIc4ZZYd
KoUkCyUrDlFWE41o2pzPpn90oy0ii+fPRwm9Hr2xrt4ZSMKvG6+XBS+5jtPLjNfretmPE1lB
8Bhei9Bhk44VOqk7BCELwh9EbsLLYc19aMKrUeTrYItHOP3azGekEoxER7J11iI8MgGxBSJP
rEi2HsTnl+2vM5/0k+iUushMdy56RG68urq+9vWb8HEej9cTOGJo3X5XPtGEujItGtNk5dJo
jDE6vDiupcKn87hjJ1Z2R4eYxp7eNpN//Hh/G034Tr37o/bEEXQ23I2qxpMmxF/XUFR0x4gX
btXqaLOddbVNUpGNtjHIKrq4yO7WpQui9Y3qttu2MaB1tXDQ8QeeOMd9TN9wVwX9TJbrXZsM
nyXL6gyzXD5Evf+ETqDJ1pnPlCx50m6XymqPXrco9b8meQyzuITSW7fwXk5Tv3kp0lMTi8Q+
q9Vike4f6U2TXsElyoPkajJJhEhxSwwJSvFwQTypwMUqK7f8lYqcjsTjbZPb98naKHL8fFkY
8NUHUU0BvY6WqfgmKu+PYYl+wkNTSgAty66m1z8N+OoSvwGtUudFKH2Ci/DrO+rr6CkFMqS9
k2nmDmuT8MqE4dSDBHC/S9LLAvMEWPIN/Wcyv5ek7jkjFKAtS8TrYC4L3CvVhTqmtElB1+sP
Ef66ZpDWqGAqXTa326rzX6efbAc6dc07mra0Fl2r3JLeK5YyHZesepeX14S5ptyl+UyX6FJb
UD+ty+ZS8kqGI1exuTjWxv5kzSZev26h0SXoNOd6Wdol7bTaI9BUWhfLW/yPnwSWPo5Djy5C
/ZH3UhGqeGIlu6Jy+/VXk5PS5YJbr+SMMZ7wmhDp0bUQJ09XoSbBR5gSWcSN9HZGIo7WwbtB
x5avvC9dIBZKnWkYptdtPn/GJLbzGCWSHLIQYkJo8UkOx+HY0E4FPguRiSBZE6yAZgU35k1V
TrJ625peetIeRqReRlBwiy1aoWOLY2kZ654Fiham5SQSZHBaeD+VRRvqKBDSczq3vNJ6TeBg
3o1+es8loy2of5KRkU5a54SYz1AoRQrpZYB10cYWTxp+B0nDBe6vp7NRcWUpA+iPMkCs0DlM
MB2vlYVUxNkoaWPKo0RT4S2yZFHqxXSkWmwoS866lvInp639qa0eDdeviXyTWFY4Pe3vlba3
QDzjHL+2CQLnqgknMJ3OZH0ivImnY8K4JdJqmjS6FOShgRbeztJGeDoTq2BVXnXBdT9dS21x
m2hJ4kf59YZ7DGPlMckIJCqCK5SrwZIdIyB1AMt3xDsFS3fqUjOcGQ9kPGB7QD+69bLfQSac
CebnO6/qdIXRTBsb/I+/qxGpraXJooleiEe7/fy97lQTO1IPbyJHHCw4f13o2isXe1qkP6jx
LRIahjkt1odRlKHJeCDjgXPYA4leExWvada+GcUaDuL0i9Dz4PQOLGsW4ech4qWg2BgmdKVr
0khGV7y2pBsndnE7pZyUDp1JnBVagM4cmilDmPFAxgMXkAeq6FVHqSbeK+b3KHKkiVSeOY0o
7WnUhdgID4plOjwofAlcp021AYrP2Z2JleK8YMtGiU6xgcEC83ObaHSYn15k6fL0stAnkqEM
UkT0x0NsS4sn1N6g8jGK6kye8UDGAxkPpOwBFV7oj7rJiHL6nEYuciJN6BqJ/QhTKlrixTaW
J/HQRBdGH/NZMtySl4/gTGArsDNFonOEsUNodHleXVbNoTMgRb/kQhLMI1ZKblOqjGC6ICk7
wnx4x9uiNZNnPJDxQGt74PQbm3BszYNoOJH6LbfxbOzUsz/6zFyErqPpo21tkSi+ZGXlWM+/
UTkSpVejR+hZjU45ndwQI0FIgpJtmK8a2lw/H4sPUBEj06Gj9081na1BTjF93UoB6d7z2lo0
0fdActQL//wB0xIl/FxjO/y2WFTuX8brPBaGIAqo6fBc6dhwRSPcFkyruUqoxHr0JOIVzNlZ
1/TpxP4yCxPdIkgpEC1ihZ8xU894IOOBdHqAJ4wTZffQC0uz0JnfeN0Kqe70UaUD83/UJhMH
hyMOd/yQO3/nNTuHPiRRXX0WH5ykT8hJ4lgj8UZgacx10RzOTCHNA6dK7e49+OCJn6N+/7uK
gyeL0799FlW/+yMa1dIaEXmYYg0WdKI8llOzWJg9DiIgwz3JC/DWPISqIi5XmjwVH22QIMVD
f5ylKp1PBOqwTDnjgYwH0u2BY088iHx6QVNnjrL2x5TSnbNs1sG62ibxk0D295ZoBqGbpqxl
qYYof7vOEPuStMof01imJD9O4JwzTqfVcYxtpA+WVG/eiro9+9Fj1nQ0HDqMEytWoeiT41Hk
BEpbA0+NwcJc0fEMYipHhhBK7opwS4wThpD6XWZPiaUEahIVHg5fRWh0kxSJjvDxZKoZD2Q8
0GIP1B9/D7n5Odb6f4ulBQvIpWObdbVFkq+6cpjlX6Seln34q3lZ2dbX5SSsBBkTGMwCGGLi
VgCdAjvB3wq/6pUgtsJ8+nhJt+mfQQVNFMdLy9BEV0a5wy9F15s/hWxaXvMmYgo7cXgYfa3z
VT2kQRVfG4LIEsG5HxKqF4KgTguCO5Mb97trCAAAQABJREFUWyFCElmUwWc8kPFAQg/I1UVC
Qosgf+Z9KJg4S1UaKw7iTNlsNO4vRxa9E7DrwqcQuXgEKj47zCyNdbVBskIaxQmKJ/zuhwg/
m8G33LZm7OCwxPGLfxKipMx5Nd0KdvDQIRw+fFh9pY9f185fierVqxcGDxlMX5vqRnsZxSj6
50k4/cctqP7lb9FUVIiLF3wJeR8eThJMidtE0lkBJ6WY/2gwxik4E3CKAVjgsH9Fly0pLFsQ
nSbOIYkx18EkV3BlWyVLrkd6cgIz1K3iAe6doF4Jwrl9a5kUxN8qBmeEujEngS/0CYNJc0oG
omj+Spz68ngU3LlQTRjRd+njzv4OTSA33Wj1+Vr74T5+y22Eb6PijxxF6xscXf5Blg6bWSbL
0WVxuZI+R7plyxbs27cPFRUVdPsvbWzTlQ/bVVRUpL7iN27cOAyg74NXPb8NDfv2o+D6a9FY
eRpV//Mcci8ZTN/2HkJHlt9quzmi2K6qQzCA1CGJW2CrdQFU1xtl8+pqfdTWXQhxdbQ+Urcp
ZW2Gdqcs61xhTIvjwjc2nrogXBDcNE7DW3IeUQY6qOVt5ACrLTbEFVjwSesKQyfK6UkTx6Kf
0SrKWEQPvI3KB2+nb47rFG65zV4yy/6iD2rwG3r51ZeRTpFOiNIbbvXPvUosYFopu6amr3Tm
zBls27YNL7/8svq86xVXXKG+YRvJyVGTyV6aSLa/+SbO0qR2Y6++aH7sJ4hc1A89581BlDbE
jz/8fWT36IZeX/8yso0PJtotkIbwlYcn4KfYFh4VItMjIgq6oQt5/GFxSkySSeePB3g7MNG7
oDpya891+1vqW3X0t/ZByUr414KkJox3rQmjqepscBxpoZ7wJtLIoX3w5hyavWgPPDsSyUGE
ntHI4u/AJkhx/R10ph8gkx9rf+utt/DKK6/gQx/6ED71qU/hhhtuwLXXXotr6Mpi/PjxmDJ5
svq4+Tu7duH1v/wFOVd+BL2/ei+6jP0HWqr6J/T44p3o1LcP9VE877HV9GvcjyUTJmLC1DIc
02yq2rUWEybMwA56WLJqxyoqT8WbMQ9OykigXFRJrsl6qezzmDJlEjbsr1VkwtVQuQtPr9+C
E1GLeMeqqZjwwzc1zkyxo3sg/hjr6NZn7GszD8ieRpg8wCh1hbGIrjDOnE18B1aAjHSC6eLJ
CnuU83l3hN+P3kQf9IjQrbd6kglCcg6AcVOIazKWJXLq6TbZrVu3quWo66+/HkOHDlXiRV8u
7WEU0xcFu/fojgMHDmDnqVMYO3068j98maLLLshHtzun0QxIy1m5/PoTkSwSFJnzp3L7/2Ab
185sxKZdszFjRKGDk0LexZ/AgnkjMTQGpclUVyvEIeqEuW4XfrXxiKo9veEvmDp/jCozWfTw
K1ix8hkM+/R4lCg3F6II1ua9espSZJwDuXyv5BwwtVVM5P5iH0jeKkoyQlvFA9pR3CryWaha
nmrBt4kaeElqEcU1usJQiQKIP9RYCEuXlFszp3vB6GYp0kAOZFvoxqls5Od1poLXpX5DGcsw
/UfVpBPL4V8DTRrHjh5FSUkJBgwYoGAeC1Qli/A9ccmQITh99izq8/No095d4Msu7KI2yK39
DJFsMqkWz69+Gv1mLsaCCcCaX7wC+6TfQxw9uRd/2LwdJ2mJiUI9dmwow4wJE+jqg34z7sOm
8jOuAzzGAsde+QV2YjKWlt6BIxvXYZeSQc+XlG/AHXPXkbwzmD9lBjaU+y5jag9h7ZI5lg7S
M2fJehyyjas69BKWzJmKiRP5CmkOVr+wRwUsDlqmH1ttggfCmIES41NJF+rZ97k20afSt+cl
T2rDPDlXhLnCEBqfZJ4wqlcvQvNp7QqDA67Qm3KfjNaocnyw5wxr0lAHAAFzcsItT+l+b+kE
wg1somWqGpoQYg5EJbwZtTU1OFvD63rNtFnPb+FlRJKp4s9YsQeYduM4XDf5DmDbWvzVF7tZ
YrTmIHbufBUfUNCu3bUO81dsxJXzluLxx76HO3r8CUu/uh4Om8eMKmxavY0mpZtw5ZgbMJKm
j9++ai2CRXpdgVm3jFQGT773CxjdK89j/Js/+hzWbOuBhWWP4bGl83B220qseHY/0VRhw9zF
2Nbjdix//DEsnJKPdaV343XtGUwRFOM7QSTKU5wsdLE8cVyok4fuh0w54wHlAQrs6mqDN8QT
/HSP8YRR9Ti9GuTrqxPyiVzt/FkX1SplFe7oD88S2bwRzrvijbRE5U9MKD8dxxOHPnnouIRl
xUxnynSFw68vOXnqJLa9tA01tTWWUA5k9o+Xzra/uR3l5XTfMsF4CS0bOQlV+Al2bV5LoMkY
3Yc2qS/9OAX1w/jlC/sIxq2TxGVeMqIPttMv0v0jmHf/9zF38hUY0P8iXDKoH1CYK8SePHro
Fayhlalp1w4g+AB8mq5mNq/eRNcWtP5XPBiTbvwHKg3FpJvGY0CxvgwYRY+rF2Dh8m9g/Khh
6DtoED5MlIeOMSc9vMN/aqrQ0NwN185cguVlyzG8CwMp2cuBMmFIbqGsdglMcsVn+JMIb2CJ
AcnkcSFMIKlemYnTwvo7LJ3IzeTBHtCP9GCqNGB4A8B0ReCDZRXIgUyrLjRhnCmbh+L7ViO7
gF6T5KMNrrdNqzjUiCbOI2foLL+Wloqq+bafOEmYmMQ0YTCe4UJnomFeRUD7Ap06RdC7dy8c
ouczXn31VYwZMwYFBQVCoEibqANefHEr3Yr7gbr9Ni8vX8GT+3MIz66kywyUY/oNz7isTz2H
ismz0FkZZFvNmf2LlPQG3noIk0p3ujw0b8QkauiuTb9WjV82+yYsYwFK3NN49dAdmDggglp1
N/NZRNnFnv2SCPr2L8ZT374VpWyinYaquakQn3lkAcqXLMX8u3h5Cxg5eR4eGDlc5gvSoxTZ
XFYmgSYo9xC3UoUnDqv/A0dBK2lufbEyYUieisawvGHpUrEhw9NKHuCAT3caxUtZRV3Q7aH1
iqRhP98lNQvFi1ZZEwZDffx8mBuPJNbVBqmZ93HZBjaCypFZ998P3pR+//33k17bNjXEBDO1
Kycngosu6o+DBw/hLL2IkCcI1zVWmTfo+TkOznnvw5pU/NKsBlkt0nB2QK3a9Tw2NhdiXtkj
GElzThQRNBx8DnNL12Fr+XRMZFWcJLdq2LXuq1i2cRiWPvkbXNmnEJWvP4xbH1bn/jaFnTXs
x8/X7cFIuhKYd21f2tinmbj5BNbcvRBr//hXTJx1pUuvX2Qo6DEs+9xC/O2WhVj/X9eiJC+K
9TOm4BmlpgrHGy7BN9ZuRnFVBXa9tRnfXbwM3x48HP91y6WuTLvEk4QEGSkH5cwik0qMoCQA
pr4WN1q51LhnTdRJKLuASaUfL2AXnDNNt5aO4ptb9JVH0GnwZeAJ49Tiz6Pb4idUnbnq/vYq
LU95+Q3nhoqAdbVF4jlDJc7JmMQbGTZ9ujNeahpEyzH8u+aaa9SVBOvgZzcqT1Wi0X7Ib8xV
V2HI4MEYTHT5ebQf4PEgtcJpEJe1nzI4ild+sYZO0e/EJFr+GXzpMAwbNhgjxt9Mi1XAit//
WVHxH/fRRipTfKNXcQH9eqFHlwgqDryEh7+5GSiiKzKHwypUbP8D3mjuhzunXoPBg1n+UAwe
Nga3zRyKI+t+if00idBmDP2pwoHdh1DLdUm1H2AflQf060lXPLXYtWU1VvINWHW0ERY9iEfm
3o3PlW1BRaQLBo64lBa+gHy6QuPkD/oyYTBOyqbcz8f0qSZxvc5PrlPTA+feZKL2UpwLNfaf
/NrKXunHttJ3fuppo/HHVwlxlpcKv/YQ8q+apCaMk/9+GyJDrbtBm6pPo/q59ah8YLaBn2w3
yfRdkbRWv/H44+OZtws4xMac+7aWYr9cvmtr5MiR6qE+fmXIyZMncZTuptq+fbs6KK+5+mp1
VxU/u3HkyBF0oXex5ObaewqeicOdN2ICVe1u/Jrus51cep3VUB43iqgEN80eiWdW/gp/v572
G5oLaLlMcFSmbZNLb5iBoT9firtuflqZPvqqocCffo27V43Dhlmj7ObU4tV1hL92AS7nJUrN
rkvH30q3aS3F87uq8IUhV2NCv3VYNv9zOFb2G1xjcyNvBObdOwFzV8zHzSsIWDQaE0YXYfPT
D+PNOzfgwdKZuHthKaZttBiKRs/GY5MGq0qqgSRVPsuC2L+mQ1H6QXKXS6eOxbp0mVLGA+em
BzgExLsC6HLDNNTvexsn5/+Luq227sUX0HTmlGpsw5tvGRsddKKnhRsjX7qA9OYQFTfVJjiV
s773ve8186s7TtFzEKWlpenSE1oO696xYwe9nr1a2fDss8+qM+U7Z8zAxz72MeesOZ5AZy6I
R+THUePF6THhSwDNUZypqkUkrxD8avxa/lwile0Hvv0S49Y94VItDlrkakDQZgepQWEh31kV
RVVV1C4zDT1lzshInvOkucVpzX8xcu1G6XChT0euTzpsu7gqrmwmCjQolIS44tsCadrg133R
Fja0VIfVX+eGv1vaVj+/2mfTjjs/Pl31v1wzEH1yg8/Fc+jFq010Eqxuq7WV9t2yT5WOjh9i
NCOo347VR/GRlw8aeUxA3oIopuffeNzy77XXXoshkzHNOseOHavw86bfj+KCbnRiTR/s4xuY
rqLlH9nTiJHQBgA2snfv3uohP855eYr3MLjsT/64Yxr+TGOCiywdrxwkM4cQcC5EWREUqQ88
Wcg8rayTCwvnHt1csY0WuF1lUjfRhOCKjlBZH3QRmqfc3XNNpIh25RDEKF+jSHdRXBVXrhAZ
jROgeCiupHZHykHV7oZkDOiYHuDhLEPaYGHjO3scaP7t02l5SlYtaKHh/ocR3bMDNU896dCo
gjrV94IsuAHWGiC1d0KNUrGSNsJbQ0cyMnPoPVP9+/d3WPr06aMmja70skL9ADX1A8M41Ojh
Ri87QrlgIzybOkHE+hkJM5iUe4Q74r1QMVByNiOELK8Qb00T5SBEpD7/cRP0ukPcCgXRL6J1
tzr2+omE2MmFQOd2kJlCxgMt9EDbjCv1jqaQT4QX3/0dT5u6TJwG0O/skz/zwIOOY9bVFqmJ
YwkHFPrx2kLk2LFjziZ0WxiQSAdfPpmWPbjLJayIjMBhEBgxueEsyCuJa0oW8znJptEyi4YJ
bDqfHIfVU2BaEuIo8SCTrnhMtLmVNbadCuQYqgOTVhWKwfaEp29Eqx8n9fiCrauljnq3lRqb
fPBQ3+snNfHblMG2twfCjb00WMmDXw6ABOKOjBucgMJCB55ohtQTSkkComZa/eE7XPnNIXQT
E11smCJRAiHtgZaOZ19JWbfDgXMwlzZJYFcOtuHMbNc5U7KEXglUSE/nx+qzaXQDTGXRz7iQ
LCYxZphmlYystOswa2ao5Ter5Fhit1fMcOAmMYIUYo1GFto64uTBE0YmZTxg8kCn3v1Rd+II
Ovtey2SiDQ0zDLc6CuCsqy1SNn9Lg2zgEMnXGtn8/AO/irz22Duk32BdW1iVpA6JNSY2pwVy
YDOxzqDg3Hr6OcREw3Dnx3WTdIEzrQHvmXgIb3nZym1yE5tBkhEUe2YbIM0G6802CkwHkHWJ
39gpdptNuh1rFY1N4QDNxsjkYcZmoBkPhPSAaUCGZE2GbMBXl6CazsrraImK37SRlh8dV7oc
ls06WFebJPqWBj+cwQ/58b/I/tPH0FzTgA/2/a8VCNUZaxt5uDVbrJqgRSSua1VdtYBNrRYc
0zt4HSiCYvQJteRCmFruSBHdDiBIXuuHWzbFY4YCiIGxdilaz8TKkFh6MzRWXntAZOLOXG20
h/dT0xkzTlMTE4qr+B8/CSx9HIceXYT6I++F4glDxOdlcqzl9utPE8aDULrCMLeUxnYgzx3N
NHlE+ncpQUMnemjtktG2VWJaSzV1QH5fNPKHK3/d3wLbd36wXdeEewIjobnHW5r8MpU8va80
/YxLg8qUTDboFZAEXL9cxustYby3NSYKv5S2rQe1pW2tyGgL54G2HT8czNMd0PVJI1yb00dF
j/Spp9R5wlBXGp3odR78RaZiegV57KGbPsVtLsk4TigUOWv/TJBccgKbFDwibIUOzoNMTpGJ
Wo0atp+QLFqJt3WoCYW6U1Npg0yS0gaTpsYVKPbGJbKa48izeYSVm+XgEsjJoDMeOD890J5H
gXXjB3/ylZP6RjgXtHjD1XM6BbtXWmnlQYFIqNgJRhqTAh1G0VtkOGekekRPwbu6+CB2j61i
QBBxuuCeKyBS6ter1zUfMNhjL9UdmMbDNFxlj3aETXF9WcrpW7IvkzIeOH89QMceX2WoA5Hu
njp48CCOvX8CtdXHUFdHTx7HHMpt7wp1O2MyaiX6UKMk3iiQE9A0hC5XIpIOS1TWZbKv2JO6
HDnF9xpie9yyTw82ehAKrdohVK10am7rHXUaLj1F3Xar7WJDrI/ZBbpr2AKN2jEoHsy9YUGk
OWxtWnBPA1y1Hl+44IQlNb6dcZSQPG0E1nEl3k6b2A4vSJ1wtIO/0+mYlvYdf1471cQhTr0a
hSYODrARfi4it3Me3j98Fp07dyZo+w8qy0FJNtEfrBOxJ0tvkucMRPaqTeDA7LqaVMinlLsk
ro+5rWGT4uI/zOJUmNsGKF1WNbxU5g+fPIFS9DG7rlCaRzDbMiNa2Kym0F/NR2KRiJJ6e41P
t/c0S/x97aLiltT4TpE3ruAEyJYGngTiOyw6M2lYXVPFr0FKIfExyMM1i5an+PjP5kmjR/du
iJws9x74mnDTAaOhW6XIwUaPQ4mV2BEqAaGSKQdsIgXirSCZHDT5x8mJbgahNo1DYnEk/VdJ
9ojnCv1iEUnLbhkDjyhbguQMID9LVXKm0pvgwMWPPkPsFmpQnVsDt1GRDxr5parSM/GmKiTD
l4QHnFGWBE9HI22/NqjJwj5q+bXtET4Ea86cwAfvvRvXS2q2dkJAXFIPUiYcN3x40OmrhIwl
ngOW+yEeH+O0vtJJNbC3DYrIpZRSIL2XO2GN5XllUY03963/zj5/QkFpIFC28B9WzhOx1zBL
A8O1SVORWxwKb2KxGL1/hY+h/ICRlcJy2+SZ7IL0QFuPktNvbMKxNQ+i4UTr3HLbqWd/9JlJ
n4YdfWOb9CddX9B3ofg74dYvQs+Go1NeFxRd9k/WgW8woyUBv2W8rjHNDQ1ooo815RTT5xDt
1ExfG2zi724U0Qv9JI4IUs/VqDENHYbFY9SFWDHRSC1AW5xUdW6GmSzQaVIqc0BmwXwGTOVW
02MwTtqjdIodnlba1vgmDhbFGE5+e0Wm4BSR74/wWpOHzuEjbIWqvpzoOQFpBV0ZkeeeB3jC
OFF2DwojWejMr8ZOU3IOL5JXd/qo0oH5P2qjiYOOMTIgi7+nQccyTx5oqn6fvtfNuxwdJ/lD
Qe3/24MPVj9J76I/oIxsaozi9G+fRdXv/ojGOt8X9ZjZLyCoaQY6CUqKhXtLS/FFG4TZvIKR
XBOZdNG1iKQpgbZUnjio6OKTFp08g5jAnKzY5y8bGNMftsVKX5C9TKPTKWLtj8WnlGrQTNHv
gZgu8RNk6mnzwLEnHkR+Dk0YfCDyHapp+qkH62xZLJt1sK62SNb44ZNS6xfJonupcrsNQnH9
+0npT3W5KiklGnFj9VlUb96Kuj370eOu6Wg4dBgnfrgKRZ8cj6KYo4JDjRaKVNGuc2d6EtXt
5R0dzNQOpU+cThdUdniDCGy4oiOb9DPYBCwKzU22muLTZDczjAydJuisOZ5dykcmfco4Xbpd
9vlRLDeJMHAnAIkUkZqA/AJCxwz5C6jtqqltOCTqj7+H3PycpI/nMF2ih7lcahPrapNEirOV
csuREf74UgMt/Zw9S58YTSLRnJMEdThSCVCS64Esnz5e0u2zn0HFilU4XlqGppOVyB1+Kbre
/Clk82f3HHPsAsUQCSO6dndJg7HCRHnCiYNo9F7ThfrKItUHVlVdqwK05IgWezQZpjab7PDD
2Oe6vwXPokWNwPQ8pj2CVIgEzExLJPK8pbD6c/GnrkvaqcMsPsEIl19ay+omH7VMYsfglr1H
saY1jm+R3ZZ5W5/cOlcWIRuZP/M+FEycpagbKw7iTNlsNO4vRxZ9qbTrwqcQuXgEKj47zJKm
DkRtXPOVRxskVyMfW/TuqcrKUzhy9BhO0edW2yvxrWCHDh3C4cOHUVNTo8zIpYmgV69eGDx4
sPraVA7d5VV00yScfnYLqn/5WzR1LcTFC76EvMuGG8z2HwIGklRA7D2JSanwB/DIJBmADgaT
PWocxYvqwdwxmKCJI4YwNMDbD+7g0wRI1E/Sr3pXiAhNKhXNUC/NhV3z9o7XF20ebL3qz+1a
yLGsTxjc4JySgSiavxKnvjweBXcuVBNG9N1dbswhue0yqvmWKdLMrxPhTYzIoEGD0a/fReBP
AQYlGVytcfZRWVmJLVu2YN++faioqFBf8OOzOQ5g/CGmQYMGYdy4cRjQvQeqnt+GBtrTKLj+
WjRWnkbVH55D7pDB6DxsCJ2uGkNSUJMILmHHzrWODpYkPHHEtimKe0R6x1XcEitjJ4740sRX
4j6pK2sIqHMHDniFsDmTmAB12W7r3ZJ4pjXGravl3CyJb+JZzzQZ38XzUCyumd5Aq2JsLCoG
UnCjdYWhI9TE8cDPaBVlLKLvvo3KB2935FmHhnsUsa62SOrIJFX8tvdsGhOReB9Bb22D+NOu
27Ztw8svv4yePXviiiuuUFcV2fQd2tM0mezduxfbt2/H2fp63Ni7H5of+wkiF/VFz3lzEN3/
Lo4//H1k9+iGXl//MrLVg4lsseVIOwTZNasl0nhrPYRr/CN6n++5KvwWp/z1EQpYcu5VffJK
IgCKiGRyK8CTSlKbwLJkxKoJO9llGLO/LLWC89jIftL9I75T/vM1SKNlGSKPpXOZYX644DiX
AJmOAMg+l5Ssj4TvXMrT6btzqd0p2yqDMWUBcCeMJTRh0F6uk+yh50zm7lB0SFqjwPdL8R1T
Efrl0B648+6peMrCHWzcAv1w9tctDdJgfqz9f9/6X7zyyiv40Ic+pD5iPnDgQOTn56u19Rra
Y7nsssvw1ltv4fU//xnFh4/h41dejp63TEH+xz6Kpss/jMYPTtG1Er1wMY7xYlFzdD+WTLoL
24om48nfzEcfh0fCjgNQBbP11Vg/49N46h/LsGGW+21fD6cEPwZqwc5Dk9YK2c//JZipoGv1
hB7gRGVYk2KvOERCglzpJ+8ZOkX6wpFg26rqbL/jO6tNDp20zQaIaJEnuUPvKwhexp4PnanG
8UC4Yz+OgAsNZd/h1JJmRw/QFca3aMLw7zPLwCfhajJvoz0NVtusbt8irVSJ8DpVKin2AJRD
U6T56xZcBmE9XT1s27pNLUddf/31GDp0qDCqM91c2sPgp9W7d++OAwcOYCdt2I+dPh35H75M
0WUX5KPbndPQTLfe5uTmKli8llRu/wO2MtWZjdi0azZmjChSPKY/MZazYHU6z69ZCZNsSyhT
rGFYUqRxgrsegANkyZlxln1pYlsZQM0xnDfHA9FmhAR+4lP8JipdqEMfR5Gi56USOxkM9/iZ
6VmuL1n8Anek+ajO76oKNkk00U8vx28SIi4oUl65acmyUQNPGIsorlVpVxi2B/l40lMTPWMn
/dOa/cLLUnyXbU6nCCqrT6tlKnAATza11EjWefToUfCXAwcMGBConvGXDBmC0zTr1ufn0WaM
O71mF3ahh/2KuUWB/BaiFs+vfhr9Zi7GggnAT9a/gih3AP1qyzdgzv0/woZV92HChAn0m4FV
Lx+yZJLcQ6+vx5ypBL9hAuYsKcUzRwB6lBC1+5/BjAn34c1KV/WOtfdhTtlLJNeKWdLFnEvZ
pW67EntHJgxLK48C9T+hEb5x6qEP9LrtWyY2tlsXGhDgLUU6t2oFgW3DVZXL1o+rTmL5AWOC
JVo/Ptx0+Q533AL7UX5xCTPIdvdAKv3bYqPlSiNM7lPGE0b16kVoPk0TRhh+NxT6JCWuynHA
lPrxYPJZc3MjcmjmOFVdiV0HypFdXV2Nv/z1r9i5c2diTa1AwctUfLuvfxYVVbX01PdZuqOK
g0JUTW7JH+io+DNW7AGm3TgO102+A9i2Fn+x390VbTiDPW88jRVvXIzSH/wA8yYD6771KMrp
hb9Rmhg+t3Alzo6Zh8ceX45xtdtwhAwpoAubvMEfxTC8gZ8+v9829RCeXvMGhoy+VEx3crbd
E9QcTOsWlN4g5ezGVjYqSLVqtZo4yAiZQCT3uIQlWEPaA2bD1TBQfyyUf5IwynObLE03HSRe
XZma7oFzxV/tZicFcnW1wVccCX66X3nCqHqcXg3y9dUJ+USudv6si3LK7INgP1jHlYXXjiPi
Fj6B8j5GVfUZ7Nz7Dg5WHAadrBfiox/5CC4ZeomjrC0KfLYWof2Ik3SrL2+Gy622um6+/OKN
8PJyum/ZpqeLJJ0kVHnX5rVENxmjaSMj79KrMRJH8MsX9mtxpxCl/3kPxowYgSlfnI+irAqc
bmjG7q1PKb5HvzEFwwaPwIyHfoIJ5Mmz6sJsAG6bORQ7f/oc+GKjtnwLtpHkT3/M3S1h4yQ4
cTkocdtakswTLhnqEctDQP/Z1ZYoNvF6dJoINBib40kxAMKyQINQ8ZlMPixHYFyOk0SaSJaD
JA6Lg2Jfy88BZgodygOmUdRmBtJEEeYqIaugi2MSTxhnyuah+L7VyC6g1ySFvcpgXb5kjWUr
8AuKYZKSGevCk01XGfW0DXCmppbGvnqNSBY60TMRBfkFQuPMNA4gUYEP3IAzuyAjWWfv3r3V
Vcarr74KvpPKn3jSePHFF9WtuPza9ry8PD9JiPohPLuSLjOwEdN5+WnKXPA11Rvrn0MF5c2g
GaB5IobzmhM7N6cTLT9ROOGIwpPD5Ku1TfNu6N+P6aw04lO30x7JOlqiimL3pqeBCZ/BiHwr
JFl/bUKu2AAP3EanI/NMHJ6+8Gnk8eOOoVjVPvJYAhfiEcN8KmhTIWTwdiXZJWWbGOiRHkNq
AViXoGz6FHQr05WYMDpF34WV83K0/Gvtllsj4BztCw74/OmKOD+eMLo9tF65sWE/7WEsmYWi
ecusCYOhcXg9OG15Sp8Ygg5wL41SH+4PHSD5FHsH9+2H/iW9Qa8RYRX0z3dzMQ+QdCSWYzI2
JycHF110EfgjULw8xROEPzGMn+PgnPc2Cgrcic1PG1Sv2rWFposizCt7BKPygQa6cazh4HOY
W7oOW8unY6Ji7IwcHqPSZDvoRtk523aiav4YtY/BvVmvv5K+5OOYTfv3v/3V79H96TOY+djH
LDNYTjuOeb0pyhDbllY1yavUmjg8k5flGv4rdoi7XYxdcgj8QmMoCSBSiJb1cVUNahFi8YSR
5FJySeRa0Av9Lx/D6YoJiX1p9V2qOrnnnN5P4SQisX3BFNbSUTCeMUVfeQSdBl8GnjBOLf48
ui1+QtUZV/e3V53nMriuJ//hxLrCJlMMTsxrHTX8WF9BXmeMGHgJXW2c5Y3wLByvOYLXjr3o
yEh6cMiB6kjwFkzyeGmKH9zj3zXXXIMiepCPE19x8DMavNfBE8uYMWMwZMgQDB48WN2O65Wc
qBbFK79YA4y8E5NGDcPgYcMwbNhgjBh/My1WASt+/+dgAeSvIR+nKeXMU/jPDTtQFa3Cm+sf
xjq6IHKnrjxMmHUrdj71Q1qaugWfGsZXQpajYwWzk1o3ydWG0sRm0I8Hml1MqJz5Er3SI64Q
/6gOOGBjPKEUGySz4e7hbyDQQSSE9anGKkYdqcpmaAyZDeDDLJZDNsFbuqQYpPVCh/t97q8n
65+YsZasgGTp+SohzvJS4dceQv5Vk9SEcfLfb0NkqHU3aBPdlVT93HpUPjA7kJ9fGOiRzbra
IGXTccVPgneimF1SRN9eaqIrjJK8Phjc+aMtUJ981/ADfCNHjlQP9fFSFe9t8N1UvIfBke7q
q69Wd1XdcMMNOHLkCLrQu1hy7VtrQxtauxu/3kYrTKXXoZOHqQQ3zR6JjSt/hb9fP4qmfhtp
xwjO+NdlxAyU/dt7mL9iPratcAXkF0acSsmVEzEaT6PmizeihKHMGMcdCdCO3JYWWE9HTuwi
xxdSEKBuuMIJgY4IKDsTFfEwmy/FSBJ6/4Rn87U0aPnUd/gqn+D522w66evwDWknA9VJWpwr
gC43TKM3db+Nk/P/Rd1WW/fiC2g6Q8+bUWp4862EVsuJIRN6h2ycoJNQqplA+r2BTuAbaFQ0
1J6hVR96IpzJ6xvr6cPhPJe0beKnwLt164YdO3bg+PHj4Jcn8qY4z2yX0HMbfCsuP6fRvUd3
YwAwWeuJO3kj8OPNmx0yPYYMm7YMm6dZqM0bHBLaKR+Fn9HGuQSXUVO/gc3/PA9VNVHkFRZa
DtPIQS8Ze4OoF08Ypk0WlqZkupHPXPUBoatIpswy1Fmwyv0DK74k3T/xKeNhxXM2jQrKBDMI
9/jHgHe0KBz9kQDvIOIVSLr2qLxHl4nNkU16rP8mqvMe1hEnDLZJAliYDvC3IQxP2mhkTyNA
4PG7J6CJToLVbbU2TclSKwAdHT8kgEsDq2PBrntW9NPfaktiFv5+eB9yKt6jZzQqUVNfZ8XA
vcf3opomjvZIHOB4QzxKH1PinJenmmkPo3fvXm6Q0B2VwMh4pBw44uF10U6Q4UJOHgqLqOCZ
2qvwzJJ7sGwbPbhx3dcxVl1msASbUwQwDyuVOpO0QXKXT8K2OE1GqbZKg+PoVv6gP7ZPhSOu
FUzrBPe4lDaS5LMevd+YX6/7O4dUxLGaWF2s6+MwtnQMGuWOFpqih6dkgnlita5vE9N2UApu
QpxmNL6zxzE8//bptDxFKx12Krr/YUT37EDNU08KKDbXZevlWMo0QZrx3sn38P7JU6itP4uc
SCdenmpElCaMLhHaJW6HxPsW/fv3dzT36dNHTRpFXYusM2buAeu/ouFBH5T0A0KnS9m3KkDZ
3FqwsPTnYThdat57dS9cd/1Y+wrEoEmXQUa1aM8gqOE+uHO14YMnrOoOTEgcZx5kN6iGar2g
ioQQFykapiME+VZXrXHFWiH94BA5BZtWFGhw1QeEZl7+CYpJ+Sd1xzhb1HmYcXP1xE33w3Q8
TxD6xKBPGEznx+u8yZaTsSNZ2W1FT+E09BPhxXd/x2NWl4m09EG/s0/+zAPXK/pJC+tqi3T8
5HE00lVN167d0CW/C909RVscg0uG4NB7dMbcARK/OkQFPbZFO8BlcPsHlnO8x7FdpxE5ccgt
lASaQMIIho2j5zcYn3AmEK2Sm4XGx5p5gqBtNXHE6LcnARWJuEGeRABtycjqX4bRj/o6htzD
66vIQHAmJwawBF2KwGxep09tuFJLZVs3Q8MkvsLQD94wPB2VJmyb2X7/hCFtsuD61CKY9OZ2
r6VXaLqlsZEhnXpk3ODkteuy9XLykkJz1NL3lgqLitGNYnNfuuU2OycrB03NDXjhb88EDorQ
0tNNqB//tmwDqEVaQ8mLR8Q4T+fpFb3MZvrrPtOdoOaDp1BNaemEzUtgYowpMb4hAdIOnvRj
EjHoPEKjw2J44gAcFSSAZYk8xcJCmcAhsgXFKvNT2IQxmfhV8hiC8wSgTwE8KQRNGNLcWI8K
Jp152F5Kp87kZHXq3R91UbIzzh1U6cCxDtbVFqkTrQb17V6CQb0uQm5WhC4zaP/7fbr8yMtx
n1C0DPF3kL/OVC7MM6hiDt4Um8biXRVOrOEBahqkGmmMQhGl05hkuIxCSVRcDCIWMsldAT6m
IAEehhZXOJi1JKBJvA9tiN834gdHkAB0ieQL3R1qvOh4y+XMaeL2UjKRTSU6pa4IbUXpGpMx
ys9PgOd4DtHEZOn9IkP1MzElomupHX67kq0P+OoSVNOebB1966KJxlxr/Fg262BdbZG607eM
utB2QU1DHd47fhQRfh6iX4+BGNV3NB3H+pGsl9k0f90Li+E1kbdyC1llokEV14RUBThtdQoB
aqzbGeNR+QO+s1QnATFAchBYlydLKjpM+PTlLJMq4RV6b04t4kZ5gjXVFczOvQwaMgahAMJq
xhqgrJsNF0apizRZFlNwBjKhS64qIf7ofjD5MYSI85aEA7Y3DiTT1BYduckoalXa4n/8JLD0
cRx6dBHqj7yXdl08/nL79acJ40EoXWnXECuwMz3qkJMdUXe3njp9CpG//7+/0+2k1ajRP/YR
y5ccxDoek+NJgdqkxokZJM+Ej6+GOCS46IQiSITrOCmrMc+BSwBSkINB6oKPn+tB3Fnuic9C
MZsOWlPEN/AlS2sQYYH0Zjm6uc2MoJ/ac5C6TwrTcxBPkAK4Y7lkQlB2MJfIFluERXAMz6Qg
D1jesf6GPYMP3VdBShPCXQ3Su1Y/pz5dJVSZJAEH89YK6HzctnWKNjSCJ4samieidJERuWzE
ZerV6PE+99rWRqZLnwyvUG52Ah4fJMQhzBJ44gnRcYF8hEgxRiUT4MV3iXhcUxyDhTUmtz0S
A7cAriQvgcgVbql7qRLVgqQH8jlqhJMB/iQ4d1rxU1zIddc7XDL5r/29EzuJWdc57W/Z+WdB
bV0NamlpKrdTZ3VSGjn/mui2yB38LkxKHpynQhRyrMiZqzAF5HJYKTF+WTqPEOowQ1nOJiRn
Er1sYHFAOp1edgh0Wc5Zi2WYope26wzxyspH/kZTXcFZLuP8dU2gsBp8IyiNOlxR2qVOBFiK
2BGOPR5V2Cu5eDI6Ak68Et+W2NAcn56xqfja0PlxFAVTB2PiiMugEnigpqEGnXPzEW2KorE5
6n3Aua6uLgF726A5eKUcMGwT9aFrGkoe+c5Vht4+kUC59V9HxpQdebI0YlJKXEqqUR/hJNjF
SO84AE/QFHtV4x0P2MbaTnPaKnVG+2kJJLJs7rRlMbZJx9g2kF6BhNHpaX8Yhg5E4x9f7IFk
2h6mKakuEiXXC2EssWjO5f4ytdLfhyYaE4z3rlNNBflFdLttd9TX1tGrROiVr3/46Y9pnSqK
Q/v347bbbnPk6od1vIGl0znMKRZYT7rkxbOZzfPocQKbGE7cIoBxIQKLI48LwiviJBecpi/V
QSAi/bl+kLBsqadLj8hTevVAr7XJtUkcId6x/aqqAiNqXY4wC40JJzRhc5El9CKTbFY+IrhY
KiRBubRf920QbUeDp2sMJGpXKhNHe0wabeWPRP7y42WM+eFcb4nNVVX6K7pN0s0wvnsqwhvh
1RWoa6hFpHc+3XXbuTt9jS5iBVLtWLZE8BCwD3azTC9UBQ8+BGMEeen0w9Q+YhNx+AQEVsMG
gFACKMAEyTPZK/GIZSs8/xEBlHPRxMf0LUk80PwDKt7ga4kuD6/TGFPLHKTNQnUFsh0Sx7fs
KDXumN4m9+q1ESach1D4WSDxaDqz7M4KI0JE+n0s8EyeugeCj7DUZYbhbJPjI4whHZzmgxMV
6oN5Z2lfgx8/iRTRNyoa6Z7fLp3pPbAS8PWjSB3kdqsUnsp6ZPQ32MHpQojIkSMFzpmGclX0
0fvl+uomapHsI1VVHce8tmablGomgSZBBHNkqQL9cdrsZVA6kpDr5U69xoGt7Q4IxxtJGGz5
LJxrWL6Bkn3OKI96S26gIcSjS9LLgTwZRNIeYC8nc7VhnZaeP71x+o1NOLbmQTScaJ1bbjv1
7I8+M+nTsKNvTLpvUmFopCfCeXkrm95w29xEX1zN7ZyPavqwRlXlaXPwk4OTtamy5ygNZ4PD
4hRsPqmbBwxDHQoyvOlsDbKL6XOIdmqm74c30YsOc+jts5x0eq4LL5cTJib2meGrGkTYGuwz
WANBm4PkTFhy0xVImxuVokLVnzLmOPcnP4i7w9CPfraW1s9ln+ptt0evAxJ3WgHfO8E6ROdY
oW1PoACeME6U3YNCekFT5/z03mckx3Td6aNKB+b/qE0mjk6dctWDffwgeA69DT379Okz+OCD
Snpwozp2OJgOQtPBy5yKlv5wAPX8HGSsfIHIaJW6nbNISbX/bw8qVj9J76I/oEA8WZz+7bOo
+t0f0VhvfkOvXyzX/TCR7+S2UhMdo3SbTNK8eBOFo0kVOACl48fCTHKC4CbaMDBldBr+mPxr
EmvR0V8eUwkTU4ehSygokIB9xEnyQMJzAMHesvwba2wQPJbSDDFNOUEyTbRmqalBJdimxp0c
17EnHkR+Dk0YPE7S+CqRZnoKXOSxbNbButoiReh7R51p4siO5NLAjyBSXXUWdfV0KxU30J+C
etlPx3WmNR6vRqBJghEmYhvp4cPqzVtRt2c/esyajoZDh3FixSoUfXI8igImMl1z3KboSL1s
W6TL8RppY0Q/Vw38DAqW4ZV4TtVSahR5w+CjuO0O60Ch4wNW+iSu4AySPRDbHbGQZD3lX56S
icHqInfgCDxZ+cnSt9XEUff+IXTPp/f5xfkQU7K2m+hzyYX1x9O//GXS1RCl7y3RMZWb0wmN
9LAuLU91RjQrmwrms3URIsej1NOa80FOQ9f/zVs5m2Pdef9nKLpN/wwqaKI4XlqGppOVyB1+
Kbre/Clk00woSYa7OyxNB4VFHdQmkwyRr3JlL5XswOTIsRl13R4+qsTD+Wk7ft3QGvaJAhtw
3Mfi3CQap/yr5JLMRAKELjNxJOHhWFLuvRS6yhZk6ntXB08U/knFxZ7jJbm6CNmM/Jn3oWDi
LEXdSB90O1M2G437y5FFXyrtuvApRC4egYrPqndpx0o0nejHUrUY0kAP9+XQg325nfLoR3NF
p7w8NNfzS+DDy1YHsZ9cAqkfHqLOt4IdOnQIh997jx5Vr1GzGn8CtlevXhg0eDD4dek59Cv6
50k4/cctqP7lb9FUVIiLF3wJeR8eHldDvGaZhnY8ekeRFrgC6eMddTZ/IK+jyFww2a0ofTp1
+T6UWbABauJz9Hv6nLSJQs4dIk2o4DVQ0sVQk4FtQCja5CxoqzPW5KxKntrUr64Uq/P47rVk
uyzZyYDpk9fiWtohSyGdpk8Y3I6ckoEomr8Sp748HgV3LlQTRvTdXe5x1U6NVf1DMYvfCMTv
oIqcrDiFk6erUHM28YN91WfPYsPT9D1sCuyeZAcPvjK4/fbbUWhvTHtouCJngRqisrISW7Zs
wb59+1BRcQLRhij4++F8cBYVFeHiQYMwbtw4DKB7haue34YG2tMouP5aNNLGfdX/PIfcSwaj
87AhFKRio1S8voul9vaNH8+ydJhJtp9GMQghM0vZbr8uT1wiJCac0FiGEIU9+XjarjGqW1Y1
o9RroBwhCQqOHDsMiC5mM/ia2ya2KxJDXzMf3+aq0yWwIjW01mZlq257ahLTzuW4lyTH9wdT
xqdIxbjEEhNTmPRK7+qTh8B0eoadjxMG7z00h7wCKLjRusLQ/aImjgd+RqsoYxF9921UPnh7
oDy1z6Ezt1KZP7/Nid/Yy8ZE+DW72fQJv84F+jC2tSsQ/SFiLtbSZPH666+roNFEt+mqwcxj
i5BZtMSVnZ2Fmz/96eBJwxds+NOu/E3wl19+GT1LSnDFR69AcTe6qsjOAU8me/fuxfbt23GW
Nrpv7N0PzY/9BJGL+qLnvDmI7n8Xxx/+PrJ7dEOvr3+ZnjXpbBttZakNeY8IpyKyJHcQhoLt
DgvjZ2AnCkzzRW1VJSpP1SBS2AU9iq07wWJEM681W7goTYYL1EvcMVqdZw3Rr4HNRZ2RKJQu
4RchNk0rTgQ+K8ymmqA8wMU/nHO9gySnTVxIaFZCgpRb5dhhS9A16eVUFMikkArvOc3Djmuh
85wJYwlNGPFeJNtCPWH9nJvbmfZommgfPopoMy1P5dHyVDZdchTwvoAcXM5osgsOPIu+ERvB
Ry6/3Hp6XA5K0v6LX6zHX976C4kgHjlAmV0aptGysY1099Nbb72FV155BR/60KUYO2YsBg4c
iPz8fHWlcZauakZcdpmief3Pf0bx4WP4+JWXo+ctU5D/sY+i6fIPo/GDU/SkScRRwXIDU3Q/
lky6C9uKJuPnG+ajj05o2yZnwU7ziUbM18n9ZcVOhDqfotHbrwsSX0QPYe0D92HNG9pXE/t9
Cj/64XxcSnNH1Y5VuHk+8OvnZqGYBeqB0G+EVrf4nsHS32zAhw6uxc1zN6HsN2sxSp+Pandh
zpS5uKrsN5glCLFLk2UueluqN03oGaYentNlkv0mWuEx5R56GVc2obJC5PtwMbL0vohBtgOg
nezR1Xp8m2YX6FcaQaKTHw1BkjoQPMk9DZPl0QN0hfEtmjAoBsZNIa9o4soIgVRhh1Z/Ghvr
EK2vQ6Rr9+70aHgDzsiSkxyE/sNbHaGWBp44uvASlHag8tVBTIozKutJ59atWxGlyeP662/A
0Esucc8MSVAxTWK8l9Gd7Dtw4AB2njqFsdOnI//Dlyk12QX56HbnNPoeLz2nQe97T5Qqt/8B
25jozEb8cdds3DlCj6CM8A1h/ehiNCXNBRaA/nITlVMdiK/A/tT85Jz9Etmudd+mCaMEix9b
hrGDi1F9aDsevmsh7vnuh/E/36UHd/g27650+56jmbQpZSZLXL15F38CC+aNxFB/E5Uc6ZQo
eEjmUl+qJP0utkrdFUsl0mtQzScKya71+8WIVR51hoq+pKF4yF7rhgmRGCCJwAEYg5bWBVl2
J9ahtzUxdVgK9lPrLg3pE4bvqApr5DlLxzfztGTZqIEnjEUU1+iu1kTJf+NQIvpU8Z06RehF
hXwANdO1RgOya6prUUf7GbVVvn0Kf3TgkW4zOnmQFXL86njm5WTLqKclp6NHj6KElqUGDBjg
mTAsQusv4y8ZMgSnadatz8+jSyR3es2m5RzeINcDsc7rlmvx/Oqn0W/mYiyYAKz5xSvUeCvV
7vkN5tz3Q2x4/D5MmDCBfjOw6qVDDmvFrmcwb+oETCTc1DlleLPC5qQ2VryzUeGY72YNV3Xo
JSyZM5VkTcSEqV/Eqi3ljjw+YK0UxcG9e4ChH8dHh5Wox/SLB4/BvNKZuHZgLurEh6cP4rer
lli2TSTbXpbb7KLYsaEMM5TNZPeM+7Cp3Hq3TPTkXvxh83acrHXVNqhiLV5afT/ZtAS7aEwW
EGzTL5ZZbbjhBsz53u9R6bKEK8mYMFCrljp4q908F1lB3mJgqHjEIEKBEgUhnrDkn8hQchku
P0FkcjqyZXC1vjPaUlfrtyaEBrnSCJP7xPGEUb16EZpP08EZht8NhT5J6a1yH/KIyY7k0F22
9LxGbQ1NGnV0pUGb4Sqgp0OfRAErQrgSOYD4Ej+ezktRQWeqtfTU91m+o4r4ouohvlgZPpGx
1Yo/YwXF52k3jsN1k+8Atq3FXzm+ktBoQxX2/OnX+MGfBqJ0+XLMnwysW/woymkObTi2BdPm
LkPWlAVYvrwUE7ERC6YtxzG25dgLmPalMiAGV4UNcxdjW4/bsfzxx7BwSj5+Xno3XqNorCzn
P+yH5hx85IZPAXtW4maaqMpWbcDrO3ajy5gZ+Na/jUchG5fF+zTbsPL1nij9/vcxT9n2CMpr
m1G76+eYv2Ijrpy3FI8/VoY7St7A0q+tBzcrWnMQO3e+ig9kZqTpoWteFK/T7XyL172DeY9+
BSNoxsgn2iPbXsfHv1KGsoV3YM/GZfjdLmvisa0lCn/S/M8BmdAaxE9sTehy1cKdqBhsDoIz
KFGytCSisvAJ7QknpkNQJdPuZAxmucnI1vsoqMeERvJk7DmvaCmQq6sN9coN8nKcXG83TxhV
j9OrQb6+Oi6PLk87f9ZFpb1cXX0aDfX89o0mdcKXfba2ht6T3kSXH/a0pQIaHXqSxw8J4Qz0
Tx7ExWebEVoaOXnypNoMr9HX71g3JX4nFm+El5fTfcs2fTYMy2CKOvjPrs1rCTkZo2kjI+/S
qzESR/DLF/YTTIZ4EUr/898wZsQITJk9H0WowGkKuLs3rSaaCfjStOtov+UjmP61e8kbG7Gl
vBa7/7iKyhbuYsJ9lnAg3Avl9ahnsfyVK3THtXcuwfKy5Rju/wQ7kfS5Zj5+/aPv4I4b+mPr
z3+AhfPupgnkBvxwk3ZlkqXZdhfb9gFO02VDpPtHMW/hcsydciVdqV2ESwb1Awplmc7K3adX
9uAHX/08Fm4EFv7kl5gyzFq34mvLyYsfx7RxozBq/HTMLKLVuyjdfs3JjutWxfw3BIkmiJ1i
+Zv5HN6QE4fZgnMbGhSAW7NVYScLOTLYFumrePYKjdvH1sQUVl9rtrlNZdMkEeYqIavADQg8
YZwpm4fi+1Yju4Bek8ShONTP9XprtjGLXonCWxKRCN3slEMb4dzJzWpnXB8mZAIH+lZM/BxG
79691fMZr776KsZcdRUKutDpb7MbWHjH/sUXX6RbcSvU7be8aZ98OoRnV9JlBvZg+gSKmpLW
P4eKm+6i/YJ6OigmYjjFUaWZ7iRztwJKCLYZd9+8WXFJF1XV1BFPCcE24x7Gia9IQFVtDj7z
yNdRvmQp5t/1czX3jpw8Dw+MGmGHTDEgior9hxChJalZ3+Af8VaUY8OjX8OapUsw9uq1+BDZ
BtyobFNcYhtPoD17A289jEmlO0UgQPNGUNq509ps3/t+Jcb376HIeNW0azFfzXCKKm0+Iy2U
529y48Ka/+19B/tkwCMuU+mgHuB+lhFvmRhmAghD00EbnB6zONjb511BArOKuqDbQ+sVumE/
31ZLN7osWmVNGAxNwO/IZV1tkPhkQYU4NSToltuCwiK6k6mRvsxkBw8VE5ILDMF286CzZfkC
Rk5ODi666CIcPHhQLU+pW3jVGHUHKsP41lvOeW+jgN7Im2yq2rWFzv+LMK/sEYyk9Rj+7lTD
wecwt3QdtpZPx0RlV+eY6xe2IlpfQXsOs/HrH09Dbi1zVmD71t3oP6QYJ//k4jrX0XdzHVwE
xw8OwTfW/l8Un6nA229txncXL8O3Bw/Hf00d5pqf9QF+MHs2ar/2BB66cYCCF5YMw4yF38Ca
qd/EgRO1NGlwIttUj7l+YeiudV/Dso3DsPTJ3+DKPoWofP1h3Ppw0LM2RVi8fi06/XQGFi54
EFf/fhlGsBCVDCOU9bFf+Kd0C23qub786B9d3palriPDmR4P/H/23gWwqurMF/8lOXmRhABR
HiIFDPSKglNtKdoWW2xUZqS3gk5Tp38qFS0o0oGOUm2uFdpBmdiZZIbi4Ch2KONQ778VpwP9
eyn+sYUZRcQ+oEVLQLTISwOEJJDHSXK/b+3znb32Onvvc05yTnIS9oKTtdb3Xt967bXWflzw
A38P3GhtH/kLKPmbJ5A77grwhHFm+dcwZPm/qjxP0q2/f5Uu4v35Bcu6eiN00jumOnM61HDA
w3l2Dr2IKi8/jyYN2tKITif+pvCAbwYdFi2KJIwJg3l5a2osPbjHv09/+tNqJcFwfnaDJwo+
62CZ06ZNw/jx4zFu3Dh1Oy7TJB7C+O//vR6Y/FXMnDIB4yZMwIQJ4zBpxq20WQWs+dkbxrWU
LZkHto9+dpY6c3h2634yOIwDv/ohqqqX430aZyfquJx2HPjlsxau9T08cf9CzPuH7fgwVIQx
kyaCp4RCugPBGcrw+YoS7H7ia9iwcz8a6Kn4BlppbFhZRW3nSlw+0lhViS8jQsKtBBh1MYYV
0XR1eCdWVdGKp6gV+msnrcNvZihGaVExpt37GG3N7cPif9xOk6dHED2qLXjQeHrNi94F7ivf
hb7fgLjlJBaCwTkxP/UrKr4G89laKn7wcRR+cqaaME5/80sIlV9BDF3obG5A88vPo+GRe3z5
HbJdrvfS4SuenDro1xmZzULtdNAMeigvwclN3SL7u9/9DidPnlQrADaSn+DmO6H49lkOjm7j
MmEwDT9lOHnyZFx00UXgrSo+22AZfIbB49anPvUpdVfV5+munmPHjqGI3sWSl8CttSw7GloO
4Kd0n+0tK6+nlYAeyvCFeybj50//BG/fMAW0EHHaHCEtmFCJmkXvYEn1YmyutoBzlq3FNH5o
otTCLbZ45S0AAEAASURBVCXcFsF9i3C0Whi38k4sqFqJyshuWMnUe7B25riIVIlC+MwDa7EI
38GaFd/Aei41F7xkKpatfQiTaM5QR9Jkmwri1Ig/J9LhefnGatx96wsKPXVqOfD6C1j4zHRs
+DSDBsGepyIrtIJJeGTlbaisegw//cLfg5/nzKM7IiTk0b6cY62iBnY2SpQLpZkXeIKxPmF4
tI8EJWUgGfsrCBeqB7g5+60Aij5fSW/q/gNOL/1LdVtt6y9fQWcjPW9Gof3N3yTltt7qOvzg
No9N2fRYBZ9pZK1cvKirnbanzpw9i5oN/2YbrXdshpKFH374IR599FHr6UDaMlq0iA9/6Yp9
zRo1cWTTymDFihVqIrDWMgrt/Yd08ESzd+9eNNOV9ml6FuOll15SsubOnYtPfOITtPjp4QDl
rd2BUVr4j9HnVTbcgmbansopKEaBc/ahPSwLF2JcbsRW8hXf0dzSRBNyqAAFMUyWaksn/SUZ
Dc00XGfnobRYW2GYZddbCeO62tFEOkR3C63SIDaavKpgEfscJdcyIl/ndYMJiyqnZJKLxRLD
3ckJSYra2pe1itN7WpMyMSDu9x747afHYESeOUjYxcr5H+XopItgdVttBDxy+zsqdXzGeJsw
gdQJejv5n/3XnxKgtEj4Qp+ffeMxlX+vvfZaDK+Mt7ydfO211yr8+Ms+at1qS4sL7j+hpsYm
8DulzlDsDNyxpGtzMkutCPh9ULyFxFtHPMBzyI2sANgg3nZSQR94LIj11+q10TRrGE4vJgzT
Q3x8MM6y2WBOS9ALIrD0xGyNNaBYfyNaaOBXzzK6KM1iXInmJ6bhSkEujd/ejYfJlIdVLRRQ
ZUYmC87bZjCZHdinuv/o3fbqPV8RXxdQ3SipDuMZFAEYZtqCIym3OhOYsiueAKdEv3ozTXRy
pjJnTRYi0SoON/7ELPArg8hMJuaWIfXb0+0psU3062Xywwm90PjxMa2OF95Mi1NRFjcZSZeT
mxX9TFmS73z7kBLJ7aDwy19BzmWToypKvr0K4YN7cf7Hz0VhvonEmrCviESQObk5NN7TE+G0
RcVtIdTWSu9KpxmkmN4a6whskDFGDKZJ4e676VUc9L4oXiGow2si+7Nh9OFxmixuvPFGDBky
xCHGkXEpJE8+o/nhvkgnHjFihDKMJyd5UZZDRjozZIOLiUqjH9xwU9RCbijxOpxyM5ddBmeJ
2RLNnhgdUR7TMhmUDLgSILAYaVGbfRNRnREqslVeveLL14fIqDvJBq4L6byJ1E06zFYtTKqh
BwqkHLoIKZM3zm5mOp+k3fgE119i8YFpr173Ji6V+S46Z1BPhEe6WLT/u3S50oV/q1QLTdGN
lQD9zj33bwmZxLp6I4TbuVA5qv/wuUbolrvn0/CUhWNHj1otyhwYNKu43BPUYfIEDUpJ6ZnE
Kw6INkBdnnKc5j0HzoKXyqTDOA4iWyWJhnUoROr+aBb1SKiUnYWo8ksZJK9JF9qonzQcl1HK
HbVNK7eDJ+of9kqUOsqvxLI8h9MiGeH1kq3bJLQ6jNME17TG1r8iiT95mmLTlWe/O/wXUWTC
pH5MO7zoTLjw6XLcaARv4gQucrxioTP5mT4WZ7QRD6HC54Hud2Auj+kfM68Xyg0nPhGclae2
rzd+FsIu1vuanmYU98VIOPaZcSqlw1i+3qME59TL3c5JJzLTEXd1dtACIUzFosLSIxHZYTrP
2E9nCmG6W0mFGC9oZkRw4heJoxRckMiPBz4pcBRvJhLQZbLYLjcxyee5vqN1zraw7cmLiXJI
2TnmsoutnDeDGyxK40KvbFMmxspSfKIsKkRLsD2cZbnqp+EicLE9oXoz2PWsb7l0wj5ISxlV
3Wid183mnsD0ookciXWcpN1wbjChl9juX3abiMdnll1k6THL0H86LlPTti8sC+P5IV45THlu
9NyVzJA34lK0hqm3edxBlUWDrvyYRq1KIrQMN/lMmPCyjtDFl5jq05JXD37T1lQ2HYizX7P/
m75l8Vs6EPntnjdcFZrOcxubTBolKNLwTKGutBEixpl4Pa+nTbk9yrtUfjLy3OySTqfLYTo3
WqGJwfPApg1u2hSnWByyjBbswEUUKJiSRwVmeofsCFGk3kx+My82c8w4E6/n9bTO1xtpN916
3eiDC9O60Zt2xqOz8CaXlffj9cKJvaatlkQe4G3Z7lp7DtVt0O3ouWQ3CVwg+bnh/WHJ2Cc+
51iCnhaYVyz8gr/0gRVoppuE+JMT/P2JeD/WyjQSc5rfhME/nVfPs2zWwbp6I9Bz4HzrFNUI
xfQ3VDFrFvjlgXyy7hYi7dENpWCCF0ervLRig0toDHCvZcXWWIXemFhad4hetniNVqcVaW6w
6GggREYcT4+aFIy6UF2DGqYC859Ig/WTFWMbC4m4LAZn2JgJWd1Gv3KKrTq9wPTYlGHmLVrN
STpzJO2mw5Rj5pmVYcKr4wXmoiphkClDl5+wkJQTSt9ULTdp6WaZkhYQh8H0UennbkZX9TN4
/+8fRdux92PqSrdHeBmmp0WlFyxv1GiM/psVYF29E6xbbmkKVONF6Bc//znq3noLTc3N1jcy
yAoxNiGDIoMSVy0X3h6UrMrWu46i8REaD+/DGoPykiVNT1mn/jhZBc9QLxk6h+4raRB6I9Bp
JS08Qi9wM1ZyNKDyZcTfDDb5Ra6w6L4XmB1HCi8TB9UdB1OGTW+nuJZlI4/pTTtsyr5PSXnE
RuXTqA9dGgCZbPKYpRBZOlx4bJi7bMELvS5LTwudVyz8jNf5OK3jvPjd4MKnyxM6C2aVKeo+
QaY0dvOb3iu9lfWk7N5SbYz4x4ZYKfGX4HkwHzJjpkKaOMkzUuhNu4VGx+v0SjD9ETrJpysW
O3jvjNOhqdddi3xaehTSAbSNtNX7DzyW4cInsc2dQIoHK2mFFLs1GZHC8hN1lFszc4OJbBXL
wMkZZQjvP0YmQgehndErPF754+FtqVYqhj5in9DF4AWRQJyM3W7idH7G+9nCuETrzU1XKmDu
9lHdquYnrS6xrR5TlnvZuLWJXLsEJq+NsXyo+9Vdrs5hpXWZOo8Oj+XyhnjzWT3IaIbegnqM
idtje6zBTQCXn/2o14W3TywJ8fCix4tO18W0Jp2ZV/LITtWARXia4rxc+qKP2pmiDSq62zW7
ZHAprr3hBlw8cqRSqTc6BsQ2exfLPOrWlOVG5gaLGOKiKEF7XDi5HPrPItFLZ1miIFGwp3UO
DWY5BSlwiQXOsRtM8K64SE91xcWRJ3LNuLuyzKldb9BeMk3dvZX3sscNzn3QL7jxuMHcZLjR
CUxi5hNf6jBTntCYcMm78brBhF5iNxo3mNBnepys7Tp9PB/rZU+GVufjtK5TcLo8E895gcVp
riKux3HJ4KH0mil6eDm/GMWF9Cze2n/4B+TRazyO0IsDb7vtthgFYlhiw2cMe1wAy3eTHXUc
OymOFC8ZwqbKoI8ISiD9MWZqBkt5hVfieDYIXRAn7gGuY+kAiXMFlJnhAekpZs8QOFup4xiu
5/1KkQytn5wAJx7gd/l1N7S3tqKdnsvjvtraQp97vWzsR9Dc0IiO4SORny+vybbFR5uANsBy
1UfhNmlSKb35xMhSAPojV9eaZJ1Wl8EkOs7KRSj0CSMiix2g0+uyFDxSXoZrRY9wu0fMp8tx
p0ocmoi8qK0sNoEJNnHtA4UyES8OlLL2ZjkCv/amt1Ohq4le1cQXatEL8gSFnm89T9/TyEUO
LS54gAsNGTIUHfS97tBZ+8V1uiwZBHlvX4IaqCSjxTaFPoDbjYvxwmtDrYFW4EocEfL6wgHT
9KhRnGUZg6QuXzHrBun8kbSDXserSYawMnHEkSOsCZIJedw4njy1TSRO0uonruALiiCeFy8o
Z6SwsOnwqz4qpNDUQFTUA9YwkdzNEl1ZRE/n3kNLh9J79AbRy19p1XLxyFH0QErYc5yVcYk1
J9pUbDorxTKkSYg8ybvJFRrGxYTIAGnriKGwAGrwd8f5yheWOAOxLiOuLSLTJRY5ycpQG3fJ
MrnoTx/IOli+sLaguDalUvR0+rw8cCSL3wZOiTKrJFZ/TNamYYPL6L2DecihieN8cxNCjU1n
UTKk1PoIEy9djIGSq1GqkruA3g04rQeh02F62onXJdlUSmbkCp+hTh6bjlOmBNMemzuC4bL5
TCRR6YoumvNMsG2xOj3JPRFSRl2WwDyZMhThWPpSIS6sCYMrRa85PZ2hFZYSs9SaVyv5hVLu
lDivV4WobflExkDNqraOdnpjCL1rkF7EnUPvKQzlZNObWKmOc83zjIjg6EAWnUwYYjWKZJtG
VJYyiLltWWKjgpIuN9lOfrHC4hScSHVCRbp77KaLDXCFayJEJ4NiS6IRJpiMpy9BMX1KFm0m
yoqBUKI+dWc/Ue7eX/uJ8ReQmd3rj610pkFf61NfEM2mc41Qayt9jyEvV91/q7znOQulYlg0
6sdDZLyiueHdYE5t7hRuUIbpE4JTjp1z0BEDbf2p4CbT5hroqQu79AO9doPyXXge6KDPvSK7
i1YZIXVvUqiFbqFqpYPw4sHyiTjNKZHLRn0YoJsknafv2qpADbT6pKPhzG0htW0h8il2bGto
JuhJ3Q4dbqaZTm2z6baYRD55sSU6cWjlEFyUPVIGWZkwj9DI1kyMXyLMgo/K0hIiQ0B+tELj
FZuydDpLrnOvU9dl8uo4XU6mpXW7U2WzyEyVvFT4TGwSWbptfjih704sckWX5FmWwLojN+DJ
TA/wOjInix7qo62pDtqmCvH3LBrpcCOvQLvdVo3O7ktONSDrZeOBWQZ/gkcHWqbRcDqLnuZ3
Xr399tvqc678LY3Ro0fr6NSlE5xx9A4QVR4phx+Oy+ooe5SZEsyfRHDTw7B0dEhLbmLGyfyY
GHVAlW4P+LUTP1y67EpH+0yXrYHc5DxA8wW9Hr3DmjRK6ONLjc2NaGg4q0lxnzA0gpQlj9J3
PPgLgPyMyJVXXonbb789RjY3RrdOwITSUL3wSpjHaOc3j/jJNXExE2lMCSyAKgdNLYl619TD
ZRSYh4q4YOH385fo8aMRRV408fQInuW4ydDxoqunsZ8eE8f6TZip3w0vdrviWIBHWzRlJ5MX
nW48gnOzR+jdcMLHNG54NzjT6XwiP4j7twd4wmjvaLPqltpv6FxLi/ra3jvvvhstmd9g6tWA
oswuCT+eVnrakB86OXXqlPo2uAu7Lyihhprklb6vQhckryOks/iVVXCyJhGeqMhwE04cP4Os
QYPVt3zzI4/O8DiT5iJETUhVIl69CF58kiq9XnK89ajac2FjuHfwkiflcuP00uRGGw+m69fT
MW0qniAPvF85hIV16boFHsQDywNt7W3IoVexc/vl+s7+8MN69QEm/mIeN4JEG51O59dw/HDs
Wl5hSONrpjft8idkTTtMGbpulqF3b5MXTXuxoKICFcZvwapNqGdmI+j8pl6D1M66jOh7nySd
NW8qmnDDfmx6fjvqwzaLnsrK6sC+F/8ON/75bHxl3jx8pfI2zJpZgZrN+6Nke9fNRsWTlrwo
MCbRhCepnDVvNsRgBMBl0stl+dLvMkE448e679yoLbwbxpp0LVvc8amCmjaaVSd4HS4w3Qax
1Q1n0gmtDk82LfWm152bjHh4Z29xSjDLIjqFysQLXOJUlFNkBXHmeKCLXkHCX++T+g3lFRXh
WH093vnTkaSsjNc4WUE8GlY4aNAgRcf0fKaRcND3hPQebgrIIUKSPX1JDRZNHYrz7WGc/MPL
+F71Gnx/8tV4fNY4kyPGbnFWDKEAXMbcS6ZXoarLOp9pf/+/8IN/2Yzy//k5DKPVg+4XTh/e
vBJL1+zALWTjXRWTUIQG7Pn/nsa3axcj/5LnsejjF5GmYpSAHuN3BPPatQAzqpYhPLbIQeWV
8SuXbqPN71JQG5lgSq+4BFkSJBOb/colophG6AXmFhOZb0hEhq+AbiBNnVJeE+4uOk6B3Jmi
A4YHOgAPYA+08B224Vzk0l22XfSt8Oydb7yJ/3rj13i77lDcYvs1Sj+cn+ChQ4eiuLgYoVAI
06dPT6gjszz9XEA6jZse7iLN9Bt/+SSU0acYL710HK656SuYQzeLHTnRaLE01WHdw3PVauTG
Gxdiw05rAu1qP4DHv74cW7c/j7mRlcqCms00pEeC4luAz1d8nnhnY8WGnWiJoBrf3YVddY1o
qduEv/rGj6lcTVg6ay421TUJt4pZR03Nr3Dlff+MJbdMwWDakwoVlGHa7CVYRvmzR0876DnT
VLcd3/7qnMjqaS5qNtHnetV6qwUHd23Hu6ctK+q2Phm1e/aCVdh1pEV1/q6u83jtx49jdqRM
S57cGi2T6UtnXl/TxZjVx4DkbEu0vXpdj+j8Th+l3w2sr7d16uVNfwkHmobk2mamlT6L3oue
E8pBB7W7DlpxZP9gTS2GDrkIHxkzVg3YeuPgtJ6XwkijTabhutGy7NLSUhrIL1V6hg8fHrVB
9v1Zpxuv2GLGbjYPIqKdW1/Crl07sXPndmyo+WusbxyF+2+fQpgGbLh3ITYeuQYrV69G1R3D
sH75PGw+3IIsmmEPH9qJJx7bglnLa1BTdQcObqnFf77VTHaewjrm212IJdU1WLnoeuxYvxx/
/by1pdR4giaNY2fpO75XY/6cycrMWffPxyeHFzpNbjiOdwly3ZRL6a91FWiVtwA3f7MWD39h
YpRewcN1eOTex/DWlV/F6meexvJ7JuDnTz6KvTwzUjixazf+1EKfi3x/CxZWb8I1y6rxzNqV
mHZyG6rmPQeesuo2rUDV07swp4rKtPwevPtCNZZt2Kv4E/nj5mOLz7299ExmItxMY19Bu7VZ
keJtu1DExt3hiZViQ0SebaflN++81Qe4/t36gsizNdgpN5zAbH0WvcCF29Rn4oUuiON5wG6b
8SgzEV9SNBh5+QUoyCtAXl4+QtwQyoYOU/f0+BlsNjCh5YbVHZzw85nGtGnTUFdXh1dffRUj
6bseeXl5fluvwuqI/ezgYXrfC7WoekFnKcEHRxvQ8sFLWH8MuGf1V/FnY+hjIx9ZgDmbd+P5
lw9g1lcs+orltaj8dBllJuLOf9qIxnAHrSC2YSPx3ff045g1rgC4ZgpWN72Fbzy9HQ2Vk4i2
mH709GTpONx84zWofeE8Zn5hBi6lB/A5SOdvOvo2GjEKE0eSjIRCCb64aBkm/vlNGJ1zHkca
Lyeug7Gc6vykC2dPn6OJayqW/Ou/4pajQAFNkr/80W6U31mN2deNJ76J+O49/z+++cwO1M+d
gmGxkjSIf+PXr8qlfBqza9Kv3lwZkgSKHV56BO8Ua90F5NWunbTO7UYTl868W5mkPH64dNoU
yB54HigpHqxejY6sTmSHshGa/7WFGDniEuTkxN4uJw2Q3aCnTbfoOD1t8nnhJk2ahClTpmDP
nj0oLy/Hxz72MbIncutQRJnJa8qWDi50kme68/S7o+ZFzJ/CAzmFcD2ef6AStd/+CT75XZqg
KDy9uBJPq5T1p1xd1dHWFsUXDWYaHjDDaI1c7bW3tZJPrsSUS+3Bfvx1N6Br/Y9R13gvcolO
Qks7+68Z7efpSjFiguCKx19NU8ZG/PqdJpp3bCSXo25zDX7S/Fk8VHmN7f/QCFxa+h4euuXz
oDkrEsoR0vQxb87Ym1Gz6I/4zprluFMVbBTuqHoUky89hddpV+7g+mW4db3wW/Hhxi4MIxPE
h4KNl/eiY7jJa8KknoRO8iLTjnmJb/vUhtspkWFDnClvvNn2LT3e9O7l0rWZvHpeT1s8vIJw
cBt5HedMx8qy8V64VMFZk5cs24og1d89UETn3tw8Ozvb0UkNNZQTKsBZ+p5GFt+M20ehsLAQ
M2bMwLFjx/Dyyy/TAyQdYNiZM2cwatQo9cBfQUGB54pGN9tt0DnHBJErfEUbKsMVH6XUu/QC
LjpTAR0xL3/+/8VnisIIE93x372Bk8M+QvD3FDn4VcCuYR+O0wHHBF6EUPjw0Fv093qMpoH3
pIIYf3QbBFU8HBMovXnbb2hS+4xAKT6C52q3oO6OCg0GWuFswMKVG3HH8mfwlc+MQ0F4L+bO
rHbQcCZM216FU+/Bpm1L0VR/GP/9Yi2qV67A1S/+AJ+k85xL7v1XPHrTSLTQiiRcfwC7/xDG
FfacFSMv3QC3erN1urXN+JOIzZ9IStfhGMEjzKnWl4hNAU3ggb73QMGgfLU1xa+cammj91Dx
iTgvOTroTYZ9GcaMGYObb75ZmbB161Zs3rw5+uP86dOxB8K6vXzFI1c9fNWm5/lMo+53v8fh
w3VqG2z/rk34AW9VTbsMpZd+DNNpg2j5D/4TJ2gAbT7yBh5ethw/+iNdjvuE4onTiQ9Y/u11
qKtvwIn9W/Fw9Q6U3PIpxNwDFm4jyia8e+CIGqSdYi/FnUvIgi3L8TAdpJ9oaEJTw2E8v2Ix
dhBh5c281WWH8HmWBYwYSSN/wxFsWvkdteL48IwcwVu0Le/9DAvn3YoNuw7TFtlIfPSysYTg
E41STL6+BDuqv4+dh+kgpOU4tjy+GCuf/YPFmORf8bP4Pkl2Rz2Z9eYtSwZ4jvWfN0fiGHPC
EPmmBC+4SZf5efF75luaCRZyvV9YobWtBW3hdvDzGu1092noIrrSzqczhIazdMnchyGb3tV+
1VVXqbuo+GyDzzjOnTuHAwcO4NChQ7j88ssxbJj/jjub7zZ48ZnG7qer6GcXsLxiEZ57YIZa
gPzNM1U4evdKfGXHGkUwinCP3HQpDaiN4Aknj+4ckECfygW9IZhWLuPwLeI7TXwLKzcqdMnU
O7F28TSV1hcVxeM/hYpRG1G7dB5O6NtkihIYN6sKNe3fp9tul+Mr6yNAlOOe6tWYFTkEEXnF
k27GHZNJ1kLaXiPSUZOn0vbWbqykQ+6p2yrBG2lsX/GUr6Jqzh+xsupuiEi+pfcqsj+0eDXu
PLkYy+++zVJWMhUr136Rzjv6LrjVm2WNdFIZzPnQmDCcjcSCcR6E2dDESiX0os/kErzAzbzA
Uxlbt4OwJmVVxDQe5C0HpEpXb5QlVbb2rRyryVl/+9aS3tN+/Pj7tPNDAwe9kbWTmkrW7XP+
qiufXnd7nLaGfvHKS2mwJDkH8+Dx3nvvYd++fbQyOIzjx4/j/PnzWLRoEcaPH+9hX3I63IWE
6cl0ulqn7briAhmi3SlNaAs90R7uBp8pB+EWNNADjmHaIystow+4xxDYAIdOepK8KexhN8ls
oj2oAr6t2WZXqXBLk1r58C3PmRv0uuU0NVqKrIHTSovtArMHVIvewsvAqMOE04r1g3zBpH6A
FsnJxJFyE4uUQk8lIymg7ZkH1DYqVQLta/RMUB9w83v++G5VLgP/XnvttRgrZJuYx+Frr71W
4cdN/Kh6wy3fdsv40PmWNpz84AO8++47MQJSA3B3Ll9DWRgnno0aO3YsLrroInxAdvEqgycN
fp6Dhgj6OektG91giVrPDiSpXbn0vEiuh3x/WTwgpyTQxFNamtj1vkNnqBjF5owgBvFk5mFe
qID4hC5jY6nb2MGe68096AjhZ0odznnBWW2AIZkbemuYYh+JXzLXG31lmfeKuK8sSr9e/uSD
+rQ2bU11ddGk0dTUTIPzh/R6dGuvPP0mWBridQE+secf34Ibpk/R8sF4ahszT1uWxAuxIfRW
PXdPjwzuMnhJ3l5Z6BOGvcKwtAkutl5FHtPxRBGRS2CWIVmxue9XGdJCxaJ0xnLxpPsonfoC
2f3FA9wPeFsqLz9f3dUaqqcD5pbWdrqNiq+yMy/wXVPpCfGmrfRoTUxqbw4WiVnUO1RSbn3g
slcB5uTAF8Q6JduoBv4o3Low4KsDm1c4qP4lqQrHuiNB8TuQgulxHLGI7I4vn8vCV3axpeyJ
GVLOWP1Of/RER8A7kDzQSR9hyg3RK0ToLlJ6NSB9uY/ecstXZB3tlAtChnggtkNniGFpNEMG
M4ltVTyY8QAasxKwSayNpwir7j2VjgKiCY3TSpqyYwhSBYjYyJOHuRKKrnxIF+MsPDPwz9v2
5EzzkuMFT056QM21xVvvA8efXV30HY1OurW0PUTTRgdCLfRq8i6aSQZSIYOGm+keiIycSXYs
80rYbaC3aKTDih72h8Bs31id285HU2qMTuVAHZWsTQSmPbqtNr2b3To2SGeeBwbaWKr6FM0R
YZo8eEoMqfUG9b6sbPu20syrhsCige0BfcDkwZSHcxWpMZMh5oTBaAlOnDkYm3mLS67qdc0i
j2NrQopgSYS7FHeoLsc97c7H5VB6Y9BiZQzCXXwADTyQQg/wipfWGcjmb2rQywtD+fmFqkPQ
Z8KDEHigFzwgA2BkapAsjYf2FRqnCBEdIzkhhLaJ9mQRJbSRit4d7rZC0Rhjk6Q6VjuTWVBz
mylWgBtEl8h2WrZaZaJJUzPSLqebnL6Aie1u/u0LewKd6fQAv9KJL+O4TfIvlEtvLeRGyR8M
D0LggeQ8wINHMgOHDDYRLXpWiXKT5yffC6cLtkukD8Q2tOcplus/cXiVS+x0w7vZJfSC8yq/
4NMV95XedJUnkOvngWx6PiObL5BolcFzRUi9c4ry/ER2EAIPJOeBZAYP54DnzFla+eLaultI
t8KmlJSlNZ5uwfPVkS6v99J8dcb/ObjfBcU2msbZ9lorDCmHEpNhf9j2TLYvw9zVX81RDTEb
fPLNIRSm5zM6u+iQg14SyN/rDkLggdR5QAZEt8GRhsvogGppNIcgM2/blchAZQ++Nl/6Us6V
hq3bGvitsmb+JNBd/3jXVHclBnyp9QC/BLa7oZ3OLnLo4WG+CMrmM41nn/0ntLXRU+H0iHn6
nolwmuvsYE5c7+Qio1VwlZRmd+uDifjcqdJaXThhnJMJhdMy8Dqvau2BmWkk2LRRiEr0eGvK
fd5TJllnMe72sPKBO1mIj/tZTI3LvTVmTjnS0Waa6HVH3Ql2n7K85vXyie7I7kc8iVyp9qPi
ZKyp4me9i9owfWLQJw9FTWRCaRVPz1ny7MbMOGvQtuXY9D2eMNgAVmmp4ZwdCJ5FD+AxKh0d
3VYUpFLhAbst2O0jFXJTLcOyM95ZWaq1usvj1QV3gE66e4q91s8mDWuwkKJJzr7rhoqmj0RC
yHGkw/f9Kkc36kJMS61Zg6xUl0wAZp49ZE8EKueyCmGZ1ArU09NMk+JAbSfaxjJ7rElxwQeq
uP5QiZEBKwOqgNs+P9zXRfdK8Rl46LbbbkcX9coOehnVl770pbSZ6DmY8xUiaY2tRoG4Y9lQ
oeBZMCbYSAvlQhLDEwDS4AFxPFeIvYUjkwTHMlGIcsFxXse5tSGFJxlKekSVzW8B7LxTntIX
4bV0sxQO9vZFdLKwEMHfwAMXnAd4paGux3L4woy+3Bf9jobes3rNLdYgYqmWDmsq1+GS5sFA
0k56sxiq+xO5vw6njCCXag/YdWXWD9ejBbMnFKWd6swa8q26c5swmE5fObIcfZJxLQWbEhXM
2jnY9qks22Qlgr8DyQNxG0cmFpYba9+2Rn51SHZWLrJo0uA33oay6cGNEP1yc61vZfeu22TA
SFZr4k5UlPafZBUF9D32gF9dueP0vh07ydgG6ROGBWV5ZicTmE3h7IPuNjC110RlSRo4f2P9
OHDKppdErhV0WKanuS/49YHesL+TXnGblcVPg1sr8FCI3l44jL5V0dJyvjf0u+rgRpu+Duo9
KLgaEwDT5AFzMI9VozoHkZmdW59EhCuxgU7qXmLmjm+H6AjiwAOBB+i16PTeKX5Ko5MnDToT
D7XTt18/+KCevv3q/MZ0bzmLb/V9++231bczRowYgdGjR/eW6kBPr3pAH7h1xfoUQTSRO5F0
CutKi/mtLaz4V15+E4OXHbrGIB14IPCAeKCrgw7CaV8qm378ep8QPRKuDsKthYeQ9V589OhR
vPTSS8inD3xcccUVuP3223tPeaApzR4wJoTIGsJcOeiTQqxB+iDP25neE4KsVlm++51UuqxY
TQHkQvBAf2oDbKveh/qmfrrojik2I4vfGkJxCNn0n3pZiN5B1ReBn0Lnh05OnTqVxi0qq2Qt
DfX4sPE8CkuGoKw08z902hf1kUqd1uAdK1FWCubk4aT06txucGsFovPrsu1JSacI0oEHAg8k
4gGeH/gnITsrh15FRb8QPyfeB4FXGHKm0dzcrB4gSbkZ4SPY8PBszLqtEvPmzUPlbbeiouJh
7DwSf0tu77rZqHjyTWWSnnazce+TFaiosWh1vDpAIqe7x834tzk34qvP7nPiW/fhqzfeiGf3
nXXCPeV4yU8Ofur1Wtw459/Q7KaHbFp441fx62Z3mXqZ+ZLEHt7tlE7Dg7lMIBac6eSnU/ql
2RY/PONEPxPGJY4nLMAHHrigPCDjVhctNHihH+IOl83LD/TN9zQGDRqkBkWeOPhMI/WhARsW
zcP6g1NRtXoJrptYhnD9AWyqXYzl8x7C6s21mOT7RdlilEA+haunYy29ZHoVqtCNMxmPRc+g
WBVpgxx+cyd+/fudWLN+GzDqTrrJzg7hhsPYsWMXtq57GgdRHvWGTeGRkrHadaCOIom5uwO5
y4RBYlmyTCSxB+a6Xg+7A3DggcADtgf4gXD65WTRHEEdKzs3FEIufR+cb73tizCU7twqLi6m
w5UQpk+friaQVNrRtPcnNGEAy557HDMmjUAB6SkeMQlzH12NW8qBg0f4fSxh7N1Ug7kVtFLg
39yHsbUu+fe0NL67C7vqGpX5dZtWYUnNBtQsEZkr8GZ9cq+fP6c5ounITqxYQKsetm/2Aqzb
XhfF1u/fjCWzLT2zF9RE9bANKzZsxoYVc6lM69AQ5YhNnDrwOxxuHIypJRZObw3h0+9g176j
GHPjdIWM/+kVmQR4gDYHaS9YrE1+EDm/kNVKNPZjirHFlzhABh4IPMAeoC+B0ztt1S4Qv9yW
XpWeR1tTucjLlavp3vXT4MGD1R1TPAgMHz485ZPGO6+/ApTcgWnmIqZgEpY+VYtZE4rRsn8j
lq7ZgmuWVOOZtTW4o2w3qh98HslOG40naNI4dlY5sL3pHezbsh7vTqnC6tUrUdG0A9/70R4P
5+oDKx/22j9r0G3CpsXL8auhlVj99D/j27cUYOPKBdhFs0D4xHZULq4FZi1Tem7EFjz4pX/C
CRog25sOYcf6Wqw/OgH33HUdihyDpqXTuhLvwjWV92LpfffirsrL0NUoA7tlR8G4z+Fb31qC
++77S4xCM5VBt8+tSMIvOMlbOgXa/VgmJZagy7bkM9aaRFKlr/uWBpyBB/q7Bzo7O6z3TvFn
welHD/fRcoPONLJ5w6oPAp9pTJs2DQcPHsSrr76KkSNHIi8vdQ8ahpSoPN/Nt9Cwj2FJ1Scw
c8YkoKUel40dBdT72RBG/eHDOEkLh1zQdXdoGMaN41mJ95kik28brROmLsP3589ALk2IuV8u
x7Yf70PD0mkojfGzDIJug5yFa2Oe800IZw3F9fNWYNS0Y7ikCDjws2cJUYH7K6djJKW+8uAi
/HTBD/DKgXtxFeW7uv4C//7UNzHCMWEQIrIlZF2x23rb2W4tkOkqqLgluZWSJiZFSfGTLs6C
iZ1RjCoS4+yyRXFBIvBAv/JAKtqxW99J1AnEyxeydKet9UR4Fm1P0ZZNR1jfxU5UWGro+Fbb
KVOmYM+ePSgvL8fVV18N/sRgagKdDDR+qK6PHUcHdDi+7pE1GDG/CrPGDQd+8zhmrtxnq6R5
wzu04MWlC7HR2okisjvw023zHeQ8vJZMGBV9I6Q1GPtPXg4BxFkUredi3P7EMhxY/ndYMn+j
2q+ffMtSPDKFJjkMo/r8BRZ88ReKXQbPxvOtCNMEUDKnwjlhcOU7FTn4BMU0fLXOQWRy2rqC
51TvB7aD9Ys9EpuW6HZL2qQJ8heaB6Kdqf8VnE1367QJl6RnZbcOwiP9jtYWdNMUvUKE7pzq
CPfdVWRhYSFmzJgBfmbj5ZdfVkshhp05cwajRo1S21f8rQ/Zx07YV0Q4/robgPVPY/PeuzB/
in2NHz68Gxt378aiBSHs3/gAardMQPVzL+KaEcVo2LUKt61S1/Yeqooxf9PLsKYJn9p0+aaV
GnQdjaADXbQPdvSDBtUueCZXofk46ig9lRi6uhpxsn08HtqwDaVN9Xjrty/jseW1+N64yzG/
tR5Z5ffgp//yZeS3tNNUcwpv/PKPGD2+FGd2c0WzMmk0JNChO6KLopjBVexgXERCDI3N3iup
RPRbNJbx7s9q9IqpgZIM84DXBUaGmelqjkeXdaV1B2qd2Z3AF5pFg1KWOgS3xoLsfHo+g7eD
cvvoTEOsHTNmDGbOnKkGua1bt2Lz5s3RH+dPnz4tpEnFBRNm4s5yYOPS+7HpzcNoamlBfd12
PLBwDcm5BdePK6ArckqOuhjDikK07bQTq6q20U5Tq1qdWKOsPvCK+u5VBDdeJY1j9SvF1XPK
kbVtOWo30/ZVawua6vfjyW+vJEWT8amJNNGF/4Qn7l+IeTXbcSq3CGMmTcSlhC3MDWHi574A
HHoGz27dT5cAHTjwqx+iqno53ncsHNnW7tmrSkusiQzYijbpP+yNRINVDrbFzR59wkhUYkAX
eGBgeyCZ/uXuCTVy0GCVRdtT1jN9eblqwgh3xL8nxl1kaqD8jfKrrrpK3UXFZxt1dXU4d+4c
Dhw4gEOHDuHyyy/HsGHDuqGsFHP/8RlgxSNYs+xu8FTBoWTyHKx+5Osoo3TR5+eifGM17r71
BYWbOpVmmd0vYOG66XhMDbbWYBX7JItyp+LhPzpeTzMuN4+2yRz7Ywy1wpS51VjWuArVtUux
uYYf1KeQNRnLVq/AFep24En47so7sbBqJSp/bjWCkqn3YO3McXQ32DjULHoHS6sXY0u1JW/O
srWYRnPNW5Qtzmcb9YZj2cwQp/UWb24eecTDTosiVX+9LEhEvmV57ErCLJGZT0R2QBN4YKB4
QPq9xN0rVxadd/NkoXYt6EGNrKs/Pq2LVxqnTn+It//w++5JTYBL31qKvXfeFsC49957D/v2
7cNhOmw+fvw4zp8/j0WLFmH8+PE2YTdS4ZYGNDSHaWIqQmmp+XBGmJ5Mb0GooJgGYjoP508j
RtLdUOVg8Su7ozpbmvBhcysN8SGUlpWqSYiHPaHpoluDWwlPRtKneY1pKUwrFDqoDuUXIV9D
RXWH67HrV2/gHL3imK/IGc6+bm8fhI/fMA1lGo/D+DiZqHyi86tXS58tjFdZ3V8Z2B6xJaY+
pZct9dIzR6JfvWWOlT2zxKrL/noR0Z0v+EkfEb91qU96l5aWqr7P/njttdcEGY2lzXObuPba
axV89EfK+TZbStNNUzw68Z1THLro9bdJB7vnJ83qxcBGjx07FhdddBG9SPEDtcrgSYOf5+hp
CBWUosycK6JC6fkNel5EQoGWFlg6YofXaZIqo59bsOhCyKctND1EO3xOPr300e1VMMTJ/7va
cebkaZymCwS+L4ybVBfa6PvwQ3Gej7OcYnUVKUlbdtoNufsTBpvj8FpK7AuEBB4YWB5IXR8p
pAtR3prqpK/38SdfQ3y5x/86Oxyb4An5zxp4EiJNmqioqEi9+ZZvwQ3TIT0fjA/kwPMvD+Uy
CcjwKrGFjXhABxogs6lYgzNJDo3AzZWVitqkiYhIQ6Qbylp1zYzjnw5LgwmByMADgQd65IGi
ohLanclVEwZ/4TXEg1S4vY3OD/ihreSCDHDJcSVHzXdNXQjBvPLmoVSGXBlWJVZ3WAky4hyd
3s1fwuuGSxfMmghpWpCZy6EonRYFk5HD1UEm8EAPPMAX7SWDBqPsomEoLCikSYPeMtR09ixa
2/xuMfXWyNtJ7oOCxiOjhwYKku4eYFfpY6zb0KpPEMbc4So00SFUZLnpdBUcBxi3XcTh7z46
VSXovgUBZ+CBgeIBfiKcHgwArzLas1qtnexzLW1qz6o7hYwODOZopwmTwUgDBUkvDyQw3ulz
sD6BqDQ5W590WI3QJCA62CzyqpcAHnjgAvVAHj2WwQfgZ5ub0HGWngXL42+D08uoQrl8Ot69
oFYb3WMNuEwP0IwQnWS10Z9hMvjbG1cupwJEJLS6aHPCUDoihIKTWOeTtM81gZAEceCBwAMD
0AMd9HXXllZ6vVAbrTbo7DuUUzAIRUOGof2c3ztQ/T3Bqw1r4jCHKzPvL+dCxrL/VOCRO5J0
Dv88mVhI8bfFYMFlwJfYwiX3V9S6ydDmr+SE9gl10O76xO0Zq1RadsYamIBhfdemOzrb0cb3
SdEzGvw8XfaocRNR8Rez0E7fge1JsLapLBk8AFo/GvZkMOyJ8AHOq9YW7DqpAompnXBTUU1e
/WESfvgvkmG/6EjOJxiUCvojqphNTycoJg4ZGye/OKQpRFtNTvNRCmUHovqfBwbCENSnZaCn
MrKzc2gsp++EZ9Nv0hWX4/TZBrpf/3zc1iCTQWSkiksfECTqAb/h2mXQdRkPbSoXpIcZflo9
WJIA63akV5PTKL4xwwlJPCde1G1PnDugDDwwED3Q3k4rDbrDln8t9HnuUNmwMuz77a+RT++e
4u91ewWeMFRfTKBHxltdRA/PvZT1CM4dvtujRo80ezHr/jDLbq0a2F6xWxuwtCTLVttSMauM
iFYpMvGYOiIUCUViRULEROReNsPwDKuP7pQtUZ7+SNeT9tKX5VVjUlLjkXSSvrS6O7qt/tST
euKziO6GNpoXOto76KlweiN6Ln0a/MNTp5Cf1Yn8QYXgb1ukI+gDC8vvSeHtwdXLUhmwMqeB
6OU3yy5bTbztxMGyXsoQBUTmQaZxwTEjhwg6VkeE3aJK6V/vsomdUg+SF/UCl3zmxXrZMs+6
1FlktpfUSU6fJK6bRO226jHz25u/txIvr5ecJn41UjdCW1s7cujhjByaJ7q6Qsg+fboewwbT
+5botqqeBXNQsKSlvuPFq3zGx6PpWUlTx235TCYMV7laUWJKFgNwldDH3uAymm1DK5S7yQE0
8ICnB5KZMDyFBIiEPUDvC1G0nbSq44VdKKezDTkFeTSwmB07YZkRwmAgSNZj7HHTa1ZeaoMo
pFoixJJlOkk7hJgCI3Qu4GTNTYI+YlnEZpuxd62w9QapgeOBnl9xDxxf9E5JsuiOKXrNLT2a
QdNHF21TlRUV0mu78xx706k0JdElZCp19hdZ1gojdiCVyYDx7D/5cbkULDJLODgjTA5YxBFu
sER8JHYkQis0vN3Gd3qouz0cih0ZIQ/iwANJeiBoR0k6rMfkXXxnLZ2J8CqDT0ay8+lDPl20
+uD7by+s0J0hMf0e0q2SNMde23zRLkQJKx2F9NjYbkmKGM0NLAiBB1LvAekVqZccSPTwAN1q
S49o8OWg2t3I5lUG3zXFj4qnKngNcKmS33M5mdvwZKzlWNLWZbteai/7oxw6ca+mebKInTD6
3i5vJ3j50psjwPSlBzK5LfWlX9Kom/s0H2twx6ZXo2eXDqZvSZ9uoA8dtaRUazITR+9vYXHD
y9zG52WZ7VObgoc8laOE2hLyqkVfpBdTT+G2nT2VFPAHHgg80Dce6FRnGZZufsgv9Morv8R/
/ddraG3xfkYjnaaePHkSb7/9tvp2xogRIzB69Oh0qiPZ0WE2zXp6RzwPy6pEccZnfsomDona
Auv5BG5qMfO945fEtWS6fYmXJKAMPJAWD0S6CH+9T00aO3e+SoNOJ863xn8iPBmDEh18jh49
ipdeekk9I3LFFVfg9ttvT0ZNN2gzeZBwn9Di+dIqEf11Z1c+SrjUPjISc3aPBSSmJiVU/cnW
lBT4ghNir877c12z7byT0Ed3juXwzS00S9DWVCfdbRuaNGkSeODu6M7nXj2aIA9yUlnxBjw+
T+GHTk7RQ4bC4yG2x+CWhnp82HgehSVDUFbq/lnVxJWkoxH6DO1Wu9F21VxoXUDR8vjhIkTx
6ioqyzeRgCJf/gAZeCBdHpBOlC75A1NuNk0Y7LmODnWwgex75n8Nt/7PWfj4x69JS4njTQT8
FLpMMs3NzWo2S7kh4SPY8PBszLqtEvPmzUPlbbeiouJh7DwS/xxn77rZqHjyTWWSnrZGb3al
3RD3PlmBihqLNvEyNGHD7ArMXbc3Iisis2Uv5lZUYN3eBppMLS22psSlJ0tZv6sGFbM3wPHs
aPgENq1aQD6j8tHv4XXb0f13IidrUbro2Zv6BBfxe7rUBXIDD/RTD1hTBo1B6i23dKYR7qCP
hdMDG62t3ftyn5sf4k0UOs+gQYPUCoMnDj7TSH1owIZF87D+4FRUrV6C6yaWIVx/AJtqF2P5
vIewenMtJvl+UbYEJaBvjqjJoZjSuZqJ+qADXDK9ClXoxplMdNHjlDcooolvWkh3OPzmTvz6
9zuxZv02YNSd6n5s0bnrXxZizbaxWFazFpe1v4Unlq3EsuIxeKpygpD0w9h0qpnvh0UKTA48
kAYPZGXRJ5jol51Db7rlV6NTGu+/fxR7fp3sFXJi1sXb8hg6dCiKi4vpw+UhTJ8+PeVbVE17
f0ITBrDsuccxY9IIFJCe4hGTMPfR1bilHDh4hK+pw9i7qUZd2aur6bkPY2udXGvzYCI//zI3
vrsLu+oaFVHdplVYUrMBNUusq/OKuSvwZn3YX4CBpc+eREPTkZ1YsYBWPXy1P3sB1m2vi+Lq
92/GElqtMG72gpqoHrZhxYbN2LBiLirmrvNdHZw68DscbhyMqSWWWPuTXE3Y94tG3FK9AjdN
mYAJ18zEZ4jmZP3ZqP4gEXgg8MDA9QB/7pUXFl38NDhdPGcXFw3C8RMnUF9/MmWl5olCfizU
b+IYPHiwumOKVyfDhw9P+aTxzuuvACV3YJq5iCmYhKVP1WLWhGK07N+IpWu24Jol1XhmbQ3u
KNuN6gefd27RJOCdxhM0aRyzBtP2pnewb8t6vDulCqtXr0RF0w5870d7fKT4bT41YdPi5dgx
7MtY/cxaVM0qxMaVC7GL9ojCJ7ajcnEtMGuZ0nMjtmBZ5WqcIE1sw471tVh/dALuuetTKPLR
fk3lfVh6332Y/2WaSWW+VPTFmL9pG5ZeU4oT+3dh05OPYD3Ni1+e8VEfaYzK1O0escvP33GK
FqADD1xwHqALZzr35rE8dPCPf8Qbb7yBwnzfPZq0uYjPNKZNm4aDBw/i1VdfxciRI+lBQ94O
Sk0IKVF5sK+cY+WGhn0MS6o+gZkzJgEt9bhs7Cig3s+GMOoPH8ZJWjjkop3e4DUM48bxrMT7
TJHtqzZaJ0xdhu/Pn4FcmhBzaTDe9uN9aFjySZTGmkAQ/+0RtXl4vonWREMx/c4VWP3Jo7iE
ZoEDP3uWeCtwf+X1GEmprzy4CC8sXINX6u7FVUrPLXjuqaUw50yFcvnTzna7hhbs/t8/wJod
xxS2vv4MxdF9NYPDGpCp2NTIDFSfZ9mgYMLo82oIDOg3HuiiySKL3j2VlWO9gyr00kv/R925
lF/QN5MGe45vtZ0yZQr27NmD8vJyXH311cih/bPUBDoZaPwQzSTMMcTR4fi6R9ZgxPwqzBo3
HPjN45i5cp+tkuYN79CCF5cuxEZrJ4rI7sBPt813kPNGVMmEUQhFoNZg7D95OQQQp5xpsOW3
P7EMdSuqsfTujYps8i1L8MgUmuRQRr9tWHjrNgd70/lWhGkCKJlTkfCE4RCgZVpawiig9jHr
0Q2YhRbsfPIeLF/+M1Ruuw8XaXR20popMm/CEAszbiYTw4I48EDGeYCf8FI9hneQ6Lbb0B/e
egtDhpTSba88rPZNKCwsxIwZM9Stvy+//LK6g4phZ86cwahRo9T2FQ9ayRywS0nGX3cDsP5p
bN57F+ZPsa/xw4d3Y+Pu3Vi0IIT9Gx9A7ZYJqH7uRVwzohgNu1bhtlV+NwZYWzbOaUI0anFC
z0vSK8BoO+jYB8b9SM3HQUcx+KQS14QP2i/DQxu2obSpHvt/sw2PLa/F98Zdjvlt9UD5Pfjp
U5XIp8E9hHrs+dUBjB5fitOva7Z0N9n0Ju64dRnmrN2MuRP4wqIAn5hxE/DCTpykm88uKuyu
4IAv8EDggf7mAXWucaahCeda6CMb2XJN3DfFGDNmDGbOnKkmhq1bt2Lz5s3RH+dPnz7dLcMK
JszEneXAxqX3Y9Obh9HU0oL6uu14gLZwgFtw/bgCuiKn5KiLMayIhtzDO7Gqiq7ai1vV6qRb
Sn2YeOJz/obg6tsmIOvlFTRx7cNZem6l+dRb+Oeqx4huCj790SHI6jiC73/jXnyt9hWcyi3G
R674KMaQnEF5ufjo576ArEPP4Ie/eAtZuR2o2/Gv+F9PrMDRTlNPN/Ml43DT4Cz8aM1P8O7Z
Zpx9/9eo/saPkDXhz3FZ4UDb5hlo5fFpiAEq8ECCHuBtZvU6W75rin4h/lB4Hj3x18mYPgz8
lt2rrrpK3UXFZxt1dXU4d+4cDhw4gEOHDuHyyy/HsGHDumFhKeb+4zPAikewZtnd4KmCQ8nk
OVj9yNfV5k7R5+eifGM17r71BYWbOpVmmd0vYOG66XhMQaw/8aZVHa+nmTs3jzabHPtjtuAp
c6uxrHEVqmuXYgudaVthMpatXhG5HXgSvrvyTiysWonKLRa2ZOo9WDtzHN0NNg41i97B0urF
2FJt4eYsW4tptKjaT9niJN9DmZtH210OO8tw1+rl+NPi5bj7tvWWglEVqH7sC7TmGGgh2LYa
aDUalKfnHsii902pt6DTmQZdeiLr4ovK+EgcrfRJvzMNxhZJz/VFJehbS353UzHuvffew759
+3CYDpuPHz9OL1M8j0WLFmH8+PFRed1JhFsa0NBMWzihIpSWmkNemLboWhAqoK8Y0ojfwp9G
jKS7o0vn0cuuw2PSLU2ob+Y9rRBKy0qj5yE2XZjsoj2hUAGdMRjTUriFVlFUNi+bw/XYtWMP
zslBfURoe/sgfPyGaSgzxNk67RT7JEy6i03dERK/erWl9J9UwvXWf4rkaulAqze9kAOtDntS
V/yev9LS0uhOx2uvvaa7SqXFX6zn2muvVbARl4ylnSh6RoNXGvQ/xA/18cl4pgQ2euzYsbjo
oovwwQcfqFUGTxr8PEdPQ6igFGXmXBEVSs9v0PMiEgq0tMC6Gydc0flFGEY/FfjQKUZhDvKL
LHyMzJx8eukjLyvUNUAMJ7roouDEKZymO9Ps+8La0NY2FOfauzAsJ5bFhLBupYFsG7iB+8JA
Lt/ArbmgZOnxAB9+d6oPalC/oDeJhIroOY1ceuBNzSLp0dktqUU0QPGPb8ENh8Pgg/H0hAtk
kAiNwE2VlelxYb+Uql8omZPEBdIm+mW9BUb3tgfoG0zqMkqdYFA61NTcqA7BO2g2ycTAd02l
P8gAYg4e6dfcuxqsckrlu61l4tszEAZUqW8u7UCv8/g1GlD0tQekDertsq9tsvWzdfpmVCjc
3kEPjPEj4mK4TXxhpLjcUlkDYUD0r7Xo/Q5UVD7UsqrdrHs/P5i0/voyD6uXjdN6kHx/L6Ne
piCd+R6QdpehltKMoS4wuVvwSwt54KC9KeuXoTan3ywZJCQWjRlemWJmdNKLArSElEFiDUVJ
axLRcZwWP+hw5jPzDOvPQcopZeC8CRNcEAceuEA9QFeWquerW26zELpo+MUK0N7OzzBfyMFt
sHCDZaKP4tlpD/ayoIyuOGKKw7KYnmNdri0jhqVfAfQyuRku5eQbCuLRuvEHsEzyAFehd1vP
JEvj29JXrZHPwPn5DP6uBqdD//7vG+kOmjbw7Vhyu1V88zOJgkvUV+7MJD942cK+MX1kbUt5
d6YLzZ/sHw5cbvGX6TNFEPzpdx6Q+ux3hjsMVj2yjy5i+FXo1h22tC9Fp+IJ3J3vsD3I9EsP
qCanWW7lu9RtdBo4btKUE5ehHxDIhKGbyuV0g+s0ZtqcZMy8Tu+H0+mCdCo8EKwYe+ZFdfZJ
ItTJBnWNATJpXCidUMrJsYTuDOQih3gVuy5P5Jpxd/SYMjIxz+UYzwl6AABAAElEQVQSf5j2
ecFNOs4n459kaN10BbDAA73ngc6uTtCLQ2i71honQn+3Yjma6XUdrbRF9cUvfrH3LEmZJhnw
LpSOmGh5zQFP+MTxifjLlCG8mRanwk5TBuUdoET8pfvFwawjgnTggV73QEcHvRi1m6GTHseg
e6bU2RAfYYSumHQ5jh07gebmc+r11/13KcedlEOyndvi6j9/kxuM3M6prK1R3U/Jycw8X3Wn
7uOXmX3HXlKUyl26z9gLXjLc7PGizTxvBhZ1xwOZX79N/GqkbgR1hy3fZxs5BA2NGTuOXo0+
FH/60xFef3RDZG+y+FWM2C4dlu0SWG/amG5dyZXJrFKud6vurcNwy9rkZKa7hMnLT4/94jvn
Q5B6+2JLzXwEFGNSDCD5YgYcGeyBgVu/6gNMmufp09wh+lJevnqRlRpNpKdoROlJcmdLztE8
2MU3LzmZ6SlbOqTK4JRs+Zz0lv9MWcnXRTpK2HsypfzxNDp955wgTJzIItnRRqrr8aIXviAO
PJCZHlAH4fzGEP4wHrXtELdv3pLK4pMOClYzp79Ge3debfW0cLrwRGXF8sipPpUgUSH9lC62
7D0riPgr1XJ7ZlXvcUv5vTSKX3Q6gXnxWHDnKk7n9+cLsIEHMtYD/BmNLJow6LOvHLI76SUi
fNBBB+R2MPsH5WU/yybqSaonnUmMY6PYLrGN4fwbaKE3ytST+sh0f/fEf5E2Zc0ECRS0J7oS
EB+QBB7oAw/wtzRUy6aYB9zszvZOdHR2oCPc3svmmANVpIN6WmHS8xO79k6ANXkws8iR2E2g
coEbIsNhpg96am6q5fXUnnTxd6O+dZaomzgRzbgay20yCIEHBpoHoqMpJbJb6POnOfTEX0dk
6dEXhbXu2JLepvfWeNZYnZj5pbPK5CGx++qD+aJuiKekD/G6L8Q/fWjOhaTa4W6rndnFd2s/
Vl1xu7OCQ4AAgzjwQL/zQGcHb0PZ4yW95bYdefT68Zwc7Tk/HoHt1h8tJLOluivw60vefvtt
9e2MESNGYPToS6P64id0i3ji4NvCnFyctx5KSbXlTj1BLlM94FXvetsxbWceP7zQu8uWCxih
CuLAA/3ZA3x8kZMjfYJWGu1tYbp7Kg+FxfQN60hgtHX1zgMx5bReYIzJwkJdzAsTJXFNHD16
FC+99BI2b94M/ja437Rkz2Wsy5ognGctEXsNTeZEYqFVKQ3KTMqKP9Npp+jIpHL3li3s154E
k9+qJ+equSfyA97AAxniARpAO9Q8YB18h44eO4ZBRYXOlUbEVjWk6COuddkeUxIZuLPoSp+G
7Ri8H6C1tZW+zd2EU6dO0SrBfxBzou2VBfNZndXSZKUtWcLDNOfPfIgPG8+jsGQIykrtT7v6
2ZcaHNuSnF+Sp0/WUjdfd8fOZPX2F/pk66u/lCuwM/BAch7gt9vyvy6OaYjILrtoGBobGnD8
/fejktyGExvpi42SJZrIz89XAz4P6s3NzepOrvi80qHdVxYWP9NY+K72I9jw8Gx84fYvY968
eai87VZUVDyMnUda4qrau242Kp58U9HpaTfGvU9WoKLGotXx7Gjv0IQNsyswd91eJ0nLXsyt
qMC6vQ1OeEpypkGc518X6nfVoGL2BjieHW2pw6q5czF39mzM5h/Z9fCm/SmxJLVCzHKlVnog
LfDABesB6lo8eXAIXUzf4G6n90797vd/cFytM1INzbQsibcCYFoVSKaakbTtLEF5xYMGDVLy
eXXAZxp+gcWy3WKPpcZv4mBpDdiw6E6sPzgVVauX4rqJwxCuP4BNtYuxfN5DWL35HzGpQCYh
N+3FKEFuBKGnY2kvmV6FKoyOQeiroBgkAzwWPfaGoStXgkCu6NjysR+lmjh9+M2deHPfDqxZ
vw0YdSd9y9EO4Q/fwrZjwKLlj2Bsbjva6Rxs0LgxNkHGpLicUl6OJcSWXzBWTLSKLR6dkysz
clLezLAmsGLgeSAnh76lQbfb8tkw95BQ27nzOH/+PC6++GLP0sqgJ4O1mhhcBiIRIHQmn+SF
juOhQ4eiuLgYZ8+exfTp06MTgk7jlGcPBvbAJ7DYTt+09yc0YQDLnnscM2ROGnEF5j76A3z4
12tx8EgjJk0owN5Nq1G9ZgtobKRBcyqWPVqFmyZ4jOa6cZE029j03ut4vf0juOGqkajbtAqr
37kEY99djy37WOZ0VNdW4Zoy7YYDFzk66JyWaTqyE3//vb/HjoONQEk57vjGg5g/Y4KiqN+/
Gd/7di32KdQteOSxxUoP2/Bc02Rcduh5rK/7HH66YT5KFYe9tScqTh34Hd5tKsUnB2fhdQLS
ozzRumh+v4503oQbPnMVcprCVF+JfbfdWW+iKd0xtwFpD6wrtk3IxCL2RS3iBsUcMptGERmW
IDv1Ekp5xW4pl+STtb6n/MnoE13Mo9urw0WejheYxELvRyO0frHIYRqWpecFJvw6LlV63eSk
Uo/YnkysvtsXmTC4O2Vn0WtE+LbbUHaO0RBjxUYL5GyxsYQRiF5YL6LBgwfTHVOjVeUMHz7c
qKRYRWZ/Zh3c1yP9PUbNO6+/QgPeHZgmE4aioJIXXI6lT9ViFk0MLfs3YilNGNcsqcYza2tw
R9luVD/4vHOLJkayDZByNp7YhdeOnlWI9qZ38Puf/wjvTqnC6tUrUdG0A9/70R6bKalUEzYt
Xo4dw76M1c+sRdWsQmxcuRC7aOcqfGI7KhfXArOWKT03YguWVa7GCZLPNuxYX4v1Ryfgnrs+
hSKHTudgek3lfVh6332Y/+VyZDU7/X70j28BjetxW8VM3HrrLNq+WoE36zP8S4/OIjhK7j6R
2CRSnzYks1J60fRazHS73bwYHVPckAQTvF5Ok7Qvyt2bOqM+MAc/0xFpyvMlCr9FxLKDXiPy
8euuUxm+i0mNvC6za9QWMVriKMJOSAHZqSaZ6Wim5TONadOuxaFDh/Daa69h1KhR6m4uMVDn
kTQ3IL3j2NpjU6E8huWpK+dYrAUJDfsYllR9AjNnTAJa6nHZ2FFAvWL0YAmj/vBhnKRxMxft
yMotw7hxI6i8PCyHLOe2nUPXJx7E9+fPUB8tybtjAl7+8e9x9pvXqqt93U9cLvmxQsZJXuI2
Rpxvouf3h+L6ed/FqGlHcUlxFur+84dEeyPur7weo0jO/7PsfmxauAa/PHgfrlJyZ+HfnloC
x5zJsrQgtjConex2hhYc2n8Sgz/5ddQ89EUMPf0GvjP/USz7/kv4P6u+EPNBFpHFdkvgtNUW
/Lq+UKcoTkKV2Myadbvd8kJr0jEt40y40DOeW63mFgVx41EI+uPkFagdC171B1MwkXnb4m4H
S9Z5OC06bK3pS4k+3QbRxq3Jq5xCw7EpQ+wXmWZe5xWcDks2LXp0Pl2uiddxzOOHZxzTmzTM
5ydHxzGv/nPjZZgZurJ41mBoJ0LhcBh1Bw7QHVTWdajd1U02ykvD5NgaBWKIpEC6oTFEBuDK
K6/AlClTsGfPHpSXl+Pqq6+mu7lyYhzBbJZc0u9qqAD1EYPK1ViPZuJ1bDaFj2DdI2swYv7/
wqxxw4HfPI6ZK3kfKRJo3vAOLXhx6UJspO0gDllZf4WfbpvvqIx28k/JhFFqUGWfWIOxPXkx
zMtHlg9DsM80ivGX3/8W6pb/HZbevVHpmXzLEjwyhSY5lNFvGxbe+gsFZ3s4NJ1vRZgmgJI5
FRjpo4tppc44zcFpVwFmPb4JsywUUPoZrFh5C26r2oPj4S/gUmO3za9cIiL9sRpeuCQJqdLL
r5ddh4sgv/LFo+duk0zw08VydH263fF0uNkRT1c8mRcKvnt+4op3H+wTkudWYYbDdTmc1oOO
E3gy7aWLXzNFMlUpKA7t+OUraDh9Btm5ubjzzju5JYpcFbNw0whGRGGEd6MRvG6cpAVHUpS6
wsJCzJgxA+/THVzbtm1Td1Ax7PTp02rlcemll6pvfdiGxe7J2+ODc6AYf90MYP3T2Lz3Lsyf
wjv6Fj58eDc27t6NRQtysH/jA6jdMgHVz72Ia0YUo2HXKty2Sl3b2yodqWLM37QN8zWY02uW
f7JanVAuv/KBw8d05Ey3Kh37oCE6WCv/NB9HHdFPpR8TfNB+GR7a8DKGNNdj/2+2YeXyWnx3
7P/A3W31QPk9eOGpSuS3hGmSqseeXx3AJeMG4wwfTvgEtsWuC5vQAQufwIZHajHk69/BF8YX
KqIObkBZdK4RmTBi69WaeESO4G0NvZFytgNLI9eHDXcrv5vNYr/gTOtNvJlnep1X16vDmU7H
cd4tuNGIHNHNfKrp6IMV15smUGiF1+Kx24TgNZa0JN3KI7b4KdTtkzLoMD9eXb7wShyPLx5e
bBB53N2turA4Tbwuzw+n03HajVZ0mjiBiwzOC43AvGL+cl8WvTWEWoZqP9k3//lf4Nbbb8e1
tE3lFkxlMTRqALEMYCMSNYTlsDMl8MQwc+ZM1bm2bt2qHvbjB/74x3meQJzB0sWVofQqpD0g
CG3BhJm4szwLG5fSts2bh9FE5zf1ddvxAG3hALfg+nEFdEVOyVEXY1gRDbmHd2JVFd1BVNyq
ViciJ14sZU+k/EJrySzFx+aUo+sXj6Jm8140kH1N9fvx5LdXki+m4NMfHUIHF3/CE4sX4mu1
21EfKsKYSRPB9y4NysvFxM/SGuDg03h2634axMM48Ksfoqp6Od6nuSgZWzxpQwVo3f86ah/5
Z+yvb0DD4V34ftUWYPo0jIznlIzBc0PTGptml9SFZ/ldaDWQq4+5z+j9Rk8zr5nX5XFaH2BM
nOQTs9vZH3QPJKJDdPVmHM83YouzvvSSCUX8mHUlqk+XJjxOG2yKROVKHdqcHilnNXoQOcGJ
2JAIDUvtpMZivW2D/EyTR2jLz/5DXeE3NTXjS1/6ktIsTlEZbl366G7mFZHVEcSJHDtkRGjM
SBfF21FXXXUV+PsefLZRV1ennts4QFtn77zzDi6//HJ1p5Upg7qYAlnNhiYvleeceLoUc//x
aWDFd7Bm2d1YE4GXTJ6D1Y98XW3uFH1+Lso3VuPuW19QsqZOLQd2v4CF66bjMU2hsRNj6dV8
I3guv6SFPTePNpsi+2PiG/HXlLnVWHb2cbq7aim20Jm2hZ+MB/9pOS7P5xJdjhV/+1UsrPpb
VG6xSloy9R78881jkR8ai3+47xCW/t392FJt4eYsW4tptKiiaQTF+WKBMxYbGCp2cJybR9td
jn28Uty5diWOPFCFxZU/V0KKJ9+BZ75lndU4pWZSTtqA5RPLMmkT4uMIlBsiBS6/7hcLa/8V
nPjLxjhTbnjhZUoTr+OckmJzOq3I4ViHx3JZEC6leIObbaTYXuQDFq77KlHfJeKMZOUKvdRj
IjoSpfGS6QZnO9zgUV3UUGh4Rjbdessh62f/8R9dv9+3T932ev83vhGlkwQLk8IJLJlY5xfD
RJ7VaG35gn/vvfewj2ziyeL48ePq7q5FixZh/PjxPoXjqwbpCPbgoNsabqEr5WbawqGr9dJS
87bRMD2ZTneRFRSjgEb8Fv40YiSty3BLS3nccHr5TbyOU2VvaUJ9cyuVIxelZaUxE09XVzvZ
1UIH74W0XeeclrraW9DcSmWL2Cy+FNu62j/Erh17cC76zIk1cLa3D8LHb5gG807gGNvI+NbW
ZjqIL0BRPuu2682tXAwT3ZwWezjdO0GGR/e2wDbo9pk26eX3w+nl8pJn0VjtM0YW26EBTVpd
vpB56WE80wteeCUfi2cfiFS7jkx6myK9KS+9Ancrm1gkNJzX6QQvsYkz80LHsYnzy+s4TnPo
jk0mr5W3246fHjdesYFx/J6/IUOGRO3atWuXspP/uPFee+21Cj9qzDjk5tJ5LH1Tgy9hQ6Uk
ZBptTR2j14kIsyhSgB78EUMSFSF6x44di7KyMlxxxRXqriq+JZif5/APvITypwgVlKLMnCui
LCE1cUq2gJ4dSTRwOcV2nUfK74YXnE7Pk1QZ/ThofVnlLfoQkRS76kIoH8W5ZuF0KWE0nDyN
0/SeMfu+sDZ6UG8YzvPds9oc5GobkRREbPPzsxevKkSv/uHGwOXnn3vD4HLog6aYJ2Xg2KxX
wQmtHvvTiz06B6W9jDDI9KybHsb72abzS1ovuzevt/9ETn+Ldf+Z9ZtoWdz8JXK9ZApe1+Em
R8dbaY+2E0vogHjZwUQ6Lp4N2fwBJupHnV30CQ0+37jps5/t4qfCG5sa8eJ/bnYodcvoynS8
KE51E+MJg+/w4oNx3sIKQuABdw+kuuW5awmggQf6qwd4pVFaWqomDB7H+RjADDK+83guK40x
HylHdojvZrUmm9Cloy/hSQTFI0f4XJM5ZyZTEedFGUvm7suB58eehgJ6bXsQ+tIDqazNVJdD
bGO5qWhtqbYvkBd4oP97gB4GV92LzsBpbKdbbstoe6qlrQVtHWoa4TVuz0rpXPP2TFbA3cce
kEG5h22iR6WItNgYGZlgW4xRASDwwIDzAH9Pg14+hSweBmiLKjsUykZBfiEiX4GNrhL0kkv3
1GGJpLvLl4jsgKa3PNCXEwaX0Uu/asG95YRAT+CBC9YDatKg0vOWFT3mR98I55UFzR7RBQIl
eLDXf5a3vDqvjy+jQn1oAlQGe6AbdZ7BpQlMCzwQeKA7HojcvUX7U1m0vMjOoeci+ESc33Qb
DTzYq18U4n3Bp5EEycAD6fVAsHZNr38D6YEHXDxAZxk0RUTmAJo2ckO5ND9ko62tNZZau9C0
khogljqABB5IsweC9pdmBwfiAw/EeKCLzrs7wh20IUXbU3S+EWoPtyPcwe+coKs43qrSt5T4
wo77KcGy1DYWp2Nk2gCTP0JuiXAyyi26NnPmpKJ3gkVM0m31w0kJhMaPj2l1vPBKLDIkz661
KkMgicemLJ2TbTDxul1+OF1OJqRjbWWrlON8yyi2C79f+ZVEqzKEzRGLDAGms95Yh67Py24d
LnYFceCBRD3A757i+aGznZcbdPdUe1sYufT+8FBuDlroe916I1RCudXLRKKnTY2Ec5sceCJy
g2dqQ44pf6ScbK8fjslMvJTRhIvrBC95iROjlxlduLxjL3nCYZZNt8vk1XHCnwmxaafYZJZN
4BxbZYns12oIKaOfTI08mlSngc5rI4UTeVHCBBNe+pmduyJPiDqNrscLzlxBuPA80MELg+6G
TnrNiGrXvHig54CH0/crikpK6VwD6tsWFk5r+dqgz41Sb4wOGzS6ROB6Axd6N9lC54ZjPsFz
2o1GxzNNvCAyhE/P62mWo+clrct3k0FcRKJ6vE7qSIssk5+JTJjkHQKMjMhz4xeYTuMFEzjH
Ekw+gYtd8fBM70Yj/CIvXiwyhE/P62ldH9MKTpfvJoMI2fk6WUxaZJn8TCiwGCYfgMjT+U2Y
nhc6N5ipxqQRvNgZD8/0bjTCL/KCOHM80MSvRupGyM6mcwz1yVfr4erQyRMnMKyjE/mFLm+2
i0wESk+cDuPZnXhrqxuGCgs3TL+GKHi3Biwyko3jFNVVnNjoZ4eNszwiPK4C4wB7whtHdErQ
Ui9ewgRv+8SklFbj2bJMhnhjegw9A8SP3nZog2NkxS08rgI1ILejCIsGzeyk1IuXlYL385cX
bwDvpx7gLkhLDT7T4BCqe+cwBtHEkU/f0+CgwC6jpkWuSCw6otEbDndxk8amTi4lnVLkSyxS
LHzstgLjTV7hSTQWfqY39XrL6EnpneXQ9Xvr6z7GLFMq9YksU4dYy3g/HNPZ+ORak+h2yhDN
XnEq681LR2rgtl8seXp5e6pBZJk6RK7Ce1z8xeMVGUHcfz3ABwyqnnmPiv6HigYV0+1UfMst
vT2VyuXWVQWuNyo9ze4w+ViJSZNat7FGtiz1wbRbOoa3JrP0TkqT35bvnDCYy8Y5ZaQjZ9sV
68d02ZHOdmHabJfPy3uprLdYHelaZfiVy/RBrFXdhPCFZLoK1E2TArbe8QC/PoR2qGixwdNH
Jz/cx0+I56CtPRwz8ItJ/l3LokpbYxUjei22B1DunH4dNFGT2Dfu/rHlc5+0fra33XlYq21j
ojYInZRJL5c+Fuhw5jHzIifTYt1XUsae2pj6euu+RVImr/ow4Wa++5oDzgveA3xzrXICjzt0
vnHv4vvUIYd1IeEc3KTTmENUvAbs6mRWYISofH3UIhqBC3kyHcDkFRmJxropIotjPQhchyWS
9uKzysf+sXykl1fXLXA2R4ebcs18IrYlQ+Ml3wueiOye8JryRRbHehC4Dksk7cWXfL259y+x
wUuP4Hsae8t32pWMHm+ZyUgJaDPZA7y+sIZv6wk/ei48iz5y1KY+dCSGO7uaNZRx43ALMpCZ
OGqGDlDslGGjvWTYFPFTqZDhr8X9QD4RvW40bjA//S5zrh95UrhEZSdKx8oTLV+idEkVSCPm
duumww2msamkG40bzOTT88n4TOfrzbTetRMtX6J0vVmOQFd6PJBFLyuMvK1Qjeqhby5eirFj
P0LfrKAn/owWruf1tGmajpO0TDLRPDFJWvg5z+94f/vtt1FUVISR9F2P0aNHx9AxvclrwmL0
6T1BFCYQu+nR2bqLj8en6+C0H72JSzZv6iJtpM+GdleeyedVDp0uqLfE/W5T2indl3razfcm
XqS4wePBUlVvYkMQZ64HsvnCS00X1kN+oU9cczW66JSjs7MHD38Y5ZUGxWBecfDyxkrz8OQM
R48exUsvvaSeEbnyyitx++23OwmSzOm6k2QNyPvQA0G99aHze6A6qLceOK+fsGbTm9Cz6M6p
ji5rxRG65JJLECosoE+dliRcBNl4MicAgTsEEVC9h52BNGMxjX4V00pPofNDJ6dOnVL79DrO
ISdORvi4EUvaZGlpqMeHjedRWDIEZaWJf87VlBPkbQ94+dqm8E8Jv1+9+UsIsN3xgPi9O7zM
I/xBvXXXg/2Hjz/zmkM3S2XxpEGvFMnm5zSyCFBcan9wPF5x1GSRzPYP03rQ5+fnqwbIja+5
uVm9ECuefj+8NGYHTfgINjw8G7Nuq8S8efNQedutqKh4GDuPtDjI3DJ7181GxZNvKpSedqV9
sgIVNRatG94d1oQNsyswd91eJ7plL+ZWVGDd3gYnPB25lv14mHTNnjsbs2fPxty5c7GAfiue
358Oba4yXevNlTLTga6XTpludLftGzj11m0XDHhGfvWU+g4TXfLznbahPx06SJNHO0Zdcqkq
PA/evIckW0qeHqFNcLVq8CRIDDFo0KDoCmPEiBGJMSVF1YANi+Zh/cGpqFq9BNdNLEO4/gA2
1S7G8nkPYfXmWkzy/aJsMUpgPfhIH8XV0rFGXDK9ClUYHYuIB/FY9AyKx5cqfGg4bq1ahnNc
zlzS+sFLWLlmB8YPT3z1mSpTek9OKlqvm7Xm+tuNJoAFHug/HuC5oItnDjrG4EPx7M98ahrO
0tbQ7/f9Nrrk5NnAvPvJLCJ3DbN7mHmTxy0/dOhQ2horRoi+6zF9+nQ1gbjRdRfWtPcnNGEA
y557HDMmjUAB6SkeMQlzH12NW8qBg0f4fSxh7N1Uo67sK+iKu2Luw9hal/x7Whrf3YVddY3K
1LpNq7CkZgNqlpA8JXMF3qwPJ1WMcxp105GdWLGAVj0sa/YCrNteF8XW79+MJbRaYdzsBTVR
PWzDig2bsWHFXCrTOniuWUJlmDbjJsyYMQMzPvNnOPnSDoyaU42HZlgXElFFAybBE0YQAg8E
HkjEAzk0UeTm5SInlEPzBk0aF48sw+UTL0NH5HsavNyUJWdvdK3BgwerO6Z4hTN8+PCUTxrv
vP4KUHIHppmLmIJJWPpULWZNKEbL/o1YumYLrllSjWfW1uCOst2ofvB5JDttNJ6gSePYWVUP
7U3vYN+W9Xh3ShVWr16JiqYd+N6P9iRSRy40Tdi0eDl2DPsyVj+zFlWzCrFx5ULsolkgfGI7
KhfXArOWKT03YguWVa7GCZLCNuxYX4v1Ryfgnrs+hSIXySboxPZaPH1wMr591zUmagDl9Uue
3mjl6XbdQChDun0UyO+uB/g8g989xS/K7eDvaYRycjB4cBFGj3KOqnG3p1wsiDZdvn/T4wzD
ZOMzjWnTpuHgwYN49dVX1W23eXl5JpmRF03x1zb01ncKebDez2iIiWRDwz6GJVWfwMwZk4CW
elw2dhRQ72dDGPWHD+MkLRxy0U4vYxmGcePYf7zPFNnKaqN1wtRl+P78GQgx9Mvl2PbjfWhY
Og2lEb3JRG1MfL6J1kRDMf3OFVj9yaO4hGaBAz97lhAVuL/yeoyk1FceXIQXFq7BK3X34irm
wS147qmlcNauQrj8OYK1K7dh8qK1cbbsXFj7NUjaExcifpvKvKL2R5szz4uBRe4e4A8wqbuZ
uJlRVwnxl5iyaflRSlf8vXInhP5AQMTGK664AlOmTMGePXtQXl6Oq6++Gjk0mbkHq4PznNTF
L9CK28lpj77xQzQTpePogA7H1z2yBiPmV2HWuOHAbx7HzJX7bJU0b3iHFry4dCE2WjtRRHYH
frptvoOcN6JKJoxSEwYj2nkSiTN5MZ0dQrDPNIpx+xPLULeiGkvv3qhIJt+yBI9MoUkOZfTb
hoW3brNZKdV0vhVh0lkypyLBCYN49m/HDjq1WXnDBIeszMgkUtfdsTTSE7rD2m2edJWl2wYF
jIEHPD3QwY9j8Bk2vR6dXj2FUCt9G/zUqdM0gxAgFcEazT0kua9fCgsL1X46P7Px8ssvqzuo
GHbmzBmMou998AN/BQUFMVtXiUwc46+7AVj/NDbvvQvzp9jX+OHDu7Fx924sWhDC/o0PoHbL
BFQ/9yKuGVGMhl2rcNsqdW1vlIM7O/+KMX/TNjinCYOUsy5f0I2logqhfbBjHxgnDs3HcZCI
P6kYmvBB+2V4aMM2lDbVY/9vtuGx5bX42/GTcFfbKaD8Hvz0qUrkt4RpkqrHnl8dwOjxpTj9
eqw2b0gYu/9jvZJ1pe0mb/I+waRrsJWJI91X7Gy/hHSVReQHceCB1Higk15QyGOtar2UyOY3
3DY0NKonwlOiQlYSEutCffrkmDFjMHPmTDUxbN26FZs3b47+OH/6NE1sWmDx/NO7oYaOJgsm
zMSd5cDGpfdj05uH0dTSgvq67XiAtnB46+b6cQV0RU7JURdjWBENuYd3YlUVXbUXt6rVSVRQ
yhNsOf+G4GNz6Mp+23LUbN6LBrKvqX4/nvz2SsJNxqcm0gge/hOeWLwQ82q2oz5UhDGTJuJS
whbmhjDxs7PoNP9pPLt1P10ChHHgVz9EVfVyvE9zUXKhGYd2kRs+c5VzRZackH5M7dM4+3Gp
AtMDD/TcA5HboqiL5OSEEMqnK/rcvHzw227THniM9NDDW2RXXXWVuouKzzbq6upw7v+y9y2A
UZVX/r9MJu+EQMJTQIJBBQSrVoQiuKLRsoXdFbRF/pZHCxZcajfZtlTMikFLpam7oaUoLWBF
yiJbC7qFrktxaYWKiLC2oHRLgICRdwh5TzKT5H/Od+ebuXPn3pk7z7zuB5P7Pc453/nO/b5z
7vdubMSJEydw6tQpjBw5Ejk5Of4sCpoBCNMMwpwfbwBWPIO1SxeCTQW7rDEzseaZb4jBnYz7
5yB/aykWPrRdpI0bR1bm0HYs3jgZPxAxyh+7YF5bAG/ePHchndrPcUnJNNjkGR9jHK8bO6cU
S+teQOnqIuyiOW3FmIzB0jUr3HMLo/DcynlYXLwSs3Yp6b3u+gbWTc1DamIeypacQlHpk9hV
qtCcuXQdxpOtITOCTJ27tRQozV/HOXxAw2333jZUk9BZglq5M19e2StcasNmefd9HwoW5yfj
9fI2S1sPLtr09PKw4iwJREcCYnEU6T47TYgnJ6Ug4ccrn28/UX4Kl65cxutv/WdEucgmJvoy
ohvgifHSpfhATYYZPHv2LI4dO4YKmmy+cOEC3fXRhCVLlmD48Bu8dHx8gSh6AV2OGtQ00BAO
fa1nZ2s3Z7hoZ7oD9tRMWpZL8+F8NaLb76+cmKa2bOZ48Mfz8gdHHaoaeEwrCdm52TTUpKXp
Ir7o3pOkNBquU8wSi1lYYhf1UHh4ysOzii57XVU4uO+wshdDleR0puPz941HrtbKqWBi75Wy
1JY3WM6Mp8bRhoPhy3SZvwzLp5q2jLOelgS6pgT4nL/s7GwxmsPz1++//75fQcQ+PYplPTxh
wgSR3rf/ECTSJX2JYgojAfZTp0/havVVGp5y+REwiuDOiqHq58GvIC7QhDunDRs2DH379sXl
y5dFL4ONRp8+6l5GeI3ZnpqNXK2t8PBK+zdov4h0qSq/r2KSEMxD8LJKaOVJkiMURdH7pohQ
ahbxxzxo6cqwnexYpnjpDO+lQ+n2NOJfxPIfHedCzaVqVNPKNO+6sBa0tPRBE7/6DjUawd6n
LL8WLlhYRwy6UVo6ukBWpCWBHikBviM8gSbAnXScCB8JJVRFr15ZSGnxqpJgkjEyGKLpkSYT
TVzPeLCWk+0/SCZ86q08+ZYNWlqady2RP5GOafSKATDKWxbUKJ0FINMkLMexn+O9cVKUvFpM
+gWkF0SZ36GwsqKMUyVt9pOzD8CDs2Yp/i73V1OWqPEvBRgr+lpGOb945aXN2wqzBOSXdCyk
Ife3xYJ2R9LkqQveEc66h3eE27Oze+HKlWo46ea+mDtFy6r1YdAsedWU13GDkw1diVVIdkxj
NKoksmLqpXt7B95SKYpEXQZ1j4QPYOTKrvzUWNIvaerlJ2Gsp1YCsh5JJa6WvxY2lHAgOjKv
UOhZsNGSgGyX0aKnpSPpd7d2yFe9JifbaYjKTtqXdoSnpPD4eBoNU8TYaFB7YWFGt9kQvegS
1NaDsMKinLqMMbPqn5q8qiBSn4lkJZ7JqUkKvydOhasmaflDkEC0ZMh0fF6gmwe9uBDYs0C7
jASk8egyDAdhlD5hhe5pbWlFq9MJez2dLOtw0EawEOY0guQh1KKnibg1nWySMp6fMi4YPd90
daOUVCRVX8j4hyQ/vjmHW4kC4XHPg53ykOWXTyUt3n+7zheWWk7sD68mBpavlm4s8gjMgZXa
cRKQbbfrtAljWfEGcN7gx+dOscKxXaFJ8NZWl9g8Z4wWfopsKtyE+OczKB82WaYqf0xE5hI2
wSggitJFgY5FIv4SiPa7k/Ux2nTjLxkrx8gkII1HZFQ6FjuBx6dIx7bbaF6D/HY+8TYjKxOJ
Qc97Co9xQ6HJ+Y3wyHYyLKkcpLLoZOx1O3YikbfEVQslFu+NaXJe/IsFfTX/lr8zS4B1YFfu
cdiT6OY+2qMhajP9sfft249WJqXBRvsSZPUWY1gRVHRDQxG1Nys5jRrBCAgxL5aLjwQikXUk
uOGWzjIW4Uquu+F1ZcPB5wAqa2LZMpDRyMntI95Ps5PO0iCLmMBzEJyiU98jNSbRqgjKeL4y
OaPLaLQyMkWHBdURCskUcz0ESE/+6gqsrtASVp3OYpLx7NemcZzlLAlEJoGuaji4Zdhs7Wjj
KQ268tXe0NRIcxrtaKQNdHxft7JEhxRyhA3HTG8j/C4bmS8qiTLH3lENnEVpLm8zsoisOnYO
7PDfp1n+1e9dwfHWAy8Nbxy/HzPGwAyMl77l65oS6CztMB7tRKubWvkyjDBdGx9tS0tteWMf
y9D+wJf+jpbbtoC3mPPdFp3BxV6o8S1lZ6mssS51uO+N5WMOVzEa2nLofzyoDYEaQ2vozcKp
aYTr57y0+YdLy8ILVQKdqR2aq++hljAwfD0fjRSG406FjestWQ3ubdD/ruaMGnlXK4fFr+wF
iBFR7h4EcRKE4RVDEQiBlbPej3E4L/njsHRqeBkXzSfTt5wlAap9sjJ3AWHwklteMMXNSdzc
1wV47kQssqIJ1vCl8gsG14mK1WGsSBnxJk3uRZjtcSgMe3sY0gBIeoEKJN+PhDGDI2EjfZqp
P5HmYeF3tARqD+3GxU3PwXnls6CshNPjSOo7GAPmLUevcQ8GpR8VAGoifIVGG196R23UfuDg
f9FJVKmoPPcZZnWJs4ni2ci1IjeTtxkYLV0rzMZYOTfLWLEqPRIpKz05qw2CNl2dJmnE+6nl
Kd75W/nFWgJsMK6UPYFMewJS0sydAhqq4WiuvSDyQNHLcTEc7XRQoeiZk9FgXu15Q0ajlWbE
+/UbEGt5WvQtCQSRACtVVu5GhkMaFi0ZtTJW4+oZCjWslo4VtiQQmQQu/uI5ZCaSweDhJx7S
MeGojy2UsQlQASJoJwKcVzx6G8yfcGKTHy25TU3NoHGqdjQ1eC68Nsu7BWdJIEYSCKTYA6Ux
O+p0tT9GrFpkLQmoJNBy+TMkp9G+huCTbiosxRsKTjLpcc4rLo5OtuXTbXkGnO0GbQx3ge7X
INdxc+LBhNVGN/g17H8fLr7L3O1cly6j4YMjaKPrUS3XnSSgVvTuL5yQisc48hcSogVsSSBy
CXDvIoRf2pxlyH2tXPz6rP49Eq8fIfAT0uiiuO//RsQHpBc5x8EpUHNKoN6TjX7cgbI1k0Xk
pVgOR1Nw5BhA8FLf/fv348iRI/jsM33L6bpagytrNuDaL7airZbuM6+6iqs/ew3XNv8H2uob
Y8CVRTL2EmDFHsypDYgWVhoG9VMLE0nYDH+R0Ldwu60EuNqa+KXNXYb0BxZ4xJCYOxS9/nmD
wE2fWwz79aPgOnvcmJYHM8Ye0QypPYg5DZoIb2xsQ+/UJLoCNVADjR1T586dw9tvvy32iIwe
PRqPPPKIX2a2jDSkXD8Y1/7jLbrZ3Ea9i2bU/eZt9P7ql5GQLLpJfjjxjvBf+SOVTsfINd7l
Dy0/KZvQsLzQyhePJ0wi9kpZ+vTy4DiZ7sE28JiFM0C3onukBNppT4NYnmqi9OkPeg2GBBeG
Y/kWJN08ngzGJ6h57lFDepxXPBwfUsg9jHY66VasnurfOxEOp4O6HurLjuLBipIH70Lnns7V
q1eJH72GThMvffogZ8kCuGpqcXX1z8UxvVkzpqH33FlIpFsHzTpHTRWu1DUhLas3crO9V7ua
xQ8EJ4fYXOKebmnIfF+qi4fS6FIpc2sqAuXW1dNYLvrv2mzJ9IeMtUZBLw8tjNkcLThLAiYk
wFXbt9mbQPIFSR45QTEYK8hgNAQYSYkwH99cjUM20stiAVUbtR0yILaaaw1wtrSTItZrYMaE
opXCu9BZ4bLBaKC7PXgjib8j6dBETDud595Ox7jTgmEkUo9DmD9/YP8YVyU2L5uB6Q/Pwvz5
8zHr4YdQULAM+ytDnw+pP76ZcOfgqM7myuPbCjF1+lQUbjtBPPi+0eObOW06Nh2t8edPE1N/
fCPlsRHBITWIXSroKx/zrAerp5wuYTgPvZ/53CxISwIhSSCE+Qwjuq4z1MNYTgajjgxGMHpG
RKIY3+akPRqtxIiYDKeb+7Ky+iAtuVdYs/3R4Cs9PV0YDDYcAwboL/ttvVaD6pd/geb//TNy
vvUN5Cyai8Z9B1Gz5Q201elobx/GarB5yXxsOjQSxWu2YCcNhb25ZQ3mjTuEkvlP4XjodsOH
uk+Aznxkd2z9b3DRo7g4phJvbTrGHvMuKxmd41AX8yx3Pki1AVFzZxSvhrH8lgRCl0A7fdCK
ISoepgry06PuJINxbfks0msNwmAEpMGXd8fD0Qe9zWaH3ZaE5IQU2Jxtdlo31Yomp/w6iwcX
3jz60NBTZmYmzanYMXnyZN0hqjbqojnKT6MXDUn1WfhV5C6aj8y/vR+NH/8FbXzIYgBXf/QN
bDoJLN3yAqaMGoBUyidzwCjMeXYNpuUDJyvZ6LhwdEcZ5hQU0Bc+/WhFw+5yxRiV71iFFZt3
YvOKORRv9uv/t/j9ccZXZFp/dC/2IIv+qZ0DB7etwgx3nnOWbcRxddei7hP86qVlCj8FM7Bq
2xHi0u3qy7FxGfEjcBdh8/5KJcFRjlWLVmH/kd1YRmlzNh4Fao7ipUI3LJVr1bJFWLGDJte6
rJM9By6AXqOR6eqnNBLyqcaV9V6d1mWFYzHe0RII1jNQp2t4ZYPR8MpytNea6GFIOhoasQim
pGQgJYmG1e0psCen0h3hSU1wksVKT45FdsFp9urVC4MHDxbGon///rpGI7F3NnJpTiNn4Rya
3+gNe/++yHnia8j56ldgI4MTyJ3+4PdA1myM13ZiUkeh6GerMX1EJhzHt6Jo7S7cUViKDevK
MDv3EEq/uw2s9p31p7Fv02psOjcCj399IgLnVgXkz0bhtCys/4+P3Gy58N6/b8KgmU9gJhkp
aeLKtz2F4vV7MH5JCcpKlyL30FY8Of8lEAVy/DIOYdPvUlGyZh1WPj4ee9YvxcrdbByo5/TE
YmytvAPfX7MGT8/Owasl8/GbCgep0CacOrkHzy4tRWPBbHxtYirWzi/Cr8+MwLNE51k6deB3
h06i/KrH/HBmXdixolcbBz0johgF/+kyaSQYR4HRN0JdWDwW6/GXAClz0dvgHkeQn5o5Nhj1
G+hokO+9EhRP0jW7eVCdTzj+FJqHTUmhX2oKkumyPnsbKSh7QjMS26g71AGO5zTGjx+PkydP
4sCBAxg4cCDtG5ETyQpDtox0ZN57tw93SYMGgH/BnF0Yw2QkBgC059yGwuI7MXXKKMBRhRuG
DQKq1FZ0Grb8rAicW/3xDwNQoqTGTIybMQdYuJmGviZhlOs4Nh8C5iz5PKoPSNQa/OH1Yxg0
uwxPzRgrIl/c0IKpC1fjt8fnYoYbbOm6ZzGJMx31FEpO70HJ5r24ekMyNp0HHl8zF58bSgNY
sxZh5s5D2PbOCUx/TEHMJ7qrF4yFq3InVtKezaVbJJ1nsWT/dGx204/vQyr4aOUqlX0gutIY
UEP2sSc+AWJIG1Z4NFqYEa0SdBY6chFHZ+GnS/PBQ0bcCwjiEjIzPBBsMOrKCtH7B2/Alt7L
F1+/aiq4nFccXEtzExLtSbSpT7mMiW7yS0RzmwvO5to4ZK+fBS+1HTt2LA4fPoz8/Hzcdttt
NNEdSM3r09GPTQfqroBNok8vgSbHNz6zFgMWFGN6Xn/goxcwdeUxLwmyG+xcLY3ImlkgDIYS
E+gvKal6J7LzpmIaXsJbf6pBf+d2nMdMTBySgR3KiBcZpss4Ssr8C3cN9xCzD8xHPoVaXLSs
zc6TI+NwU64nGTdOKgAOtsDVpMStf3IWfu5NFrisIjn53onDxbdzczXPrORjULYETMXYSVQw
yju+zqu8o59vqA0nVPjoc2xR7MYSYINBTTiQS8jKQO8XtgkQZwUvq12A7OUbFYPBsT741HZ8
v3i8pE0YJy9w+L7mlmYk0XLbhASayiB7YW9rc9LZU20dtnqKi8LXzU6ZMgW8Z+Odd96hS6Fa
Rdy1a9cwaNAgMXyVSl2kcL78hn/hPmDTeuw8+nUsGOvRnnBVHMLWQ4ewZJEdx7d+B6t3jUDp
ljdxx4BM1BxchYdXuWe1w5J1b/zd47dg8U/LaDhqH8Ys2SgMlodiahaGEd1Pz1wDxrpNWXMV
Lnny4l7OX3CRLF2em+VL//cxxd2LRJoDovE2lGz7Fe7OcMFlBy78+UNcyrmevpfPKhTY8JCz
Z+XQ35OoYYspVlQ7cHQ/dVPu4tR4OlbUsTAcgQyAXn6B4OMpDyuv7ioBZegocOmyvv0jJOWN
BhuMayVfQ++SX4gwYzV/fICGp3zxjWwG5xUP10b6uJVmvhMSyHAkJcKWRN2OdiShTX7CxoML
nTyGDh2KqVOnCsOwe/du7Ny50/PjcHV1tQ5W8KjUEVMxjz7htxZ9EzuOVKCe9kpUle/Fdxav
JeRpuCcvlXoT5B3UDzkZdlRV7Meq4j3ULWkWvROjHJy6CfwS22nCuh0jCh5B1vl92Hd+EGbf
l0fx6nmEAZg4MwuHVi/DzuMXUV9FE9vPllAHYDLuHyUNWx2KV21DZT3xe3wnlm89T/MidyF3
yG0EVYeSn9IKLSLZUPkhli0twWt/VboPCgfKgEtK3jhMopxLnt+Miqoqmuz/IdaeBPqrR94o
PT4uPhU8sHHSMyTxKb2VSw+RAH+vsdI3+GV+9wWk3TVVGIzqf/4K7PmjhWDaGmrR8M421Dzz
uCGuH02fHkns5JtAWx34x462+cHOVqylhSbDW/hztOOcjdYA33rrrWIV1XvvvYfy8nI00plT
J06cwKlTpzBy5Ejk5PCXc6guG3N+vAFY8QzWLl0INhXsssbMxJpnvgEeAcq4fw7yt5Zi4UPb
Rdq4cWRlDm3H4o2T8QOKyaSpA1+XjiT6wvcqKEUhJiUTNTkGlnsb5o4B1qbNwufcdoB1tZwI
H/+NdXj8MvVwnnwMqwXxMSje8G3kEV1lFGsMCrAT8x9aL1KzJj+OF+co8x/f3lCMcwtX4qv7
lNIMKliC5Q8OQYKjDjxSmmJPdH/XD8G/bFmJlYuL8fisTVxojM2i6RpPl0eQ7oR/WLmHY2Sk
UZBPLpqko47rhEW2WOoWEmB9GqgHkHH/LLSc/gTVRV9GOx2B1PyH39PyWhpxIOc8IhfP+IrC
aM7JqAfiix15yJaQSKqOT+KlH5FL+O1v32qvrb6KuprLWPjEdyPPIUIKLKAzZ87g2LFjqKio
wIULF9BE95cvWbIEw4cPj4i6y1FDQzUuMkx0GFi2dge8i3amO+jY30xalkvTDnw1ottvnKla
EUnl5A8daFjN5aBzv2iMKTNTy49CR6TT2FImM+XjFH6JYZ00N6CjAptffge3/L95NOzG+LTy
as7D2H1vGTbTRHm0nVHlDj0fKVdjmXppGsEaxXsxg/kCvbdguF0pPXrvrXOXOh7v8093D8WA
ZG1b9col8eZ8tJ0/ryyrdUcP3Hta+C5MGe4FVPmM3s/FFhc+98dPVZCBvXzOX3Z2thjNYVm8
//77fghSRpznhAkTRPr1ebeIxUntNG6WQAbE3tZcg+TUdNgd8hPZj05cI5jpYcOGoW/fvrh8
+bLoZbDR4P0ckTp7Ki3d1dfNRJoVt1cGqSq/cb6s1NznspjRbzqE2Eh5c/UHME735dcfk2JS
SWZ/2Yqlj23F5GnTUP3uLhyrG4SVD9EqsZg7VtphCkXwpsWV9OSTgdgfzEkYLb1geFa6JYEw
JMDVLEBVa/0LjQ+7Xdqjj9HwlPfjLevpVXCdPIqm17dIEOVpRM8o3hc74hDPeztpKMxOG/xs
tECJNvllI7GlllZP1URMPJoEMjIywD9egutyucTEeDTpR48WrceO08sLnWcamvvZTnzhyAEc
PXEJLQtK8J17J2FIICsVeia6GLwvIjS5qI2BnkBlHD8lrIzTsiANhTpe4qjjLL8lgehKgM9o
MnuQYPbi7/tknvHALIB+jVt+6RNv1NMQ50H5QMYmwAulkmnIm3saLlcz7E4yi808q2ujwe5O
6HjVlOUikUAqRtwxhX6R0IgHrtoABFPwalg93qRh4TQ1rDQm6jg9fCvOkkCYEuCqZbJ6nZ+U
Zy4TI3pG8eaomoZKS85AAq3Uam7hDcRkKpKcDbR2in5kSSwXjgSkIgoHt7vjRCIbY1xewWHO
yVbF8Mowojk8C8qSQHgSSOo/GM0uqncGq6eiFc95cF7xcDwP3ka9DB454PvCbQlkLBIpts2h
zODHgwkrj54hAR6i8jqfgDfax6cod58oVUAxFnp01HFaGt40aUJUJC2vJYGoSmDId1aggU7q
bqbDCttIy8bix7Q5D84rPo5Otk2001VG3AJpyS0SM9CWSCuFUmj7uuWCSIAVkFb1aMNBSPSQ
ZP4qUYyGV2kbF10FQ14hZR2xyij59NLzj/GmqXwmwVQYlteSQEgSyL73i0DpBlS+uBwt5z8L
CdcIWDunkTxoMBmM5yDyMkKKYjwvtJV7NRIS2nlHeAtZxQS0cR/EchoJCPWlibOC5iTAGto7
JBR4UlylzXktuLAhqjjFjBA9dVwwLpT8GVWQY+xQ0IORt9ItCRhIgJV5NBW61mgYZBuzaJt7
Yx9nwB+CNrutDYntaaivoeN4LaeSgFQ1qqiQlJYar2f6WUmHrqjDQjIWsJtc6HwYk7RSLAn0
JAkk0TJbMTQsjAcNTzlqLqKmxkmHFhpvSOlJArLKGk0JKJ/2isJmI8w/JS5wLmbh9KgwfT2D
L2HN5C9hraclAUsCyUkpNDfjQAKd2iHmNNpcjUjvNRA5bdXg+7o7g+vo7phXBpEoLxUV3xlh
b0I38wV7b97dprLgvgqc09nAsLgUQ+ObrmBJg6CXJulKGBnmZyB4NZzl764SkPWvq5UvWLsy
Ux4+BDZc10J7M3hC3yYaJfU0mtuSkZ6VhcrKi3TRRkq4dKOKFw0hRc6QVDyRK5uuWllDlaGZ
9yZloWcUAqWFxot8dxIr8ncoKVnPrisBWb+6WgnMtCszZarno5HCcA1NytRFK12hwTK09erd
m45GdyArpWMPLAyjLHFAsZRNtIUsG4Be54vToi/x6FOMtkwsepYEOrMEWmhTX7OjiXa60/w3
Lb211za1I5GOX7UFvNuuMxcpFrxpv1RjkUfPpakYDgMZe3Q8p3sCIQqL8Qzoh0jJArckEKoE
ag/txsVNz8F5JTZLbpP6DsaAeXQ17LgHQ2UtLPjMdDrElc4nTE6hUanMLNgTqcvR3kIXMbXE
/Tq3kArQ7nSirZGuHcz27idpp7sx2uhcqkRThwuGkp1UVpEorlDy66mwBvI1iA5NStE0HFFh
KDT2BXRH5RsGqxaKkAAbjCtlTyDTnoCUtOgsLpK9cyni5toLIg8UvRwXw5GWli6mLhxkJxxX
L9MxIo7P0NJ4EZ39igXHX0/i6itb6Cz6M0J2bCxq33ob9f/532Tw4s09N2bLRSoBZYhKR5bS
ZgfsLejg+THkIeSXElpEtOiElmv4Pa1Q87HgoyWBi794DmmJZDC4csfoKBGmzXlwXvFwTY5G
WmF7DU2NdWiqb4C92pmJJOp2tNojP3o8lgVobWhEw5530XyyAjkLHoOz8hyurN2IrC9OQZYy
qxqF7FkRqRWE2q8mbxSvhrH8wSSg/9qkbM0YhWA5cLr2nZrBsWAsCYQngZbLnyE5jU+ElfU4
PDpqLD1ayVStOa94uBb6KLeRoUrkk27pn72dLgtHYxWaOsF9GlI48qle7ZBGl5f0fuwRVJGh
uLyyDG3VdA/IyBvR66EvUXcpKUqyi96LjhJDPZhMsHcRLD1aRqcHvwKr6KFLQPYuTGKmzVuG
9AcWCOjWqk9RV/Y4WivKkUDXQvQqfh3260fhymP5+tQ4rzg4PnOKb1ZV1sGT0UhwVOJKdR3d
Oj0mDtnrZ8FLwSorK3Hu3DlxSx9DJZEh6NevH/Ly8sRtU4l041TW309F7X/vRcOv3kJbViau
X/pNpN4yUp+oFduFJKDuDUhlH8womC1etOiYzc+C6/ESMFnl1AaDZZaYOxRZRetx7VtTkD63
WBgM19njvoMfHSBcW6JiMPheI+6527P65qE1sQ7Oq+Hcvx15CWpqarB3716cPn0aVVVV4sIl
7mFwbyOL9o/wLX6TJtHFQX1yUP8/++CkOY30+yajtaYW9f/1DpJvyEPKiOHKjrDI2bEoxE0C
3LKUs6l8e/JKfHTYMGq9aiMVnZwsKpYEWAJ8AROdIm7KpT+o9DDUwMJwPPNLGkWZANfZT1Dz
3KOG9Mxe9qSmH47f5eKNgW10PiF/zCfzKbcpyEy5iFz7p+HQiwinrq4O+/btwx//+Edxvevt
t98uehXcFWJjcurUKRw+fBiNNKb2YP9BaF/3KuzXDUTfwkVwVZzF5VU/gS2nN/p971uwmdiY
6KipwpW6JqRl9UZudhyur4tIOj0BOZDhiKT8gYxCoLRI8rRwLQmQBLhKG32rmBSQx2CsIINB
c7mG9CLMxyQ74qSQ1NQMZGVkoXfvXNhPHfs9WtptqKuPzvIws4zwtvaPPvoI7733Hm666SZx
ifnQoUPFta7c02hsbMTo0aMFzMEPP0T2uYv4wh23ou/M6Ui78za03XoLWq/SHSB2u6FMPby4
KrH5mSex6ZB6WfE4lLz6LCYN/r+0YwAAQABJREFUSUX90Y14qAj49Z4FyPYgGXnq8VLBQ2gu
/TWK7jCGdtUcx2/evoB7Hp6CvjTlcvSlAhQ1l2JPUbSu0KvH5hkPYfv0MuxY4L1nGI6jmDO9
CPeWvYkFYzu/YeQepTJ3FS9lHqeWZlR9rPjuLYEQ5zT0hOE6Qz2MZ8lgkA4UzqjKmuzR6OUR
SlzvPv1IL2ciIz0L6ekZsE/84hPg2fFLly6FQidiWM7z3XffFcNR9913H/LzvZM9rEiyaQ6D
f3369MGZM2dw7No1THjsMaTdMlrkbUtPQ++5s6g7SPs0kml3oqGrweYl87Hp5DgUrynEF27M
havqBHasfhIl85/Cmp2rMZTtJd1263uIipESS8WU4qVwDcswzJETXOfew9r1OzHiHxSjcd3k
YhQjyjdtkU3QMwvpgrPwz5oJWLAYJCrDU0YtI9QM+b3FyhnViVjlZ9HtahJop2tRIxk2crLB
WE56rd576rhcGKSVBecVDzfk+nyaa3agob4ONXXXaCN4Bzk2GhcuXEBubi6GDBliyAWn3zB8
OGrJ6rakpfLImgfWlplBm/3oa596Jkau/ugbZDCApVtewJRRA5BKPZPMAaMw59k1mEZ26mSl
+zyWukq8tXEFCgoeoN9cbNxfKUg6ynegcMVm7N1ZRvGLcKTegZMH9+JMtUOkl+9+CXMKCiit
ADMWrcLBSgcYZ/aTWym9DkXT52BHeT3qzhzEwXJ3T4cWH2xesUjgMN6iFdtQyXNM5Mp3rEJh
2WaUFSo0C+aswJEqd6IC4vs3WdNDpPL5uPpybFwm85qBFZv3Q+FcyWvRijKsKpyh8DKnEDuP
17jR67GTeCxctQqLZii8zFm2GRVu5PrK/VixyI03YxE27i33yTb0gN471IszQzmWjSlcnszw
bcF0eQnInoaZp6awbDAaXlmO9loyGGbwvapQQym6wSuXL+HatSo0NNWgxdnYcUZDFouHqXgo
ysiaOmjXd2NTk1ht7yJDYzzAJyn6Pk9/8HvqRczG+AHqeGr4qaNQ9LPVmD6Cv9W5p7IP6z/o
h5Vr1qBwGrC15EWUk4J0OetxbN8mrFx9BNPmPYphqcDFg4dwtqkVrsqdWFy6HXcsLcWGdSsx
/tIeFM/fguZ+t2PBzDEiw2lLvo5x/VJRd5GMxvlaEXfkZer57MtBcdk6rCstROO+9Vj7doVI
c9afxrFdm3BmbDHWrFmJgvp9eP61wyJN78/5w+9h/8GD2L9/P/3o+T8fgmyk21Vh4xOLsfVQ
GgpLy7ByyT3Yt6kE/7SNVmSQ47xO7tuFj4ctwLp1ZZg35BhWP/lNHHTbjepzJ3Fszx7c9a0y
wWf6oU1Y+E/bUE//djxZgn05j2LNhnUonp6GrSsXe/DcmYfwICXvp4vlBU6c4JcYAm0L1JJA
HCVAilz0NrjHEeSn5ooNRv0GOhrke68ExZN0Vd/PalJR99fUXEV97VUxjJxoS4T931Y+R+eJ
ZMNJ7fYrX/lK1DMMRDCRLve4evWqGKbiL+70dGVgReK00T24PBFeXk7rlqk3Yaev6FDPyLKL
katk1clacsUOKyL1F2kWVv7rP2I825ChRdi4qwy19IE/0M3MknXrMWMEWQxSmB7n7gDUVjfC
3u9OFL76KqadAzKyh2Dqg5/H6u1NmPp3UzAkKQHVYiCJ95O4kDNxKYqnjqeeTzbqq5pwC8V+
fNHdC2mhr4xxS/Higim0SoFWKzyajz2vH0NN0Xi/+ZZkFtexrSgppqeOc5TvwdbzwJINqzA9
j3i/YyzW1P8FT67fi5pZoxQMMqg/LZouaI94YQM+KViIvUcvYvwkGn4jVsYsWYcFU0YQ7Fj8
a1k1zf3sxOn6acoJAk31VJo+mDxvBdbcdQ6DAo/Y6XCoivJdQiUSvFHq96TC0fWGAqtLIEBk
LGkHyNZKClEC2rYdInok4DxkZKIHkECjJNKxwagrK0TvH7wBWzodk6TFN6p2cRqecjkdtLHP
LnQwf+Tbbr75ZuQNH4YB/fuJSFbOEf9IGvL70I+WW1K8D6N///6il3HgwAHwSiqtY6Pxhz/8
QSzF5WPbU1NZaYfqSLPWXYH6DF+hjGhyfOOyZdhJQ0e0t5J+D2AkGwx29iRS8fJNcVoBJgqD
IVI9f+x5U1G2ZBo+Wl+C+Q9Px/SHl+GDCw6h7B1OBmuES44FebEwcHA2Dq5+WAwJPTSrCHso
Ld09LcN2KGvEIEGDUZxsRKgnlMgBjeOkrNll2EO9Ac+PhtEGueFcTuZ9DMbSZL90w79wH3l/
h5NUbBcRyJo+UWWMBuJu6iAd/PNnAryFYMaOlGaT5k9uvI1on8cnF+x45EdLMa5qK4oWzsLU
qQ/jZ3tOwqUZGZN5hveU8pfP8KhYWJYE4ioBVvg8nRjgl0CTyb1f2CbYclbQHMaKBcgqXK0Y
DI4NgOuTpjUugmIM/tD9y0n89U2Ks7XVCVtu335IJENhE9xEKUOiR5bHTUzT6NkoUQr3Mq67
7joxLMXDU2wgtI7jeOktP3luw9sTkbS1GP5hRUnuws6jcqye+WmnJbsf0LDNITg9cwApKsWs
4TmrH7zfBd48XDUXkDbucewgpf3mtg1YOjuXhmloDkLVGfFofw/aRayeX4yPP1eMbTvfJmW/
E4+Tlm9k/S5dCHdhSTsnUf2fx3BBFp0Sr5z6C/29B4MJketB3Qd/od6CdA04cQwYdr2yZ4ft
WOUFlbm9coZMRhZuHOjCZecNeGozGas3t2FNyeOo2rUaz+8ol4QieJp/txFkYqF2awlo2m8c
y6oMHfEQlfEv89s/QlLeaLDBuFbyNWQv3yjCzGbzxwcC4vrSjU857fQRnUBHortcTjjp4Fhb
C88Z0Iy4i85Lj4kT5dIUjgwHDzXxxj3+3X333WIjH+fPPQ42FNwNYsMyfvx4DB8+HHl5eWI5
rsKjhl4AxlNHTMU8mvDeWvRN7DhSgXoqb1X5Xnxn8VrCmoZ7eNgmmPPvBAkMx9n/xOL5D2Hz
wTOwZw/ETTcMo3i2GKT4SMDsP3OiEg6vVgYdE4nTlDJkUF9areXA8b2vYD0NIaGZexTRdZk3
TsZkIlny9EaUV9Xg4vHdWFa6D1nTJkKZ4smllQBr8eLO48RjPY5sexG7CL7gtiGCkeT+NNOz
cjn2VtTAUUMT6s+vpngyOKmf4kdPLsb8sr2osmdg6KgbwRhpSZF2NbQGw/x7FgxbfywJdLQE
uJfA378Gv8zvvoC0u6YKg1H9z1+BPX+04LitoRYN72xDzTOPG+L60eS84uDsNCrELZONRlub
k+4Ib6hHKw1jGE1ER8wT5ybaPv0hYyEdb+AbM2aM2NTHQ1XV1dViNRXPYbCbOHGiWFV1//33
4/z588igs1iSAy6tlZS1z2zM+fEGYMUzWLt0IdhUsMsaMxNrnvkGSG0qsxS05NbQadL4C5w7
A5lj56F45gmsLF6ITe7hrGmFZbiVv+KHT0TBoH/H6qL5uLT6LUyUxGkCvnBJAZ5cW4SHmJms
cSgYl4U921fhyNwdSJNw7mcST1wYdCeYDzGHr8HhqY5kOlwM9jx8b0MxqheuxOJZvJqLs5uH
dU+OF36APhQGjcHpjU9iOtsDcgWFazB9iKL8xcjYoEasXPiwkkhDXSWvPoEB9lQ8t3IeFhev
xCy2MuSyqMf18tQ84Q//j2UkwpedhdkZJMBD39zbMHIZ98+ik7o/QXXRl8Wy2uY//B5t9NHO
znnkI100I93snfPTRYtaJE8xtJLB4KGpdhr1SXim8FvtrbTXoYF6Gqt//krUMlIIuYWnliEb
DiqtjOLzTI4ePYqGhgZa1nUNb7/9tjgca86cObjzzjvF/Eq0mHI5alDT4KJeTgbtATHRwzCV
MZWHJi7qaRIjle718H5rSwMpN69piAkcsgeZzIcL9fUut18DF6Wgg873cpGyz0z1cnh04xws
x9O0OXAU5V8PeypdtuJJrsdG2jyIH+wEJQv+fMvHjLngoCXIhEjzTbTJMl61OEoyscj0PAmw
Aoyl+9PdQzFAuwxelWEiHbzaRh/BYlmtO37g3tPCd2HKcBWk4g3Upi62uPC5P37qhyNGOjyx
UtNC7MXjvW9ynvn999/3QEmPlA/nO2HCBBF94013iB6Gs9VBe1Baqbmnp9DaW2rwtHnDvCNG
mBch/2AvgdIT3PCcgcpgcJCZ5AlxNh785OEpZpj90Xb21GzkRstWeJgjo5CUiiz6sdPTm7ov
no5voc6TW9Emkj+6xyl72HN7UiizFMGftxK1O86hlobFmD/uyfFL9fLfDkdtO42aUUVpz6Z0
wqZELzYTTgTTZadbRpHC9cMXS0R70thjlO6F9PqUOTEFwwhP1kmjdEktEG8Sxnp2JwkY19Po
lNKzHNaAnOt4uScl7dHHaHhqrKftZC57Aa6TR9H0+hYPTECPbvU2W/cDUvZJbGp2T4rSkFsb
6QB7YmISnY9Oa2+Tk3wAdQOsUdSWWjDt5lwd70GWBaAId/vUlpPnLQYP9u6UHjBggBAiH1Yo
rZ6HXKfzKIVSi0UtBo7vzO76L5WhFNcbsJiKL5WWAjfpLQEwQNGNNhKCrBtG6brEKJINl8TV
wvDKPyVOUA1KOiiANgMrbEkgoATaaZ7B7I7w7MXf96GV8cAsWsQ5C41bfukTbxTgvPxd9Ou0
q5lW6dB0QgIdkc4fjna5csm4ITJbxEhQXhhA3ZjN4PgXmbtPsXXEI7MpyhO0UEFYkfjyC92r
tBiRFVg7LVfzOgnvjelIX3beWBifhGVH3h3Gqf58y3KaLSPDSRx/aoFjlCE/Rbbq/OR7YNJM
m3/q9MBUrVRLAhFLgKubySp3flJeZNmZzCeyTGgfNN0P7qJhKZ6hb6dRIzuv5W+hsTGXi6f7
DVyozBl8YodKxoCbCKPZPNLR6xFS0UeXSktRhqy3PF++sclQn40OiQ21gJEpdKWKBciTk0QW
keXTIaK0Mu2yEkjqPxjNV84jhb/KY+iaabKd81JcbOt4Uko6zdW2k51ooslwF2x2Oh+dVzIp
R3QYlzJA89QgmYfUIMYtqIxrxpJPhbaB7YxbOTt3RpHK3whfNlZKFyBGcJ1bOhZ3XVMCQ76z
Ag20wqiZ7tXg8f9Y/Jg258F5KV9GLCtZ76MvN1uCje7RSEGKPY1WZabxnAZdqUHzClS8KOUW
W6sXJSbjTkYZqop7tj0uQ0vOPe6Vd6oCZ9/7RaB0AypfXI6W85/FhLfkQYPJYDwHkVdMcvAl
aqMrwVNooY+N+hsJrmbY26ibw7v9bGQ49J3ypRbUjjFYAKCe873nKwTubcghKn35dqdYddnj
8caVlVRc73yHq5gPzj8ePHSn92eVJRoSYGUeH4Xubm+iuseurnPHgu/TsNudSGimRVOcFRsM
G62i8nPW+IqfSMKJ6JlilIo7HImZxeHaqzQcTw+Dojx+s2QsOEsCuhKIRx3WzThIpFLnPUCx
sxcii0S6IzyZpjH4G6yNz56yJ6fQUioyGvTzcxre/NKtCEsCPhKQtVc+fRJjEuCc2ChLw8wL
chW/VXljIvAeQZTrDv/iV48jE2ts+UxIINtA8950SCGd5Zqi9DTIapD1sIm7YH2Z59aoxPBD
NEPZFvX4lOMwsgWriOmBq5J7gDeQ4Lpb8WVZuVyxfvOcl14eRvHdTdZWeXqeBGT70qv3+tLg
s/zCdqTP22jVFC+W4o8yO48K22zK1xkfP+7riCk3X5I9ya4vnDtkYDQkri5Oj4mUkutJ0tCW
WRvuMS/fKqglgShKgNtR6HqEjwoKx9loTsNup9VTaQl0IR4dN+Rqaab1t3RFKR1cKJxOL8En
I9nuOVLNtzreB8EKKBJQC6unyITLzBselcqhVK14yCG8RtVT3opVzq4ugXi0Ia+M7Hz4aTud
2k3zGWins/uuXDwvhqVq3Gc+eUHdw1GqCKXpWw1SJRLLKySg1AzfrwgpGjnHIMPxehrV00C8
xos3K5/uLIHaQ7txcdNzcF6JzZLbpL6DMWAeXQ077sG4iJG3YzRTx6KOTuNtplv8aK1tO13l
R5s3dM6eUr4TFb5kU/OEAvVICJiTjZptXEraIZlIKcX3SyA6RY3kbXW28urxI9+NnrRkmh6e
HrwVZ0lAXwJsMK6UPYFMGvhPSfMcGa0PHGZsc+0FkQeKXo6L4WhpboaDTkF3NDXCSUekU9Fo
VpzUO6/FDdR0ZHNK0DMWci7DIwQekmDDoWB5hyckFQ+gKU+k+KYyiQBI8ucloUhSlt8b39l8
ynvycuXLtyxXuOWIFN/LV7R9vvXSS923/N74zueTslVzJt+TTJNhNYwZf6T4ZvKID4y2fntz
9ZWNPpwvjBdX7ZOyknGXXn0eGbTKKIUVIO2XlulmaEkawZ6CNo0YXfzFc3ExGrX11e5yULuh
col9GqzbbTZ9q8jNS2lKwYrin84Ci6aw/HPoDDHG0uns5ed6LZ3oGbrDnZ1vyXNoT8VQmMHp
7OVn/qTj9iXDnZ1vyXP8nsbaSy0rlTiVERKT7UDKncsj30PL5c+Qk+Z/zUG09WAy8ch5xcO5
WnnVFHUsWJ/T0z5zznxR6c6dOyesiCy8lhmWI6fpNT1PFWbNI536Tbjj1ELmKLUgjdI4vo3u
EG868mekjL4ZiX16C2quS5fRXPEp0m4dDVtqJJdkiJK5OYzsEag8gcqnzVXvHQSizfh6OJKu
GlfGqZ8yXTEcbOjVqVwtPG9YJEh4DhilqePZr9DUEPbNpsNCgcqjLgczKGG18TJNGy/hZeHU
6TJNHSfhJD11WOuX+PxkGjIs4bR01elGaep4PZqSdld76pVdWz4JY9QOgpVZ4PNpTPyjqi5k
6a7y1JfxvB+1jNPmLUP6AwtEWmvVp6hf/Q20VpQjge6p6VX8OhKHjkTVV0fotzPOJw6OT7i1
0QGMdOURFasdNl6/+zHdnGdmHa+6sLq8snKRP5K8fAm6sO7IS5cuYf/+/Thy5Ag++8xrOdV5
ua7W4MqaDbj2i61oq62Dq+oqrv7sNVzb/B9oq4/0bu1IFZkXn3mWPy67LL+6LFIWenGB0gLB
SzyjZzBcTpc/hWdvmYxocrweXb04hYY5moHy803zNWS+aUYhfRxZdn7G8r1pZaMNa7k2k84w
/JN1TUtDL6xHVy9OD7c7x0lZeuVpvs5KXDY44rpXRtX5sfGQ8WlzFYMhZZqYOxRZRetFevrc
YtivHwXX2eOE4cWRuCJOIsb8SdaJ6xkZDr7pwb6Hrlf97NOz6J3bF/PmzfNTBFwZtRWKm55a
nHowIhOGYym6nfSr6fH933zFK+8RGTVqFB555BGf/BjHlpGGlOsHo3rbm2gnxtsczaj7zdvo
/dUvI0FnAl/mF6+nXvllGWWZmRfpl2la/rTp2jDDq3E5XYblU9JUp8k47VMPRtKReTOO9Ms0
4oJfr8f5pys4El6mexCi4vHWq9DIeWsv8yV5lDRkWM2z9Ms0CSuf2nRtmOEkrjZNxhvRkvHq
J9PQ4nFY0pawMqyGVfv10tW0Zbqk112f6jLLMko5BZKBHh4da0uV3/3xQVrSj4673TBu2gNf
F++MYfjHccJwPPNLJN08Hs4zH6PmuUeVngsxJnnx0KTTbuPh7HRgIU9fJNBxIjY6Xdf+Dw8/
TPs0WsT9scYMMHMqLaEDKAvESbJQOmB+Uc00M8+bTqqo92Dk7DQklbNkAZzXanB19c/R2taK
rBnT0HvuLCT2yjJC84t31FThSl0T0rJ6Izc70y89kghv+X0Vqh9N6uM1UWSqXTWHRHFOqjB2
TRzdxktxXgpauWrDXkjFxzyZgZF4wWAlnLoqUBZd2nnfW/B6q4aVhdaLCyTHQGmSppmnOl9J
k5/q+EB0zMIFotGd0tTykPI0Uz4/PG4P8qcmoG0n2rAKNnnkBMVgrCCD0cjaQnGkWRSPxJVP
CRCjJx8j4qI7l7inkcCnh7y1fTt+/GIpXv7pT0SFUwvBy4PXYHh9SioLWP4kvD4Nmer75B4G
w/OYWUNDA11gbjBQR2eftBPD7bSdna05H6JFGfsSMwq5KrF52QxMf3gW5s+fj1kPP4SCgmXY
X6nci15/fDOF5+BoiBsm64++hAceeAUNbhko2XuHpfTYOb71a/i7v12Pqx7eq/DSl6di6tc2
wX0TL6FVoWzqVPzjG5+g7s8bcP/9D+FwXTvqPnnNh0+Wm/dXh21zCjBj41G9bP3i5DtTN5BQ
3psk6CmGjOjUT28rC6f8EidYEb3vxL8uaNNClrm7rkX+3ky2nWCF7cLpQvYRyFNbHwQ9Vl9m
fwayc535BDXLH0V7XaNydaybHl8jq/6JfAxoRDPaSXsz6M4+OmrKjuQUOiL97nsmY9CQoXjw
b6f5KX+9jL3NTklVV3opRHWF1qOhjktLSxP5Mp0BAwYKvzqd/a3Uw6h++Rdo+egocr71DeQs
movGfQdRs+UNtNUF0/Q12LxkPjYdGoniNVuwk4bC3tyyBvPGHULJ/KdwXLEb2ixNhVPTFIMn
gYOVn9NvGPd3BP47lEsLUXUcv6ujqPO/x19Ucbso6m8n3IC0Yffie0XLMCJLaeTG8k6TbJh6
GtMxgU6VQA/fCFPKxSg9vvFKDdbj36jehsq/pKPGk/nppYVUflXXTtKXNM3QkXxI2EC4gdIk
fmd7Splo+ZLxfmWKUJ6cj5o2z2eoFbv0s4KXfn4qCl/54GYa8r04yWBcWz6L9FqDD7wHR2WQ
xNwJI8fYuWhkp5VHQ2hEytVCp9z26ZODrzw6G8OGDRNZS+ZD4kMleDWeGVp9+vRBZiaf1W7H
PWTA5EtV47Y1NMJRfhq9aEiqz8KvInfRfGT+7f1o/PgvaKPhrUCu/ugb2HQSWLrlBUwZNUAM
C2UOGIU5z67BtHzgZKXa6FRhc+EclO2t9JCsL9+BOTNWCOPiqjqKMkovKHgABXNWYOsfygEa
HVPUkAMHt63CjIICSi9A4Uu7cc0tF3VZUoffinzU4cPyKyKPi3/ej7qscRiD83jvL1Ui7sqJ
D+g5DrcPSYWr+hR+u+cwrjYpuXgYI0/lwW1YNEPJb9GK72PnecAz6FZfjo3LmFdOX4TN+71l
Kt/9EuZQ/P33348Zi1bhoLvHJWmr+ZVxPs8AH6mBcQMg+mQQaoDpamlrw/40jXiV8fKpxtSL
k+nqNL16LOFkmgyH+lTno8Y1ilfDsF/CqfmQcVrY7hpWl1ftV5fXKJ6UlNBTuulu4yCMgkrB
y7Ba+RMZH8cGo+GV5WivpcU9Klw1joz3xPlQiE3AnpiMtNQMpNG1r1x2209W/wSvbHwFr2zY
4KlMLAz5YzakXwpJq744rIaRflmEQOFevXrhuuuuE6D9+vUTT5mPxLdl90LOP34dfRZ8FTy/
Ye/fFzlPfA05X/0KbGRwArnTH/yeFPtsjB+ggUodhaKfrcb0EWr8XNxyUz12/WSvZ6jor795
DeeHfR7DU6vw84VF2HXmRpSsWYeVM1OwaeshoD+fM9+OE9tL8PTP38eMp/8N//bsQlT8+odY
utk7VCRl0J4yBFNuaMfv3j8jGProv3+HW77+dSyYnYVde4+LuPL33kX7LfdicGI7nI1ncfTo
e7hKo3LSMS3n6d9g3tM/R8Nd/4SX1/8Ekxz7cI7i05L43V3D5icWY2vlHfj+T36Cpx/tg00l
87GzwgFX5U4sLt2OO5aWYsO6lbjr4u/w9Lxfok7zzjkvybM6X/FuCFadLuFEmgSmpzpeSdPW
HBVwRF6FrloJUu4aitxC5c+bpOUxeBkUXInnpeQbr5cu49RPxtKG1XEKVf+/ahzpl1DBwmr6
WlhtmqTZVZ7a8siw9qktjzadw4bO3VY43Q+Ph5C4t+H+tbW20Qmxyk8bp8Zlg1G/YTmylm4U
8BJWPiUN+eR4YUAMmYxeQkpqGvr2vw6ZvfsiI7M3bPk33oycnFwMu36YXy7+TUwB4fhoOZ7T
GD9+PN1Bm4QDBw6ISXktbVtGOjLvvRv2frmepKRBA5D+hTtpj4b2ZF4PiPDYSacDyaANlCpn
XIJb/34BULcJRy4yeCV+s6sOM+dOhr3yMLbTMFLhmqcxaVQ+xs94CqUzBwGXGK4Gf3jtQ+TT
eTAzvjAcw+/8Bzz3eD5ObtpHsxNal4nP30d9jd99DAcuYi/Znb+5bQRuvOsBYM8holSDw5Tn
uC+NpmlwdqIASNKQObFvG8VMw4tPTceIPOo5vfAqCiimsQXUK3sbm6jX8fjTc/G5oUPxhVmL
MJN6RNveOQG4jU9tdSPJ83MofPVVlK35IiLZ6aJhrcOCSjs3qrWSrQDKQIJYT0sCbgnwh4jR
T1dIUpmregqyd6B+JqRneNDZYNSVFSJ72Suwpffy6WWocfz98anLCbR6qp3Kw3eF20lP21NS
kkko7XA5Sdu4nVCpqr6TPDokViyOHj0aY8eOxeHDh5Gfn4/bb79d3Fsu+YnsSV2quitoICLe
PgWVhCbHNz6zFgMWFONeVQb2IZMxO2s1Xn+vEpPH/RH7aJhow63ZcBz/lKDGYORARZUzyugH
HwS2k9zqz+IDmqg+uWkpHtrkK6UzNPqV681Y5DTk8/cB6w/gT0czcYjoLxpCq6l6T6CRrudx
8Og4HCCoOZ8bKGAN//DrmjYR3g5UbwwmG/YxRbualHe5/slZoFXfHpdPPnveVJQtOYHla0sw
XyQOwuziZzF2lAesi3p85d5FC2Gx3ckkELDHoccrG4sgV1ckZGWg9wv80Qc4K2jS+7kFyF6+
UTEYHBkEn0GE47zi4Ox0ax9nRWsxxVNowES67lUu99QaDC1P8hudn+pmqg1r8QKFeTJ8ypQp
4F3p77zzjlhBxXHXrl3DoEGDMHjwYKTSrm/f4YdAFL1pw79ACnrTeuw8SkNAY7M9Ca6KQ9h6
6BCWLCIROD3R5MnG9CcmY+vmX+HXFUeQNe2fkUcgjqwcSjuGCzRZPcLd4blw9DANfY0la3Q9
7qIv+eueeBXPPjgADvqad1WdwKFPXBitMRicU2re58lUrEfx8mPImlwMshlE4ybMzK9D6fIS
CkzD5wZ4jRMna53oMLx7DPVF493GsBUt7umZVJon4smWkm2/wqQMujyFSF3484e4lHM9XDUX
kDbucezYU4T6qgq89+ZqlK5cgdvHbcYdOrxq8+2cYbO1T11jO2dJLK66tgSU4aTAZcj69o+Q
lDdaGIxrJV9D75JfiDBjNX98QHzVB6agpIohKjOAEcKkJKeKkSAXTYa30lAbXQ/OlzBRt0Nu
CJBWQZ0R9zqU/0qsG4Yf8scJ7mgFJsS/Q2kYZSotM2XDsHv3buzcudPz43B1dXWIFBXw1BFT
MY8+sbcWfRM7jlSg3uFAVflefGfxWgKYhnvyvAMz0nYMuGcmxpzfhfW7zmPBjNGCUGreOEwm
X8nzm1FRQzSO78Qza48pcxpkaMbck4V9pT/C/grq0zguYNcLT2LlK58oTGj/2ofg7nEUScNd
4++Rw1CZuPO+MSIuy6cHoSBL3jjE/uETqZdTtxX/uuMo6l31OEKT8FuJHvWrYB9yG/Fah5Kf
/gYXybo0VH6IZUtL8Npf6+A4+59YPP8hbD5YAXv2QNx0wzDCUC8GoGCXdMFqn2UwuuRr7WpM
cy+BP8sNfpnffQFpd00VBqP6n78Ce76iX9oaatHwzjbUPPO4Ia4fTbM9kghlyMNTdhrn5xbU
RmPA9sQkO1rJY6N9D4GbHafKhkd+GtLyBN1MydRweGTDdeuttwrjxXMb5eXlaKQzp06cOIFT
p05h5MiRNPfCX/uhumzM+fEGYMUzWLt0IdhUsMsaMxNrnvkGuNOgqMx0kCgUlzoWs6dlofjd
6ZicJ+dMhuDb65bi3OJSLHx4k4DLH0PdiyoFZfyTtIz30pMoWfiwEkErolau+weDuYJUjLmb
TNChcky61TvANPzzf0PDVsfwwMQRCg3PXxVvZBaYz8xRtMpryWcoWluEfbJQBJ+WyYUgXjcU
49zClXjMnTioYAmeeXAI9UrmonjmX7GyeCGUUpDpLCzDrV22l8FCiqTmMb7lLAlERwI8rxao
B5Bx/yy0nP4E1UVfRjsdgdT8h9/T8tprInPnkY9CYoLziodr5+kLOm6qlY5F5310Cd9/4YV2
p6MFTXRW+g9/+ALxwMbByLFEKE3Md7j9btBo8c9jiGfPnsWxY8dQUVGBCxcuEG9NWLJkCYYP
H27EmKl4l4OmmRvo5il7BrKzvT0Mf+QabJzxMI4u2IDV0/M0yS7awU4XkaRm0vJdTRIFXY56
MTzFy4jj4lwO6j25kMrLlv0yVHglZpGpZTYgnh8hK8KSgCUBExL4091DMSDZvyVK1MSb89FG
RyeJZbXuyIF7TwvfhSmh6beLtEv7c3/kuVZzjs/5y87OFqM5PKLz/vvv+yHKKQDWwxMmTBDp
Y++4jz5UU0gP0+ZrvrmPDh6ghDYk0o7swAaDkn0sA8EzChFXR8tMKUUsR+MnO3U8h40mmBiO
94z07dsXly9fFr0MNhq8nyNSZ0/NRm4gW0EZ8L6MuU+8RIM7Y7HmgeHCPioWnUvJKymSkJXl
XcukLQcbkyxhVH3LqC0/l0WLy3HSmYZng2Bon+xiD4weLSSlgYsheVDDyDjmRR3PYXUahzuT
8+eVuVNqp3+autYqpZAw6jLKOHU51enqePZr4QPBanG1YS0tdbqkq4aRcQxnFK+mYfljIAGu
Vv5Vy5NR619Oevxpjz5Gw1NjPeGsp1fBdfIoml7f4okL6AmQT0C8EBPb22hjn5OX8tNpt7yC
qo13J5Jr4+MLw3GsIBWt6ofNFVddkf0AAkRk0NHA/Bs4cCAdyesCT4zHw6XljMKCJUuRP/Ee
jHIbGFlEty3wYcNbRjYoPkmegLoBeyINPcZ0DFGsBB8lKcXhfW/+L8b73nwVrMSN1lOdT7Ro
WnQ6rwRIr4qd3GY4zF78fR+wjAdmAfRr3PJLn3ijAOcVD9fOQ1I0fWCz8T0hdGCh1PdtZjgQ
bc+/AUaLcT3lyqum2OmlcbzaKOnBqNMZPpiz547C9BmjBF3GDURTnWZkMNT5CV6kJlMn+PjZ
iCsylrzLfPgp43xQQghI/EA0ZT4SRpKXdUWG+amFkWnafGS8fMp0DuvRUKdLHDNPiReIpjpN
7dfSl2mSpjZdG9bCyzA/zdLQ0pRhiR+IZij5SDqSvnxq85Hx8inTOaxHQ50ucXrUk5uvyR7A
+Ul5BqLh9m+CiAkQgwxCim6j8/7s9iQyGkk0p0G9DZ7Y4GVU+pM3GgnEiUl1ifQqpl56MDg1
Tiz83FiCNRjmkauDeLLx6GouBJaDvQ+ZLp8dJQr53gK9O/m+5NMsr4FomqURDlwkMg2GK9Pl
Mxz+ujNOUv/BaHaRojRYPeWNp8YUFIYkZQDDeXBe8XCiQ0Hs8iGxfNKtjbsefAETb0/3d6wl
9DWFukHoVSD5VcppMl2N45+XN4bh1LASX0Ko02ScfGpxZbzZpxpfm68xDX0ZGcOrUxT5qOWk
To22X5tPIFlq8w5WSrXstLgcDpRXMFw9euo4Nb7596amYOwXn046H0xSltHOT48TmZdMCyRL
CWP2qZadHk6g9EBperS6e9yQ76xAA+nUZhr25+Wp4f94ykAfn2lzHpxXPFw79S5aWhpoAdBV
NNRW0fAU2wo+G4WYCOyo1ai+joM3FG5lwdRM4BwDpXJl9fIQ3Xy8dBUOOK/ALnC6Ft9L33/+
wpsWOMdopGr5UtOMFR8sSm816uj35lNidUD4/eXj5VcrH23Yj1gUI/z58hKPJx/eXC2flED2
vV8ESjeg8sXlaDn/mYzWeXJdMtIbsp7ppycPGkwG4zmIvHQoRzuqrdVJS25baDKclty66JYf
7mnwr80p9hjr5icrqbex64J1YCQLVwo6MjbUjU6WOzKKrCQV3vzpcY9KSZfKlGEkPD/9cSLj
Jhg9df6ckzYcWe6E7fOaovfe1ISDlVG/DP68yPegR08vTsJL+jKsBythzD6D0eB0mR/T1IbN
5mPBRS4BVuaRKXTZSLhOdrxzOptpjwaNSFGPgzmyPTi1QPQyAt0Rrq6MXASukPIni6SFkfHy
yfBaxzjyp07TxunhquHVfi2uOs3rly/FG6Pnk7T4qXYyXh1nxm+Ep5TPOySnLq86bxmvpRMs
bIa3UGC0+Ulco3iZLp7+1UBEm8L1IeQbUL8iSYufaifj1XFevy+sN14x6lpa6nTpN3o/Ml2b
f7CwxIvWU5ufmq6Z8qnhpT8QTQljPbu2BJy0epUGymhbhnLclJ1feiutw21RHVioV0SjSsUN
JZw0vTwiiQvEhz9dA83lD+iJ4TLq5SEVhQdQxxMung6pDo3SsfuG/JiRCyPrycaQaJgJenn4
8adjM0zhBeHJL58g8B2RrG6/ZvnVk01H8G7lGQcJ0EhUMh2Pbqf7NGykB+0/Xv1jjLhhBI1V
XYODzmViJyuRrEAizL2LGPOnzTeU7LS42nAotCxY8xKQcmYMWV/MYxvUtTBphZJvT4e13ltn
rgHyCyZ6GjfQSFIwSSSn0tUUvfqIi5haaKjKPiL/RmT1ysKVy1fESbLBCHB6OMrBDF1ZkcOh
L3G1+YRDS0vDChtLQC33cGStxlfnEg4tNb7lDywBtdzDkbUaX51TOLTU+JafJcBGI3oGQ8q0
vj68g0mTU5Lo6oxm1PAtqcSaPYGORU+kE25T04KcryFzdj+9lUaZzNUkhxWMpMJJXOZL+sNi
oksixaaSmRFFpLKW+D3zvZmRcGxgpNzDpS7xrfcWrgT18GQPQy+t4+JoQIqW/9IEOO3RsCel
wE6bw5VdfvZE01x5DQaj0GQ2WcXo20XT7PgAysrsExnTQMcpbG+xOov0vRyF6ov/ewuVQwte
TwLWe9OTSrhx3I47n+FISqSd4MRWMl3GlMg397VSt8PRZKd5DPNGI1yRdA889Uvll9z1FXb3
eC9WKSwJdBMJiO9Q8afTFCiRjBmfdEv7wekfO5odp1Gd4M5APxpEB6fXpSHCLbUZQXdpwVjM
WxKwJBCWBNy6IVzVElaewZFcZB/owiUa9qf9fHw0Ot//yhbDZqanoafvOlkBg4sgEggpgEgK
HQluJLx3BlyWX08uf2d4BxYPnVcC3Dakjuk8XPJ5U3yzK89rsOGwJaekiIljuvc1LC6jMZsR
eFy08wkxLEF1SyR+N2bfj1m4bikoq1CWBExKoPN9VKXSHeGp7j0afL+rnWfEuTnbQ5gIN1l6
U2B8m9T//d//ibszBgwYgMGDfU9u5GEz2j7IJs4UvdgBhaP0JE64vDN+uLixk4RF2ZKAJYGe
I4FE6lDwfRr8Y3Wk9DlINyWGYTQC9xDMCfXcuXN4++23kUI9ntGjR+ORRx7xQWRboRgOn+gO
CLDyDlWJSxwtu+aMiSi353IsptWZnLkyKByHAtuZymjxYkmgIyTQudp6S0sLGQy6wpZu7RNG
I4Ev1+CJDo9yiq+QmmnDCG86uXr1KhkHqVzUPBgpXjVMvPzBXibzr4XRhplXGacur4zzlsW3
c6VH2wsbX5+a7/jmbOVmSaDrS6AzteXg0nS2NJO9SERyShrdqUFLbvmWDxcdeduuq7CNCUaj
l8HUuYfBtNhgNDTQxeVkwGzcDVI5RXmGKej6o1j0UBG8N/NKwlkofXMHkl4rQFFzKfYU3SET
VE9vnsomJk5SK3e18uR4dZqKjPBKWDWM2q+F53CwdD2ceMd5ZRTvnK38LAl0XQl0rXbD9y21
07HotmQ73RFOnpZmB2xJZD86wKWnpwuDwYaD5zSMnDJUY5QaIN5drMmFZfjmuD5ockrYJPTN
BBomF6MYvvMoEoKf0lj4q29pBNTQgfxMgXHUeP5UA1HoHGldnf/OIUWLi54sgS7W7mlYKolW
T7GN4E1+dpeLehmksJ0B7tPQvt5o9TKYbp8+fZCZmYna2lpMnjzZcIhK6W1oOTEXbiSwG0aO
Qu4Af8N44cxBHHQOxZSxA1C+YxV+WjEYw85swq5jhDRoMkp//C+4I4fwmj7F5h8+j037lD5L
/uRv4Jl/mYUhznKs+qc3MGnR7di1tBSVs8uwecFYA8ZkZWHFK/0GoJ062izvloHp1K/RYs6S
gAkJ8Mm21M9QRoQI3tZQ3yAWJnGPgx0bBPVPRMbwT69evcSKKf6i79+/v4HRiIyBdELfv/tt
HDy4H/v3828v9h+tBF87VXeRjMb5WpGBs/40ju3ahDNji7FmzUoU1O/D85s+pLR2HHl5PhmM
HBSXrcO60iI07V+Pl96uIH6bcPrkHpSQwWgqmI2vT7xO0Ar8x6zSDUylY1JD4Z1h5c8st2xo
1MbGLJ4FZ0nAkkBMJCCbIzdluhrcfu1qNZJog19TS5MwFtpM2YBIHG1aNMI8pzF+/HicPHkS
Bw4cwMCBA5GcTBsOo+jSiNax7atRvF1FNP9xvPmzWRRBY1RIUhJaqE8ybileXDCFJnto2/yj
I7Dn9WOoKfo8ciYuRfHU8ZgyqjfqrzpwC2Ecu1AnDC4j589ejdWihxGKUlWy7X5/ucaEKgdZ
y0LFi5/0+MOmO7hojhR0B3lYZQgsgQTQoba8+Zvmm9t5o9/UwZ/CSVf5Xb7moK9mPWT/SP8Y
PbzgcbLy8lLbsWPH4vDhw8jPz8ftt99Os/ThbTbUy7WJImeXvYkFY9lAGDvueWSNGMSrA8TH
rpONCOiQLooZODgbrz//CFbKGXUSQr7btjHUvROHM5bKSSl1XiWoYjYG3p5e/hiI1CJpSaAD
JSA0GXUi7M2f/Qm0DBfNdTQ8pavfVJH6ViXiYqSlpWHKlCngPRvvvPOOWEHFcdeuXcOgQYPE
8FVqamrYQ1es1BVLYIJVOjJeWAxVsYFLWD3/X/DxzGJs+/Fk5Ka6sG3udOzyTKoTCnXbfJ0P
Ad+kLhWSyp+ZDqVMocCGSrtLCdBi1pJA15YAHR3CpxQK9U/qQHxUc/OmZbjBHc9Gx8hwDB06
FFOnTsWePXuwe/du0dOQRmP48OFikjwnJyc4jzoQPKdR/uePUZGWC7ruVjin046hN+YpAZ+/
aiXpTnBcxWnyDhnUFylw4Pje17DhPM2TN7M5YuokFxZit3RcMJZJKAUMBbZbCs0qlAkJdK5L
FUww3FNBaAuETRgI9+khvMnPlMGQAouR4eC9Gbfeeqs4GIvnNsrLy9HY2IgTJ07g1KlTGDly
JMI1GjyncWh9Mf1kIfg5iPZpbAanSScsqFCOitJLSqZUHtFKHYXCJQV4cm0RHnqJwlnj8MC4
LOzZvgr/++gPyGwkIJluJjHvQlXC5inHBtIyArGRaw+nSs1AGA7WKZbrtBKwJZJuc78jntdL
eP3xge0tzgRcqXWh6I2L5hgXH+Pijzl4Ayg5p6FO5rizZ8/i2LFjqKiowIULF9DU1IQlS5aA
exwd40TtBpwO1NM16pmZdMthggsN9S7hF1VeCJVlotcAjOI7pjTRy7W7lktfQtZEuL5cwosl
5eOuPtE49DQ8HnoWFp/zl52dLYb5uS6///77fgKQdZz18IQJE0T6rbdNRlJisrLpmvDsJ67Q
5j4ajq9toHErs471Ir/wGDhmetiwYejbty8uX74sehlsNHg/R8c4d0G5zPZUMhJuLtrtdMii
XRpgigwmEJmuZ1Q6pmRWrpYEOk4CMVQinkKF0ubUsOy32qkUIxsQvkfDlpAihqnsNw9KpInw
BFyu0U7kSpSOeWZkZIiTb3kJrosmInhivHO7UCpZd6mUoZS5c789i7v4S4A753xVdPSduxfj
ISwNgicigEfCujkTIwgBwHtAEp83lUDzGHyXBovDTuKlN9dO8xqxeHmRS5RXTXW8Y9nIyuT2
usXFXWxvvVLBBGoMDCYOiOycMu94eVsc9AwJxGZgittkNJxopqLd9+x2yuYzkec1eDCK9Bbv
EBcn3kZDyN2HBlcX+ZMVRj59S6lvMHxhtF1dptx9nJRT9ylRKCXRrxWhULBgw5NAfFpRtAxQ
eGXsHFj2RNrq7DYUPFRFN2uQtQ9hOqNzFCOWXGgrozqsryL8K5YeHMcp8Sx46Y9lSeJDuzuV
JXSJqWtH6NgWRleQgJwc7gq8xoLHFBrtYZ3lbG1BM51VSDO59E1NNb9nCYabuqLAzQtZpR5C
RO0pslWMoXmJWpCWBLqKBDpbG45nW+M5ZT4ava2tVYxQ2f/3Mxf6pCbgYiebCI99ZQpmOKRl
YDiVwfBhTIHxDlH5JPbwgJSZlGMPF4dV/ChLoGfXKzZi8TIcTU2NsNNkuI2vfSWx212t7Th5
pQ2nLrWKb2+1KpXNnt+29hWp06JcGzoZOVlyWWIZNmJTLUEjmO4eL2XV3ctplc+SQAdKgIeI
4vDF2konoCclpdCxru77NO4ankQHFgK3DGzzfE/rNXn/OLfy1OpQAegPHb5omZY2k/CpeTGN
aHK8Hv9G8F6KHjzxMjneDI4a3/JbEoi+BPiLtLMNr0S/lMYUtS1aGzbCNAsXK3wjujI+VppR
0lc/2TYl0AqqJDo+hE8AVxytqOL7uv2cTOcElmKoTuCriXgJmOteMW44GXvzia9PW9ZO3mCD
iJYXRSrLst1SZHh3EUVFUhVXeZ/yfcmEIBnE9+VElFt3Ubzm2l1EoupQZDF006EcxDFzkz2N
Vr8DVc3zaEuigwnpmKckurIiOSlVObCQ0XktbkpqiqKfZXvXoxuuDuCvb43rfpXXv4ws0O6i
bDyvz10HhP1QFdnXaEhoBgi30kganePZXd5j92t3mvqho2s0EN0naNJocIHr6+vDKnd27xyk
pWfC0dRCK6h49RS3aRIyf0+Ktq1SAro5hKsDtJ+lusTjFWmmEGZgtPwKNaqNjElYbIuKkS6W
ypGVi/T7FCKgaLRMSZlo430oWgFLApYEOqkEGhvq4Wx20skcbUjk4Slu/zwlnsDT4iIQQ847
jeEIpsCkIOQzGLxaZhJW4qrTjP3KB4O+khYU3Qo8Hl+J6jzUfubeY0S4vohd7cZlUiqUlEcg
OCvNkkD3kUDtod24uOk5OK98FpNCJfUdjAHzlqPXuAdjQl9L1EHTFk6nUwxNtdNxInZu0mLM
WgvZycLtxHRbYxMSs3t5OGt3ONBGa4gTPacIepIi8KiVvSKd4MpPjRNm1kTC6D0I6u4ut0dp
h5lN9NCMyszx0lBon9HLvbNQkjWks/Bj8dGxEmCDcaXsCWTS53hKmnLZQrQ5aq69IPJA0cvo
decD0SbvT4829LXRktv2JK7ttCNcOUeE/GbGAaUO8CdrPkb5pDYP74Z0/PUkrr6yBS2nz4gY
Nha1b72N+v/8b7Ty1YMhOa3C47D8SUKysPIp461nYAn0LHlpa1Jg2Vip3V0CF3/xHNISyWCw
PuWTNmLwY9qcB+cVD8ct2kY9DN7g19rqouEpWjUl9KXZtm4WLsqlaW1oRMOed9F8sgI5Cx6D
s/IcrqzdiKwvTkFWWIYoUHPXFlIbVheO6ch0NU0Zp4btbn4uo7rM3a18VnksCYQmgZbLnyE5
LTHmG++SqdlxXvFw3iFqPnKqjYwGz2q00Fg6G49gjvVDDHWhlzmFEfVQTNrN+ej92COoIkNx
eWUZ2qprkDzyRvR66EuwJSUF41yTLguhp/BkmgZFN6jFl0o0FBq6hDttpKeEYRnqTlssizFL
AtGRgOxZmKSWNm8Z0h9YIKBbqz5FXdnjaK0oRwJdDdGr+HXYrx+Fqq+O0KcWpzMDuc1LjcY6
Wgy6qZWzPneqWKknJRVVknmvVD0KBi8Fq6ysxLlz58QtfcxPEhmCfv36IS8vT9w2lUg3TmX9
/VTU/vdeNPzqLbRlZeL6pd9E6i0jzWfrBykLIQvlB6ATIWElrhqE0/Ti1TBd3M/Ggt6P5SwJ
dFYJdHgrNKkC1AaDZZmYOxRZRetx7VtTkD63WBgM19njuiolni0wwUZmQmRIf6jt28F3L5Ei
CJkJRjApHBaIkaupqcHevXtx+vRpVFVViQuX+L5wtmhZWVniFr9JkyZhSJ8c1P/PPjhpTiP9
vsloralF/X+9g+Qb8pAyYniEiowLEkwC2nQjARjFG0mga8V7PjDYcLABsZwlAUsCHgm007FM
Zk8NT39Q6WF4kMkjDMczv6RRlAlwnf0ENc89akiP84qHS7InIpGHooSdYKMRSRdH6tEwea+r
q8O+ffvwxz/+UVzvevvttyu9CjoYi43JqVOncPjwYTTSRPeD/Qehfd2rsF83EH0LF8FVcRaX
V/0Etpze6Pe9b8GWQhsTDZzLQZM3qYFWMgQqSChGQBqfQPQkjAGzXSXaMhhd5U11Qj5DaVOd
kP1ALHHzDlMfSrIeg7GCDAbN5Rq6CPMxpKtJcDpb0GpLEqM/9D1PS27ZekRjuCHEesDb2j/6
6CO89957uOmmm8Ql5kOHDhXXunJPo7GxEaNHjxYwBz/8ENnnLuILd9yKvjOnI+3O29B26y1o
vXqNSiBOd9cUUxV0HMXXphfh3rI3sWCsvOBble7pYQR7A5werJDSWKjpS389Ni96CJtOSjru
+KxxKFnzLO4eEt0bCuuPvoSHilLw5p4F0Cu15Cr8ZzBZhE/ZwuzOEgjURqJf7rjX0hDnNPT4
c52hHsazj4KUYGCBRPLBH5iyT6qrzUVnTlH/gmwFjQHRRHi0DIZPNsEDLdR7ePfdd8Vw1H33
3Yf8/HwfpGyaw+Bfnz59cObMGRy7dg0THnsMabeMFnC29DT0njsL7bQELJHORAnk0kWi9g50
+brMGAtJPRishDN4ch0oWIpXH78NaHLCUVeBN54uQcmyX2HH5jnIMkALJzo1zbjnFQ49xvEx
d1J84RKz8HqQBLiysOMaFGEbEnTM/9Hmpldt1XHSL5+cE/vZSVqB0trbaHgqgmEjYTCWk16r
b/Tkp+Tu/5fziofjFVOtID3bziaDNvfJTKVgZDisp1qaQQiw0bhw4QKGDBkifkbgubm5uGH4
cOyjIayWtFQaTWsjtpWlXrbMDCM0n3gfe11zFC89W4rtx84Dg8ahYMhVNN9ViGdnjEL5jh/i
pxWDMezMJuw6Ri9k0GSUri7GHbkkJkclNv/weWzad1LQzp/8OJ4pnoUhlFS++yWsKN0Ooois
/AI89Uwhxg9Jo5C/QAYNvgFDcge4+RuCRx/Nx571LWKUsJ1ezLEda1C6dpegxfwtfbYYD45Q
+goXD27D8lXrcbIOyC+YieGn/4Sbv/uvmEHprqqjWPN8KfHN5ZqMefc6iJkR7nwcOLhtNVat
3wNCJbKz8fRTCzAqm4pVvgP/tPE8po74FGu3HuJUzC55AQsmDSG/C0dV/LQTP9+T/DgvYMea
F/DSbz8WeYyZVoh/KZyGXBGy/lgSYAlERauELUrZ+tRcSDWrjtNyKtPkUzKgDrNf0lLjJ9DX
P/8COcbT0mJ4J/UwGl5ZjrZaRWNJGC28h3aQfDxwEXrYaLAhbGWG6CgRm5gCD3ocRAi5ypKa
ROFhKh6K0i63legO2vXd2NQkhOwSm/jUr0pCmX1W4aX5Rdh+ZgQNCa1DCe3C33PoJMqvci8k
Ac760/j4t5tw9tZirFnzAxTU78Pzrx0WxI+8PJ8MRg6Ky9ZhXWkhGvetx9q3K+Cq3InFZDDu
WFqKDetWYvylPSievwX1okr583r+8LvYf/Ag9u/fj907XkLR+pOYXHg/SH+j+fhWFJHBuKOQ
aZVhdu4hlH53G9Gid1W5G48Vr0fjPYVYt64Unzu9HXtO0obHJua9Cj9fWIRd7nKtnJmCTWwA
+is9sPJtT6GYDMb4JSUoK12K3ENb8eT8lwiL6DrrcfLQdqz9YChWrlkD0vvYWvIiysnmODT8
/D8VP8e3LgeximKS45qSeTi2azWe3lFOFC1nSYAloFUE/m3BX06Mo8XzhzITI6nIp8xdnYOM
06OnTdOGGUfS9sEnRS56G9zjMPjROI9IU+OzwajbQEeDfO8V2hBIualw1X41zYjmo32YDhWp
viEAAEAASURBVByQ05ftNEzVyte9tiORSk+KJxrDVDJvloaelGU6PXlYzE7zEdXV1WIyvKCg
AOnpykCSBGsjC8cT4eXltG7ZDW9jfsN0rsoD2E6f2kv/vQST+hORUc9iyf7peE0y20LGa9xS
vLhgiuiCJT06AnteP4aaos8jZ+JSFE8djyn0eV5f1YRbCP3ji0SM7iJhV1tNt1v1uxOFr76K
aecAvRmKZC7esa0oKRYonj/V1RfRhDwk5dyGwuI7MXXKKNLYVbhh2CCyB4riP7H31wQ/DauL
pouv+RGlK/G7hxVCrsrDolyFrxZjEnd9Rj2F0vMfY+nvOIsa/IHKMGh2GZ6aMVbk+eKGFkxd
uBq/PT4XM0RMFlb+6z9iPHdohhZh464y1FK57AH4AcmKBl1xrRYYN+HL2LLuNtRmDhTUrD+W
BHwlEEQZ+ALHJKRW0DIDvTijtECwEkc8hcL3idENJKhGSYTBKCtE7x+8AVs6HZNktgfBecXF
UT5kOfhfoo309r+1/BxfSfg+qWJl2CWqPEhJ65SN92H0799f7M84cOAAxo8fr2s0/vD/2fsW
wKiqM/9fkklISEJ4v5Fg0IKCVQpCEVqRiFTYXUUtsvwjVKRgKV1oLS2m1ahNpdRu6NIoLeKK
1Ea6LbEttJTiUo0vRKhrUKwmEiUSHkYIeU2SSfL/vnPnzJy5c++8ZzIJ98Dknsf3Ot8593z3
vF98USzF5eW3qXTBeTjOTo0zDexgOH3Ws43s7EzFxBnUMPOYDSnEQb/MnGE0dkdBSne0ccOY
QrqxYeiILDz3yG0oVNSUQ+25LXsuilZ9gAeKC7B0K9Oh4Z38BzGR2n2943Y2kxrv0mVa483p
VQeKcE/hBrz5r6WYOYAs2VuPYm7hUTcqiSccIWcu+LJ7+CcrG1MpgW9AsZ87QX8nYNxQMhhO
d8WcOcAuOl7FfhbllL8vXjtGJsE2NIe0QHs66UYu2PgIlhsxTs6W25JdE+c2H/KMX/wollc/
guL8lShmyjQs96Mf/AfkgBhHWc7SgN+vRw8VyYbCR8PhAR+HAW7w6bXy5RIy09H30Z0CpK2K
l9UuQ9YD2zSDwbF+8F20AzUuLoTQPFrvhiYGaNltJxmNxDpqhp5qexCvOWhcIpJOljvTVP1O
Hkm0rHb48OFiWIqHp7hXoXccx0tv+clzG/qeiB7eX9iW2Z9AKnGex3uEs6P8ZZoD6KUI2CIr
roThtDPYtDQf73w+Hzt378X+/buxnBrzJmpvHXWnkDZlOUr378fzO5/EukUDUFL4EI64eEg6
2jND9GHccdmTplCgHifP2vHub+5D0e5++Mmvn8ff/rYfv/tRLjrrW9nIo41+F/b9A/X05HDn
+Sq8Ts8U+iVl9Ke4o6ihxWQijeJq3j6MTjIEnb0ycQmFP64670rrpF7MaYqTsJ2dvXicUglr
fm95ZtOh/GxkqP9yqh5T1xQLXTxLw3LzQMNyq3lYznKWBuT7RJXqInNaA0vvDzVnZr+M7/wU
ydlXgA3G+YKvCYPBYXYt77xmiudNLzb65SmEdr7elRoMLlkxo9xGjcYhx40UJwtbyB/VPzw0
NXr0aPG77rrrxEY+Zsh7N9hQsKBsWLgHMmbMGGRnZ4vluOEIlZo9BTOJQMEjO1BFGwnLSzei
uNI19G9OmhrZ45Q6cthA9IIdxw48ha08693SBPvHf8TKpbdgx8GPYMsaissvHU0J5k1nTfV7
qKiqEkNuFceOYNuGAoKfianZqXDQcS4gHv3Tk1BbVYYN+TS+lGFHI/WAxkyn0yzrf4OflR6m
ntdx7HjwfjI1XGk6kZo9mSh0Ur6eQVVdM2qP/Qk/LC6njPHxKoMxfUEGDm36PnYfO0VDax9g
24MPEu4MzB7PJwZrNIye3vLsJ3laSB4yvaWrcc9thSg/3YIBI8fisuEUaTlLA0IDXKci4WLX
HkVCWkGDewn8/Wvyy/juo0i7dq4wGOe+/VXYcjRj0dF4AY0v7ETdD5eb4nrRDLRHEmbmxEQ4
tRPiSZbLNZ7RmaAVEBsOcbdGmIy80Jm8Upd4L8aECRPEpj4equK5DV5NxXMY7KZPny5WVc2e
PRs1NTVIp7NYUvwsrRWIBn94KiGFdjVSs4/8ZwtRuPIHWPbVp2msaAImZNK0ATfW5FzKID9/
hduSCTODPKnjsWZVLlYXr8UtPBZDeytyp2Ri/64NeP+uHchf8D4K8+/BdmcG560pwlVyuIcJ
O13KAPKUFWNlmYyhJ+/TePI7yCbmzbPzkFOyEffcsksATJlCg0g0Sb1y20wa0srDk/n1NJS1
jknQCqhcGmKiRly4kfjOlnU4uZJwb9suYnJExrTUqV/fguVn78Om1YuxSURNQL6TpzBvpAMj
d5mRPG9q8uy6uwi5R9Zi7eKXnahEc+tC19CW1r1UCtyIgRXXgzUQStlHwkhEgkboxSJ67z7m
GtJnL6STut/FubV3iGW1LS/+HR31NERAru3IW0ExZl6xcNxW87UN3Ity0ER4wlXfPNTZ0dZM
K4dO4diOO1wyRMVwMHXOqChXEoJy7aAjzsvLy9HY2IjztBdj7969dF57IvLy8jB58mQxAe4S
KlyPvQo7nngBV/77UkwawkakDjvybsO+64uwQ5ln8GSjVEKHHQ20qigjg+dW2uj6RIfTT0GR
5kAq3e2hGh+m5bkXxqUATvJw2goyB9G10w72DPAmdjtf0Uh+VB/AUy8Ady2bpTXMpw8gd3Eh
lm95HgudS3J5Vl7F9SBOAYe9AXaHzS2zHsAw7EmzhcqJ5WHZWN72lkYXTbMVcIZku2GkZzl2
www4RY7PclLeMyGn+p6wP1DHH72BwkYe7v+uG4UhKfoWwM0niQ5e7aCP4E7nslpOGXrguAA4
NWuMGzAA36lWBz7/8scBQGogZ86cEXvfuB7z7/XXXxcJ7Jd1QtZxDk+bNk2kjx59JZJt1OaR
XhNphMg0d1HrceiyyELyhDgbD37y8BQLzP6Iu9R+wHslWLe4BDPnzcO5l/6Mo/XDUHiLway1
wpxE1PoQpDj3fU/c+Crqs6VROJjKrTDw8DJddzeFjRA7R1oy/lZSgF27/4B5X+qHPXuouzJh
Oea5DAZDeeJyjOrYELkpqym+/J40pTyykoVG0xc/K+3i1ICZkYjEOxVDjbK4PkRuf4/Gw50u
7c7FNDzlXhSTef8GOCrL0fzcsxLE99MHH9+InqnyXfaMdYdsZAQTk6i3QRPhCdzrMOtpSJSI
9zg4o+JLwG3dJC9+8nwGZ4JXS/GcRuSdHRVHXkP5B2fQmj4C111PhyEG1JIKoRVxPEtMs9ac
7BnPMdJ6s19L19NyplC+fbqGahw89BaqzjSiX/YX8KWpYw2X9vqkEWaimhcuJ304TPJxja7m
Na4F9SOcv0bCG13WVz/104XI8IHCupAi5unKcnprKvc0Amu3hpVVGea5Zma2Ybw+8lRrO65+
PfyehkpX6o7riOxpjP3cJDIayfSu82VMvJbUj+P5cmre/UAFkSzrnwkKHx0SXZeKsZNm0S8Y
LvIlkMJ768Nfe2/MjelImsYQHrEZIzF1Fv08IrsmEHzD0zVyWlwjoQHv+u6fqnxn/EP2KAhW
VYDqqpmRHV7WA+QTHhM2FAlifwa3cUnk92s0hAKCaNfCFTA+8GWGtVIRw1PCK0spnBdCw5VG
hmlbztJAz9KAfE96Vq4CyU3y4BFo+bQGvWg/QzRdC01KM6/YOMoLNVQ815yYRENVgTCN/FLc
6Co0kDz5/8J3V3zNp8rMMTLMT+kPhDMtXXOTVhAkTUlPfSpgceMNJs9xI7QliKWBqGpg5H0P
oZH2lbXQWU18Kmw0fkybeTCvmDhusOh/EpkLHr7y39NwSdXTGgnDltuVWw+PbM+9UILXibHB
YG6+Vn0Ez8dD/qgEvJQRFS4WUUsD3UkDWdffBGx8EtWPPYDWmk+iInrKsBFkMB5GH+Zl3qBE
jjc1P0nUy+AfT1YEbDRkuxk5SeKNEjfM5g2hlqrCSFiOYyfDWqjn/1V10fNza+XQ0kCgGmDD
IYxHoAghwsWsxaFXnec1EmgSnHsaiXfPykSvZNnw+ZA+ZhL6kCHqSVIP3pk1N+gM6w1vJqpc
nWCWbsVbGrA0YGkgnjQgRqe4iUvQVkvabqejTa8Z1YkHnzkbT3IGKEs0v3ZVAxK4UdAEV3E9
s6JfdaQPs1HRDFSwPD35mIf0OqOwS1x/PPW45lysFEsDlgZ6igZ4bqYdnQl0LBE1AXTdK3Dw
AztOnXegpYXPTPXhlPbFB1TASfoGM2DEiAK6WkwdVfccg+9G3Kgh1XAlntq7CCzPUiZVJH8N
ugobrF/yC55H8HkLVrb4gVfzGj9SBS9JYHXQiG7o9cSIWrTieko5+dOPeFu1RsYfqDjLzy+Q
CQAflMgnoyTwEVP0tD36h3N4ic7OZt69evUyQXNH04dwxFzolTdiIjgJqZniotDCnFd3mXC8
kZO4+nSK5ySKjqTOjCSIl7j4Kc/oaKSnNEb+y8lZcT3UKOs5R+rrugdglwd6Sjn5U6QoBXcD
5Q+cjhgyP0jVF7IoeWeR867wxJffo8OUwnVBCB4uq/DxZeWXT6bIGpE/NV5yc2pMBl1PI1hX
ovPdMsNV4CyvpYG40oBVZ+OqOLpaGNqY0UldjA7uZvAlTBGRR3xKc0Xz04hGhFkkiJjJ6Rkv
ckRR7n0q6sukDkFFQiaLhqWBeNaAfL/VdyA+5e1qCS8c2ofT2x9G26fRWXKbPHAEhi55gA7I
povWYuD4SHT+Au6g8wE7EgM4RkQvk6w6+ngjgyELz7Mp9sYMJKazrQ0dTc1IyuI7IDTXSfeH
c0aSlAP+ZJr500wqbynNY4iGK1HS03N0x/sfDtDjWmFLA12hAVmp3XXXUwqzeE+org7JXHSF
HGwwaovuRaYtAb3SIvNNrs9Hy4VT+JR4dK59An0m36hPjnhYHFTI+8BJsbzsNqAd4aFKwYUX
qQK0v1+Jz556ls6i/0iIw8biwh/2ouGPf0V7q3abXPBySglVKfnF8PdyqPDBc7UwLA1YGoie
BuQb3BXPU//9MFKTEpBCoy/eN+1Ry0If7eH+mDbzOE28YuFoTIV2g9PIVKJNbPCzXT4sGe99
3Bw4by4JfZvJcxoiTp8QOFl/kO2NTWjc/xJaKqvQf9litFWfxKfF25B50yxkBjynwvJxBlSn
ZkhNU+PN4NX4WPuN8mIUF2u5LhZ+al2ReY5n/bNsF4/rqty2nf2EehjUxAbcJoVWJnxD9WfE
KxZO7ASnM6dsfOo4nz/108UDMHtCWni8xZyGUkxG71MAHHgYR/2pKGl0eUnfxbej5R/lOFtY
hM82/Qop4y5Dn1tuRiLd/OffKfIJYBZSL6gnDJe7cdlzgn+OviE8efmGNUo1EsAozgjXirM0
YKQBrj89oA5xO+LMScyfQfYkUvPWo/8zFeKXVXQAiZeMFT0RpKWjz4/+JOINeyZ81SudQRUL
l0DGIokuX+JhKna2ZBp7413hR98PcPwt3LbOIJe8FKy6uhonT55Ec3Oz2KrOV8AOGjQI2dnZ
4rapJDoyPfNf5+LCXw+g8X/+gI7MDFyy7ptIvXKcAUV/UZwJVeHs18cxDRWGw57O2KB4wsRH
SBaa7/zEh6zdRQqpU728ZvF6OCscVQ1E9eWUZWzwPnEUzxsLZ5Auk+iZtmQ9eufeTc2MBpfU
fyQy1/wK5781C73z7odt1Dg4PnpX2ySh4MXa20lWiw4Pob0afD94J2wHK1rwX7trceozR+Rk
kToNgCJfunTgwAEcP34ctbW14gY/PoKXexx8EdPo0aMxYwZdlNSvPxr+twxtNKfR+4aZaK+7
gIa/vICUS7PRa+wYavODYCrkkvCyYOUzAKEFSLDwerrh4Otl19PWh8PhpadlhS0NXNwa4KbG
zCZ18tc//w/gles9Z5mXIpMGjELmD39NoyjT4Pj4XdQ9fKfW8/CCJB4x6ml00M4+PnsKtIpK
bO576HefoaON+zqBOdlcBQbtG4qvdi0rK8Mrr7yCgQMH4pprrtF6FdQdYmPy4Ycf4vDhw2ii
ie45g4ehc8vTsA0fioFrVsBR9THObvgvJPbvi0Hf+xYSfWxM5KtkbdS9ck/GcIk6YLe3013c
qcJ6+pZUTVU1YF4zmCcx9VjT7LCTHHy5tuLcsimRltfSgKWBONeA/t3X2gXxl5P0yUHkxmUw
HiKDQXO5pi4MHqY0DRI60Y72jjYyHDw81RHd1VMG/F1R7e3teOutt/Dqq6/i8ssvx80334zZ
s2dj5syZomcxa9YszJ8/X1w5+N6xYzhIsEmTrsLg+1YhfdpkGqr6Cvp//S4kDx3iu3zs5fja
3LnYcYx3Q2padpx+GSty52L+8mfxmShl1RC4RPTjsePI7lIcOW20ObIO2++Yi69tK3fRcFTv
xtz5c7GmtMIzjmQ7cNpXL0/PR8oaoxrjktbyWBqwNMAfnj57ETw0FejPRJ08JFX3ABmMejIY
/miZ0IhkNB8h0trWSsNTCWQ8qNcRSeLB0Gql3sNLL70khqNuuOEGTJw4EX379hVHmfB8Bl/7
ysaEjcdQmts42kRHnSxegLTJVws2ib3T0Peuhcha+G9ISknxybo3pbY6tN6UveoAvra4AJUT
lmPnjrsxOIy29x+bivHiGSPWWZjwpUzU/P1dyI371W+9IgCPvlgOaWZOibhcXDHEs/ehp+jm
YxkMvW6scDgakPUpHBoXGy43GOaNRgcNGYlhI2pc+enrp2mOy8BdDm1kMM4/sBAd9Y0+cQVd
bs1j4BJpQ18SrZ5KSGALFqzRcOctbFHZaJw6dQoDBgzAyJEjTelx+qVjxuBCUxNa01LJ8LLg
mkukTX1JWX39zmdwBy+FViM4qvZh0T2FaMhdh+c3LcQAQYYU3/ABtq3PQ25uLv1WYMfL1SLF
XlGKFesfR+m29c60PGx7+QRg/wAb8uahhKD2rJ2P9TuPCXj1z7gv06abmtdwQlgIO/6x/xCG
TZkCHH0RdD4kOQfefeUQkDsDQ8hfXlqEPMGfZKAVFfsqyNzYK4jPfE8+jtMoLVrjlCcXa4p2
o1ZUOiqchgrDfMBBdFY8hH0Hdrp4rCC8OlVgy38RaiA2jU7PV6zSMFLzJFc7+e4lMI6CR342
GI1PPYDOCwH0MGQPJAbKpYW2SBRVRZM5uJ4GIapLYsP1c355mKqJDALTMnJ22vXdxCuqKNEh
NvEZwxnhyjjuaRzetxmr7tmIeizAju/PQYZMpKZzx70rUVI9CYWbNyN/UX9sL1iK3VV2ONoa
UHloF4rfGCXS1swDSgp+hgoMxrwVa0AmABMWrMIdXxjsoiY9WTlfAK1Jw9vVNPTkOI69R4G7
Vy1DLsW98QH3P07hANmMebPGw36sBGuL/4xJazbiyS1FWDTgEDZ+dycaUgd58TlW8gCK9yQg
f/MvsblgCY7u2YT7xZDXedN8wN6M45Vl2Fi4G/MLilCUvwiVhPdHMWQnJbae/jQQbn2PF3x/
+bTSg9WAs02iRoonijtlL8NlQKjHwXG6n8qFDUbDkw+gz/ee8oLT48mw8v2skoqCXzMTSXwJ
Ew1OBWc0fHTLgpWUT6Lkyelz586JyXBeaqt3HTRbzxPhFRUVYhkuw9Olg3owv2HehXJ0159R
mcmgu7BHaSztFXuxvQZYfv9d+PyoUfjiwhVYQHA7X/jASTcThT/7BqaOH09zIGvJENTiQnsW
Js64EVcQ3MRZX8GksVqfxYmgPbLG4UZKf+29U3BUv4lKMhdXjRyLGTOB3W9Qb6X2XRwiatPH
DYCt/9VYk78Zq+d/gXpdw3Hp6GFABg+5MR8avlL5tHK/qRbnLwCjpt2BZ8nIfHf6EOqU+MiH
c/Qrt2ATFs6YSDIvxhKiWe8csvOQ2wpYGrA0EJIGRL+BDAOP4rDx4J/W26AU2TNwPhN686es
ZmzYYNQX/Qey1j+FxN50TJIO1jys4YckbJBIZPK0zFDmfA+mB0k4GHCetxg8eLDYn/Haa69h
6tSp6C0U6abCRuPFF18US3F5+W0qrXQKxbE5yllUiF8uuwI7V9yCrasLcdXuRzGeyDmatSNI
tq5eiK0K8Rzh57QbMU52S2zJSg+lDZza4uC/RnJlYRpZjV2H38Lhcy/TMFSeGA677EszUf/U
myi/lHdzEu0sWmSVTj2Vtx7F3MJ3KM5ZEchuaM6h8EnD+MWPYnn1IyjOX4lihs3JReEP12Co
z3wAbGoGZcmj7zWakoP1tDRgaSB8DYjBEm7wlcWobEj0gygJmeno++hOwbCt6h1aVrsMWQ9s
0wwGxyr4AsjsD/OKgUtJTkFiEvcvKDc0Gd5lRiOJltUOHz4cJ06cEMNTbCD0juN46S0/eW5D
b1T08GZhbjDnTL+C/mZg4Y8LsXthPlY/tBu7H52P1H79KD4TBTv/BzPSHXCQRk69/SbO9L8E
aH6D0nrp+jbUUDvbdUokZ95Zy5k2H1i3CfllwILC8QJ6yFWzkVlTgAcK2ZAVUV8COFZyHzbt
GYuNz5Zi0pAM1B3cgNs2aMZMIInBuSThrTtVj6lrirHwwTacrvg//Oan+chfPQi/3zyE0k3y
gY81MgHXRie49bA0YGkgQA1wo5BAbRUPQ3mjaCdlaw1H5nd+iuTsK9BWRZPeBV9D34L/FmHG
annnNUN8b4rUDBGvWLgU2s6gDa0yt6AmwiMrIA818cY9/l133XViIx+LxHs32FDwXAcbFu6B
jBkzBtnZ2UhLC/24E7l6CgOm4rF8mpw4tAmb9lXDNvJq0Lc/Cn7xJ/DK10YaSlq/rgDPvF/P
4hg4/nZgx88EnKj4ALUNcj2USHD9ybr8Gmg9lhxMu9I5hDVgvBi2Yuozpo8RsKKzMmwQ+qfb
UFv1Mjbk7yf71oJGFyUQn/cFn8rS1bjnth+h/HQLBtBw12XDNaCkoPOhELe8F4kGZN2V2dWH
Zbz1DFkD3Etgo6H7aUNVCcj47qNIu3auMBjnvv1V2HL4Y5aMTeMFNL6wE3U/XO6Fq6flCgfa
Iwk5MxKRDaG2BKmDjEaAPY3IGgwWhXd9T5gwQWzq46Eqntvg1VQ8h8Fu+vTpYlUV792oqalB
eno6UjyW1lKF5zofgGg8ephi077UmfaQWfdi3cGXsHHjI5g19Zf4zpP5OEmrqhaXPc7JGJa7
Cj+cQyu6eFEUjf27nXaHBk3HEO9UfO7GCSgpXod7av4Tpd+Y6AaTvowczCCrUYkZuFwOcdEg
1bT5OdhVkobJY7TIy2bnIadkI+65ZZfAnDKFkGgCfuW2mSilITU3nyKU3v2fyD2yFmsXlzm5
TED+kwupD5Wh5KNYpLnyYa+HXgcpxNrP5b4yF9azx2hAfVksgxGNYuWhKF89gPTZd9JJ3e/g
3No70NnQhJYX/07La3kdYyfajrwVlEj6Ya+gkIMAbm1toVEpnk2mOzUIL+Gqbx7q7GhrRlvD
KRzbcYcJKbWymYCEGM07osvLy9HY2Ijz589j7969wqDk5eVh8uTJYgLcmLTzEiROjIj2HHQd
IjWjtlRkiF3bRnnWeKos2YC42RvhGEvvHcv87cQ+A2nJCWiupxVWqelIpbPBPJ3Gw2FvgJ3G
0jIy9PMpGh13PjyxrZClAU0DxvXK0k6oGiB90v+3rxuFISnG3+L85iZdnoOOmpPaslonq6EH
qsjXiVOzxjhjAnucbnXg86+cCAyYoM6cOSP2v/EiJP69/vrrXrjyqlwejpo2bZpIv+qaL1Pe
aFiK5jOSaX7DOHcepMJpCD0IGQZYSJ4QZ+PBTx6eYoHZ788JySImHjfAyU6WZkSpm6ZL4rFK
zXDoEvwJ75XO/LWeB/NIFX6myT/1BWc/dRHJuLg6Lx603HQ8oq2ApQGXBtT6xJHh1l0X4YvQ
49QlPYRPvrJGmqC09vcqXfpOu3MxDU/xCIWm/8z7N8BRWY7m5541wvaOi1Gxtbe3EW9q52i6
gBs7P0Yj+lLxvMWIESNcChkyhI4FoVaTV0tJq+dK1HvCEo+LOCwCTmnYkDAtUWUiRlMjLmk6
WbkeMj4S8ruIkofp6mlGi5fK1/LHTgOyPCVHfXnLeOtprAH1HXHqkh5Sq500zyB2hBsguz84
NZ1nrfyRB1T6jQtpQeVCND37a494swDzionjCXf+Mqb7wRPoIiY/RiMmInkw4eNDup+L1ovn
i66spr60pYfxRY/p6NMlvj7eF08rLX41IMtTSmiVq9REcE+dHlmNMor99JMGgttalxPqFn9E
VM2MbFdSSB43qZDQA0VKpK0G/AHPq8I4OybrRVmaGEkUqOQRh+tu+ePi8qqBvrWiggddnhK5
u+nJt0ou3lRZnlIDVrlKTQT3ZL2Z6y558Ajau0Ub/BjEuYJKHCvCvQLdiqpwwsyDecXCpfCm
ajIaHbQZ2NHuUIyGa82vuUJiIWBgPPQvQGBYAUFFkXRA/A2BQhRKFCX/CbZMJb9g8QyFtyK7
VANclrI8WZBQ6kOXZiDKzFXdhM9q5H0PoZGWp7bwYYX0j0+F5b0bfIGR9mN/eD+mzTyYVyxc
Em3so34GHHQ8ektLs3N4igbHmmt4qavZ6qlYiBYMD9mYhVPgjCvp6Hn7StPD6sPh4OppyTDL
GUpezfIn6Zo9Q8Uzo2fFx4cGrHINvxyM30P5hmZdfxOw8UlUP/YAWk5+4mQXWb2nDBtBBuNh
CF7hZ8g/Bc4y/TgXHdTTsPERR18cfQG/P1juHzkACDH2JXQUmqLk5DdPhkfXGdGnOKNoP4JI
md1gWsWKbB5CEMwtkKnPW3ZSgVP3Mk2GTYmYJISLb0I2otFSRpVoqPlVaUTVT0MFRk2XlFvm
SSvG4OuNGz943KjmO0TiMj969OD14611OWchaHHDSirr8+WbcAX9ZBrzlWWjl6E7hLUd7rxK
lHoclKnEOdkf43Oj+mAJ3VURKacqK1I0zelEq2J7VxBzGYxTzCqrMXTsY1X51Eqtxsdeqthx
VPPZnfKv1kyt4dN0puYndlrsvpzCa6e43fFse9xl4Z3WfbVEvQunReR5jQS6WyPxqa1bUfNJ
Fe2Y9swWV0D5U1NknPqU6RwnnfSrcDKOYcziJb7/p5uXf9hQIYLjwQ2P/Ok5muVXHy91pI/3
pOcuGw1ek1OPI8OeuN4h2WDqnxJS0pFPGc9PGSefMo3D0ql+GRdPT32+ZZhllPmSTym3DKtP
X/BGeEZxenoSxuipyanVOaN0LgIzemo8+6Uz88v07vxkfcmfzIc+v6peJAxp0alH1qf2c6e5
fTJN0nCnaOUgwzJdPs3i9ekSLtbPdpo/4RqSxJcx0Uketo7WZvz8P4vQZq/Dt+/9f0IeFlbv
5ItklMawnK5PCzRO8lLhJT+Z5vmU8nlaek+YcEJMn2nLp29a+nwztCq/UbqEMUsz4ihpGuGo
uvOFq6aZ0ZEwRumc5ksOma7HlTiSdjw89TJK2aVsRukSxixN4qpPmXcjHKvcVE1Fxy/1LsuB
ucg49vsqg1DSJB+VRzh8JC4/Q3V8ll+ort3RRrej9oKNN/dRs2hL6HTQmSIOsduvF51mKDMq
M84Np7QhqgJluh7eX5gFZxiJHyh9xnPjcCiaLjBjoUog863Gsd+fzlQ8mT8Z5x1m3Wkc9Gm+
+Eo59DAclrzUND1to7CKZ5Su0pbpKo948av5UGVimWWalF8NSz/jGKVzvITxRYvhVCdoUSE7
i9lFW4Vhv6Stj/fFi7JEeG6MQOR2Q3dfn9SVzC/nRMax37fO3PVAwvJTOpUOx6k8iItL3zJe
whuFZZpKR8ZJeMk3lGdDA1/+FoqjikOVx0E9Dq5DtoSOFtz79aXoneY5PiWFDYVFIDiB0NfD
cDhw5cm3g3IZtAseR5XLU24ph1sIFVbGGsV50vF84fVpko76ZJr+4FS+EpafarxKU+8PFE6P
Fy9hVX6ZfzPZVFgJYxTnTcddB7zTJCXlqW/dlSTpVfkGRFMiOp8qvi7poguq+lP9UhGsKxkv
n5xmpENOl/GqgZa0zJ4qXTOYrornBbdiuTAZDb6mwpaV0QvXffEL+PTT0x4yyYx7REY4IHmY
KUymB8aWX8zgG/vAaJtDqbJLefnpjmeZ3I0GU5JpEt6MulG6C5eRuHFRnExToky9Kqzk4ym3
KapHAtOR+B4JcR/w/gr0l3+pM3/5NU7X6oBWZFa5dW31cL+Psqz8la0ezpf8Fw7tw+ntD8NR
e9IFpsc3CksZGMkoXRJLHjgCQ5bQ1bBT5sioqD4dNLSl7dTgektG4+f/WUgbUNpx7N33BGMW
loXnn/RzgsyEAAroT2CNuKooX2Q729rQ0dSMpCy6DtHpOun+8A466DDJedCfjNeeni+mZ5pR
SFYkPZ7vfKg68pcXf+l6qfTwzEvyE9IG8ymjIy7pcLSejw7UMKji+6PB9Bk+vhzLo5W5v/z7
S9fnS+ZX4nHepb64yFgVapoe31dY0mEYScMXvD5NxScCus8ZT2iZD8/Y7hsKRF96GFVf7FfD
qiZkPBuM2k3fQAYN/6fqRm8kjIon/fo0rY7IVM/2t+XCKXxadC+w9omYGA5ePdVJNoKWTtFn
Oa2eSrIl4u3/exv//fQzbgmdPr0CvQB8RATSngVD3/5+JT576lk6i/4jwZWNxYU/7EXDH/+K
9lb1ljsfQkUpiQvcyMl4+VRhjOJkulGaUZyE56dxutYoqnCq3xjHjJaKqfklvlqOMs4bOv5i
zGSV8fKpSm4UJ9PVNKkTNU7CyTQZDvZpUt1M6oCbuv6dVGuHkZxuzJ7pU/Os+mVuZZzUN5eb
LDuZJmH5yXGn//thpCUlIJVWGYmDC3VHhwQa53EMCe0AV48c6UVyMA/mFQvnIIPRzqM4lD/6
/IPtq1/9f7TLr12sv5UCGCnELE0P6y/MdPQwkravtPbGJjTufwktlVXov2wx2qpP4tPibci8
aRYyZamqhHz65euia+w5WpxYK5E5XQcjk3RPX3liULP0YOODo8VfRjpBdUEz/kZ8jGCN4iQL
X2kSpquf/mQ0Sw823kifMu9GtIziJDzXSV/lqsf1F3bT1Xx6eH16dwsHmh9zOHN963FazlSj
X1qSODqE9aRPN4vT69QIT4VJobaq9azcca6mRMevDU9xT4OGp/jMwmS6Ea+Dux9d7PSKklad
xUr7XA76Lr4dtWQozhYWoeNcHVLGXYY+t9yMRLr5z7NxF62/SW6kwTBIdjaw/EXm+VL6omdA
J+ZRMk9+LETM5bIYWhq4yDQgexYBZjttyXr0vnGZgO74rBr1RcvRXlWBhN7p6JP/HGyXjEft
/xtrTI15xcBxp6IjgY5EpwvhxNHoiRRIpAOpPBvdGEiisOClYNXV1Th58iSam5tFF5CvgB00
aBCys7PFbVNJdGR65r/OxYW/HkDj//wBHZkZuGTdN5F65TiFkvSaNZ6ycWU4PYw7rN2PIWkF
+uxKw8Kyq3kzk7krZTSTyYq3NBALDcSw7rubEp8ZUw0GAyb2H4mMNb/C+W/NQvpd+cJgOD6m
O6cDpOeTWRiJYnMfTQckJ/cSt6raeE4jkS7XQAcbjti7uro6HDhwAMePH0dtba24wY/vD+de
B1/ENHr0aMyYMQMj+/VHw/+WoY3mNHrfMBPtdRfQ8JcXkHJpNnqNHcOzgn6EV9P9lYI+XR/2
w6pLkgORMRCYLhHeYhq2BoKp32EzIwJ6fhwOt35FgoZR3lRZjdIjF8dzFtpZTf5p9p6j9TBU
yKQBo5D5w1/TKMo0OD5+F3UP32lKz+yyJ5VeJPydvD9DTrJQO2vjO185k3SYbyToB0WDr3Yt
KyvDK6+8goEDB+Kaa67RehW085CNyYcffojDhw+jiSa65wwehs4tT8M2fCgGrlkBR9XHOLvh
v8g698Wg730LibQx0bcLt0LrqesreCToy8odCVp6ea1wz9VArOuN5Mca5bqqhsPRcjTrfTRp
K3lmNmGychmMh8hg0FyuqQuTjyldXQKXLn3Hiz0afNNqYq/UNNoi7rmxT4cTlSBva3/rrbfw
6quv4vLLL8fNN9+M2bNnY+bMmaJnMWvWLMyfP19cbv7esWM4SLBJk67C4PtWIX3aZBqq+gr6
f/0uJA+l62F9SWgvR15uLnYcC3U3pJO4oHMrjggyDXg8dzaKjtT54ozybbci9/EjPmE8Eql0
tA6T0UvYgB235uLWbcanEQfNy8XYjiO7S3HktF3ENBzbgdzcPJSHqS4XecsTAw1EoKUKSEqu
l8666VFFfb6BAVHuMUByTiOQp0mmHR9RD+MBMhj1ZDD80TGhEdFo0SjxuiltO4YtnfY4pNBX
+oXz5yLKxx+xVuo9vPTSS2I46oYbbkBOTo4HCl/7yr9+/frho48+wtHz5zFt8WKkXXmFgEvs
nYa+dy2kZW20T4Mm8n253pTYSrdOBe/4zXC+EHR7FZDhJJGKWfnr4Bid7odkBjLBk/SRcCRL
RoJLAo2ilI+fmcjslRYSo39sKsaFoq9g0pCQ0C2ki0IDXMcUJ14L1ViofgUuLryxk62TLlwK
Z9ioTRgMatcafPQwnDplXrFwfEihdLRHA4lDBw9FRlo6GY7AGze5Xll9SqJGTxVO+ttos97p
06cxYMAAjBw50ghNxHH6pWPG4EJTE1rTUsnwuhWVmJFOm/2yaEZfO+edaUsn+fDTXP0OlJcW
iZ5ILvVGcvPWY19Fg5iIT0i4gL8/tR433ngjfXkvwIZf/QE16O1Ma8GHb/wdH5/XhvQq9j3u
onHrig1445MWASdl4WdCyyf49cMrBT2mufLh36LaAVTt3oBb1+xEHX/BUdY6myuw4dY8PF/Z
6OSlrQ13Z82dR40+p9N5MClpqH9jL4rW55G8nJeHcKSWGDDvhBa88dufYAHxZd533f8U3rtA
eC2V2JA3HyUE8+dv/wvu/+17LrnbBKYdrzx1P25c8DDeayQm9k+w46EVGn3iseKhnSIPAjQO
/qhlrtYFFs1XmhRdwsiwEZ6ergprBK9PDyYs5TF6Sjpqmozjp2e8vs6okIH4CZ9JeJBxv4eB
UDCG8SJqDBZGrKoH6ddlJAzq3qgJtGRf/riXoPq9eg06dDYYjU89gM4LAfQwZA9ERyMawaRE
G/cxBGkHtduJaampyOrTB6l0imFXOB6maiKDoF9uK2Wx067vJl5RRREOsYmPteXbceWQzowu
p9uPlWBt8R5MWrMRT24pwqIBh/DTdb8Fj8yU71iHwpJDWLCuCL/cdC9O7dovXkRpWk8fPISP
m2nTyyd7sHLjLkxa91Ns++WPMe3sC8hf+qygIWVgeY48sRTby/ojv2gLtmxcg6ayrSjeW4WR
Eyag/uhWHDytNfANH7yIFxoGYNxI2auRVPjJL6p8WZ15pIeWR+plVO7BR2PzsHlzIXIbyvDI
M3wbI1Cx8/vI37ofU1cVoGjjOgw4VILVSx9HbeogzFuxBlMIZsKCVbjjC4MFPMg49kl14CAt
/ysoeQ9rfvodjCdxjjyxxDAPTqQufahlLgWRcfIp4/mpxrFfDbvh3PXIHRecz5hucDSMoVm2
8OXTaPii40xTq56xQCHERoWoSw4z3SvNgws2Yh5qnkRvg3scfn4qTzYYDU/S0SDfe8ovnqQr
jJBKJEp+bnHp9CmxLaOFTkW3fVD5AUV0ghvnYJ2vBtmIlgrPBWqjIZ9z586JyXD+Ou7dmweS
3C80H4515MgRVFZWaku9+IJz2sauwoiA8kdfUfRhBRS2/ldjTf5kzJ01nixILS4dPQz4jIe6
GvCP31fg0rs24xtzeDhsIh7b0oCv3FsK/gLnfLjyorX1qD/fBNugyVjz9NOYR0fOpKqM6BTh
/tPX4f6brsX14/uiobYJVxCNd07XwzZ/Ohbg5/j936swZ+FYvLWHvvtzCzCeCEgeMg/yqZF2
Gg9pQ1prgSnr8NiyOeIO3+Q7c7D/uaOoWzsOL9Jz2KIifP/WiYLmT7e24CvLf44/H7sLeTNv
xFuZm9A2i4anxqaigVb4JSR8iF/c9zUcfScBP3j6fzBrJA/NcR6+h/y512LW+CzKQzOupNh3
z2g9M00m91+97O4UzSfTOeSZL+90LSawv5KuL5pqmurXc5CNi6SpT9eHJS0JL8P8lHF6nEDD
Et9N0xtT8pEw3hDuGG8YzTjo+bgxNJ+2f0mrdN403HVWjxf7sNsQyjxJGVhu/nG8zIOEMQtL
XD2cjHc9echIfteymqQYzvdU0k+gURJNBqDto3fQsGkt+v74d0jsTcckEb6Ek/p2h52EmGGM
hqd4cS0dg06z4TQJTuxt587XIoki+O7XYJ3MCONJZfqiocLzPozBgwfjxIkTeO211zB16lSX
0ZA02Gi8+OKLYikuL79NpUl7diodCWv29CWXbQB9Wb/1KOYWHnWhJwwnr/0EXq4Hrr16lCve
lj0OZFK8nC17LopWvY8Hih/Ekl+xbMOxKP9BTCQ75HY2DB2RheceuR0/rnTGUqW9VEzF9MfN
q67ErmdeRcPCDLywvxNLfnG1G5V8nAcC9+m49DLHDnNe+k4VsZUH5VKQZD+LcsrLF68d48K3
Dc0BzyDJeR4+hKXVwUNtblN39GiN0POHZ+rIaAygNBuGjaQ8PHwbCmUeKHasyXQSl5Ev3cv0
YMqS2Jk6X7xMkSjBjccNiTGkXkY3jjG8jGU4Pa5Mi9enLBcz+VhH3JDFe77MytI8X9711SiP
/vQjDIacPuX2XdYpRWcJmeno++hOIYqY9H5oGbIe2KYZDI5lfCceP1jfMuwaaKAol3FifxQd
39bHjmVJIAuS2METxCRVoJd0qIo0enk4Xf4EJ5M/vHRr+PDh4qXl4Sk2EHrHMp2nCXB+8txG
errWE5FwzF8vgxpW/XSDiERzPY+V3IdNe/ph47PPY//+/fh9YS6tWGhBZ69huDaTRns+VlZH
1Z2iOQ1v56D4tCnLUUr4z+98EusWDUBJIc0neKw+Oo1NS/PxzufzsXP3XuK1G8vJAjVRa826
GvPlO5DQ8Dfs/9selGEmfckbDU1J3j5WunG7r3eptNeF4k58dF6kiLJp/QxnnHBuHan6yUTB
zudROC8TJesewTHRCT2NoiXGeZAsmZabnox1P32l+0pzUwjMx3kM1vlC4XeWf3ondEmIofDT
0/IXlrwknC89S5hAn/5074uXP9xAZegqOF95kzL5y6NMF08xJEXtuXO/Bm9n0P/Sv70RttHj
6Ry9d3G+4Gvo++BTSM7mEQ2g5Z3XvOD1+O6wUa2UUkfuKfbxUT3no0QS6dBCCidpL3qA75mq
IBaLw+z0lVrGiUTnHxWXh6Z4497o0dm47rrrxEY+BuO9G7xHgw0FGxbugYwZMwbZ2dlIS9N6
GirNQPxsairefgdVtD2/ooJ/x1BRVQs7f2IPG4T+6TbUVr2MDfn7aYVSC5oS+mLil/vg0Cae
GK9Fc/1xbHukkIB7e62Fsn/8R6xcegt2HKyic+aH4vJLRxOch8Wgye1afEh6GjF0AFI6m3Hs
wFPYShYogcYHhRswGasm1KB4YwmG//ttGKnFGv6tqX6PZK9y5qMCx45VocFnJ3EIpi/IFHnZ
few0DStVYNuDBagn43TDOPeJwScq3kdtgxyizEDfjExMvffHmICjWL3pABz2z3CcJBo5bCB6
we7KA1q4RxM/Tm3AZd0MVTpZX6mSiw8rlY7Kh+P1YbM4lUaofl/5MpLD9ZUaKkPCc77mGgVq
QHqik7rzyCtllONlmlMBrux7lQX3Evj71+SX8d1HkXbtXLRVvYtz374DthzNWHQ0XkDjC7Qg
5ofLxeS5is+T6Rz2OuxQ9mhc0kTHQ4NSIv/c0vOIGH220tchBbwyb8JfKs8I3ijOhIyYo5hA
k8C8qU/ObZw6dUps5mMe06dPx4gRI8TejZqaGmTw0mA/S2u9eWmVm03Noa359FMgMhfhN0V5
yCnZiHtu2SUSpkzJQcKbpVi57UsoXb0Zd53+Jn6y4qv4CacOy/R493hUhm1OxsS7kL/gnyjM
vwfbKcyyz1tThKuos/A+hdklpF2Btd+8Ed/8xVrcUkzhPtcid0om/vb7R3E4rxRfyEzF9Nvn
ofjoHnx1zlgNSfkrdZ7Mo0RlxVhZpiTSoNnG53dAb06TU8hUOjssU7++BcvPUq9q9WIUiTdi
AvKf/DayRaclFZ+7cQKeK16He2qK8Mz1XBvYzJJLHY8f/OhW3PmDQvz+9t1Ys2o2VhdreUDm
FJGHF3ZtwJG7SjHJV+dIoxb1v1JPwdRDX0L5oufJg+uZOhSlhX3RDjbNk583NqdLeTnVI8xF
Gq7TXiWNCtehiBqO6OhL1YfMvlGcTHM/PRVmrHtVIQomoYqJaml5nGCCBvnTZy9Ey4fv4Nza
O8Sy2pYX/46O+vOivBz/+D83IfJ5lKEzrAJIFmpcNPwJvKGPRoK0u8Kpnu3Y8WzncNpl/ZuS
32Lrr54wr3hOoc2UbqxYLQtmOJzKS2/Ly8vFCioeivrLX/4iehh5eXmYPHmyhzwMr1ckx6lO
TdeUyhXAV6V0oIG+sG2pGUilRrSlsZEaS83PdO10LpaDbGt6uvsqXJUf+0XeHXY02B1Io7kX
0RbLeHq68i9gqC3P4LkDB/Wq2px+CuqcC0eJlzqWacGGHfYGNLclGfJUaUo/s/bUJ+mS8tDY
QvtFKA+dnW1obGx30VNh9bgyzE9JXw/PadLJvMmwv6ekqYcLlIeKL3mrcSpdma7GSb8RjoSX
af7DTM3bCEge7vrMX8BaLNOU9AW2EpbvgUzXw7rpSlpcRu5YIS9FyChf+ALWjRqgz9f7GSAJ
AzCZX4Mk7Z1VElRYmQd9nAyr+ZewktTbMy7BkBRaoqop3VUmEieJDl7toI/gjjptST3jDfnf
DwX6qVljXPAcIXFEojMs/fw83erA5185oUb59J85c0bsfeN88O/111/3glfzOG3aNJH++Wtm
0YGFdN1rGx2Q3tkOm4MuDWfAtlZtZb4XFV2EPiOcLBWkAw0oyLx5QpyHo/h54cIFgcd+vZN8
jGTQw2ph9YtBVnkVktNt1Oi5P5NTFT9DyjDXASO+UiayOkRHe51VDux34TlhtDhuvNV5BD2W
Z9jFxzM6qBAbxoxeqk6CQteAOQ/JUpesO7kI2W0MGDBQeV26CUGUQFGMeAQiX6h4qlyB8FHh
hd9nG6omclnKsvCiElKEs63zxtWxMtKNN1IwMWq+gsEzhzWTMdAyUfHVxtScI6WwnuRPBaQ4
ptf+XqWIZROctnAxDU9NdEFl3r8B7R8eRfNzz2pxTEd1/sIqbAT9zJbzz5v82mmuxvbAgz+G
vbmRvvi1ATK9QvVhlsUozpeMvuB53oKHoaSTxoJXS7EzwzWLN8YR2Rb0KO9EU0CJsP6PL7oC
y/St0iiZ4ZvF6/nLsC94fVqwYclDfao0VD/D+AtLOno4I1x9nP5llGFJM9CnEW8VN9R0f3gq
D/b7gtenBRs2MhAqDdVvJIs+XcpuFO9dzXmRg8RwfyBI3FDLTaOoEHaziIhPyuePmBlcsPEd
DrpxIpEnNDSnDf7LENUPYVG0cJ8Vj7gTyJd+40L6uxCNv97hilfhXZFOD330x8QlUC+D5zL4
2tdOmoW39UqmYQbKY0cHDcvEgeOjQ2QFNCuw0MTkisnL6kLDtrCiqwFZ5tHl0p2pyx5FfFVg
q9x0dYqLJ8AiqpmRrUMOMhggnyCpeoPzLndaMGWj2wLbO3iw3vnlrZ4v4o0V25jIGgtVdtZy
5LvBKoeLzR9uWUl8bnyk/2LTof/8Rt5ghKtriR9+ufWs9zF58Ai0fFqDXmJHnP+SDRWihT79
mVcsHB/TxMtteUKcS4smxambQd0P7SKmWIjQ1Tykeebsy5exq2Wy+MtGyNKEkQa4zsp6a5Te
dXH+y019z1S/lDk+8yWlC/Y58r6H0EhtaguN/XfQsEY0fkybeTCvWDiefxEHFfLBhfSzUbaI
L3c/YsG+q3lwJntWJe1qjVr8w9WAVSfD1WA84WddfxOw8UlUP/YAWms+iYpoKcNGkMF4GIJX
VDh4EuVOk41udxUzNWQIbbym2Ea7pVtjNKniKU5Xhizj0ZXat3izBi6GLzX9e6YPx0NNUMsh
fPm4MY9Vgx4L7SU6V05xz4IGkWlXOHlsNFbF50/Fr+NClQWr+uNXYksySwM9QwPyvYtEbsJv
kCMhhTeNeJXLW9Iui1HmaBJ5fwTbjwTqfsS/k8NooRZyKHiWkYr/etFdJeT6GEqdjHR+9XVc
byj04Ujzjwd68VAO8aAHbxl4Ipy6FZRAA1SdvHqKKm1rC510RzajhZ9x6fSVVi1gTlPDkc5A
tOlHWl6LnqWBQDXgfK8Mqzi/U850QS6a71ig8kYTrmfnlTsHoTqe7+aBqOSEFBqhoolwth6O
dvrRBUe96NrX+HSyQPUVl+ON4vS50MPo0/VhSdeMrx7eClsaiJQGZJ1jelxvZV2MFH2VjspL
jWe/5C39+vSeFtbrItg2I/710UBHIoXibMkpSO6VgnbaAC6mM9ra6Eam9jZxjEcoBGOHE2gh
Sjh9JQhOUvf6c6bDP0k3ODoWtKWBYDXAX3aitvHpphF1kh5TV/3MRB/muIulzsu8c57ZXSz5
1nLr728HbT3n49ETU+jIoDY+Ip0rJv1PSnKfIeSPSPyn6ytBsBJrlYYNh9upfnes5bM0EF0N
RKMBU+uy9DOfaPCKrnbCpy7zHy6lSNEJV47I4/NeHB7e6uQ9feRP5K3hPAWeRM/4dCyXrMyq
jNIvn0bSh/4isKLov8t52A9XrOWxNBCOBrjuyvrr9DuD2kOpgOGwceFGmp6LcA/yBKojZ3mJ
8nMWWg/SgpoV/njmuYxOMhR0ljJv9OPOBp24SNevdi8nC1c+Vek5zihehQnEL2mwAZH+QPAs
GEsDvjQgGxxjGFF7o1bdBHVirD6N5ej5sVQOIbf3RgUUMrG4VjW3ffzRnCisBu3r63/1NLTS
sei2jsCORo9t7vwVglHBRVrCWPCItMwWvfjVgO86zana94lV76JThor+pVc+BUMKBKp6Dzyn
tF7zUIESi05uI0WVj0TnRVMdpBzb8H9Zgo62VjR/dpasrpEWfLCN8Ne3/mvec06B5Qi1ADhf
oeL6yL+VZGkgaA1wPVTfM8966RkKmriF4EsDgbZvavH4omeU5oVLERFuJ43YRjaOM6HURJoE
d1DHgmPaO+gSpvqmFnS2taClOfg9Gu4VRuGJzEvBqqurcfLkSTQ3N4tlXck0XDZo0GBkZ2fT
bVN9RFzoXBQFCCI6pYROOEzMeJEjzGxY6EFqgOujSdmLqqqvr0GSt8CNNSDV7tQ+A8VC05Fq
J40zFY1YT63wddysKD7cln82B509xZPibXzLRpCOMcJVSF1dHQ4cOIDjx4+jtrYWDodD3B/O
vY7MzD4YPfoSzJgxA5dcMjrojlCQ2YkxODca7EwaDy3R+ttjNaB/3/ThHpvxuM+YfDMjVSKR
aCe7UmncxqfSHr4W7m3wJUw8VtVJPzYcobpQDUd9fT3KysrwyiuvYODAgbjmmmvEHbZ8mx8b
kw8//BCHDx+mO7wbcdtttwkY7dsg3IY2UtUhVI0xnqhKzmc4dCxcSwOWBoLVgHz7ZEsSaUNh
JE+o7aQRrVjGsdyJdO95ooMMBm3NEKfcajf3hSaGS/lEWD8n4Ysir/t966238Oqrr+Lyyy8H
X2I+atQopKWliZ5GU1MTrrjiCgFz8OAbOHjwIHJzc2nXegqRDaLRt5cjb/5azNn8PPLGu+8C
9yVb0GkN5Vhxy1pU6hBzclfhx9+/FQN08e5gEPlwI1k+SwOWBiKoAWkwmKTqjyAL1ydidzQc
7eLEEAcSaG4jKdFGRoN7GfQD/8J0wSiklY4teemll8Rw1A033ICcnBwP7nzta1ZWX/Tr1w8f
ffQx3njjDUyaNAnDhg3zgAvEgPQmjFZH6GevuKuSiY4g0cLWAABAAElEQVRoyI/dzDVF+OaU
fmhuc+DMuy/gkY3FeGzCNXh0frZIt/5YGrA00D00YPKmR0T4YNrJiDAMk0gHfeDbac5b9Djo
EKpEvk+Df+Lm8DCJMzoTDsSx0Th16hQGDBiAkSNHmqIMGDAQY8aMwYULF2iYqp7guDjVnymq
K6HJ5fP21Jbvxvq8XNGLyc1bg9IjpzUgRxU25K3A7gp5Xkszdq9fgZ3HZNiTFvO4dNx4DBgy
kvKTjUlzFmNBJlB9mmVmZ8fBnRtwK/WWuMe05vF9qBPRFdiwYgNePrIP6yk+b1s5UFeOx9fk
OWVajw3E96HSY4JKUHScGNbD0oClgfjSQKDtZDxILUai6E8CLSdOotPQba5+UwRPRg/GkvIw
FQ9FpaTwCYo6g0PBlha7WFHFhiK4kxqZlu/vBcfpfVi4dhMyZy7BxvuvxDu/fQTF6xYj/em9
mNO3Hu/UVGJQs5zsceD0e5VoMemxcG/m5X17cXltX7S1teH4oeewvX4YCm+fKMq9ovQh5G99
D0vyi3B18rt4oGAj1mUOwy/vAI5X7sf+dfsxIXcR7p6eiseX3otdmImCzQ8Cb25DwfZKDBvr
CJLOcAFv/bE0YGnAWAPcOsgWR7YUMmyMEdnYYNrJyHIOjlo7LU6i/gVsvWloypbC171SJ4Ma
7rZWgyW3UpP+eBho2p9COJ2Xcp07d05MhvPXd+/e3PS6HS/v4onwiooKYVDE0i93ss7n30jo
EPDBvt9TVC62PJiHIeSb9OAWfJK7GDv+egzUUVCcf0WkEfTRXZuQv0tBQybOnqT+RBbw4jOH
kLNkI2794hgCuAwPL/9frN1ahto7ZgqEnEVF2LRsIhzVu1FInZN1zz6IGSzU+Aex6uX5eEZA
1QVMR4BbfywNWBoISgP+33Qf5Pwhh9BO+uAWsySa0kAvG02AU3stehrDm46L+zSa7Z95C2GQ
SQHkTzlOSr4MB+/DGDx4sNif8dprr2Hq1Kk6o5EgjNnfX3yRluJ+SstvM5GamuotYzgxrTSo
NHOGMBgamSGYkQscdNrP3q7vEC2Vp+ANTKtIbKa/i4qex7KJzsl2Ry123rcQm+7/Ha7fcS3e
IENQuX0dbtmu0ZJ/P2qaCR7aun46GxMafDrHw2M5GEaGRnOpmDiD5nF4lKuB5nYCpCOxrael
AUsD5hoIsCkzJ6CmhNhe+monVfJd5e/s0LZBJCTRCipa2Wpbce0Yuk+jDZ9+mqVrIn2IaKYc
AxQzhfCy2uHDh+PEiRNieIp7FXrHcXXn68SGEp770PdE9PCeYV11oHvQ9U4M+JS9TXMLM7gz
QK4B/zxIjxvpSBVHimjMU1x47aAVwqZOzJs4J8QFkG0ArricfB/RGoOMS3AtzW8Mv/dpPDhn
KOzE2FH7AQ6968AVsnPlHPayZfYnpErUNdJD2Eg7yl+uAa6lcBB0CNpylgYsDQSggSCaswCo
GYAEwMCsnTSgFvOoDprPEJv6qM1mo5GYyHMJNE6FKB6NzgrRO+7qjB49Wvyuu+460ZNgGN67
wXs0eP6CDcvUqdeKifDs7GyxHFdPRwszfZ2RUAC5Xa54+x1UVVWIoa6KimOoqKrFJdPnUMou
bNp5EHUNdThS+jOUkGFYMJNWclEDfT019C+/eRQNdkqjSWweeTK7pkrP49jBUvyCEaZeinQy
SRO+lImyjY/h5SqyBvZT2PPoahQ+9S4BeLrU7Ck0mwEUPLIDVbTZsbz0JyiuBAZzNycIOp5U
rZClAUsDrAFuKfS/eNGMUTsZF7JR08rHh3Ab20HzGzbeWxHM/opQM6G3pIl07+yECRPEhj0e
quK5DV5NxXMY7KZPv06sqpo9ezZqamqQnp4uJsuN+ZsbDIbn+YZDW/Ppp2BnLsLvS5dh85pP
sXpTPsqcabmrNiNvYl8C7MRN37oZJYX52pBSplwS7N1jYapGPHifxrP3zeLrETF19WYsObMa
BffcxuBA5hQUbvk36kwcBxscd49mJPKfLUThynzcs3A7wU3ABDJeta0CKwg6Grz119KApYHu
owF9OxkPknPvooP3atDNfQ46pzDhL3/5Syev9jl79izuvvvuqMuoN1B8bEh5eTkaGxtx/vx5
7N27l7o/ScjLy8PkyZNpAtxMJJkgDQaHpd8MxyTeYafeBFnQ1AykqkNMDG5vQAMNJ2VkRGZj
oIPo8fCUKT17FXY88QKu/PclmDSEhanDjrzbsO/6IuygiXLp/NKRgNbT0oClAZcG4vZr3iWh
5tG3k7rkkIJnzpwRJ26wDvj3+uuve9GR+mH+vOGa3dTrbqYPdtp0TXMaCRSvbyK9iEQ6goVS
FcJhnhBn48HP+voGkT54yGAnazNjwAZCGg4ppRmsTDd52lKpETdJI0NilmSC4TOaDZNPeqn9
gPdKsG5xCWbOm4dzL+3BUV66e8t4D7p+6XhAWwFLA5YGvNuL+NWJvp3sWklppWuyDclkOGhT
H2zn6htht9vRSl2PWDlVITxvMWLECBfrIUOGCqPBq6UYTnN6YyDjXWjkkb0MPawKE6w/krQC
5Z2FvF/uxhePvIbyD86gdVkB7rt+Bkb6tDSB0rbgLA1YGuguGlDbya6UmeWw0RQCX9jXLs6f
oh1+vejC8DZ7V4rl5s3HoHt+ERj1KBheGgk3buR9seBhJHUqxk6aRT+jNCvO0oClgdA0YNaW
hEbtYsHi+edEMhwOmsbgc6hs/TIz6Oa+VrQ2i0Wj3UQP+sa8K3oEgavK3WMKHKc7QqrDjt1R
fktmSwOWBrw1kJCUoK2e6iDjQfPNNntLK1kPB9pMjsfwJhHLGGkc5JN5GxkINV31x1JWi1dP
04Bl7HtaiVr5CUUDiQmJNAFOYztkPJKo12Grb2imswrbxQUboRCMPU4sjAIbJuliwU/ysp6W
BiwNWBqILw3wCEIH/RL4YFuyHrb+/TLF8FR7Kx+EEQ9ONthd2Vgzb6MeTTzox5LB0oClAUsD
sdMA7eSj5pCX6TJPMhrJvHGDJsM/rYuTmfDY6cLiZGngotQANwLUBFyEeb8Y8xx+MfMwrZgM
p5NuyQdbY3Mr/nH8DD45Y3xPRPgsg6Ugv/KDxQsXXlYo2cORz3DpeuL3tMnii2ncvyfk1VX/
ZHX3rJ5WyNKAlwbYULDTWkRaPXWo6lMgORWDBvejuyvMznD1ohN2hKvyhk0pHAL85kjjoHW/
aOhOiQuHthtXbWw432rYDWXuc0uoSmsOH6sU1pXWZdU4xkeZRi73ajmFUm6RkyRylGQZ6fMW
OQ7xTUnNd3xLqkknyytcWYO7i8iTGy+1ddjoTg266rVDDE+lZyCzdwpOftJA92+bHcfnSSQS
oeCVoTbwkZDAiJ5RXPi81IraUxofI634L9Po6NdIlkjE+So3s7yqOJGQIdI0pNyqnDIu0rzi
kZ6a73iUTy9TJMumoSG00SQ+e4pP7GhztAijkZjVp7fYge2gU2W71nGDwr9YODM+8ps+FjJc
jDy6sX7NqgwVo9oQRfIlj0oN8ZGP8PlFlXjY4qnlFDaxi4pAJ23u0066bW1ppjvCKfPtNM6g
DcvEsya6cYMTz2q1ZLvINBDNhj1e31HtgL7uWdDRLK/ANNLSbBcX4qXQySF0ciAZDbYWXNYR
vCM8MFHMoCKhJKah/vS8OMP6Ci7h9bBWOHwNRKJMw5ciLAr66qIQi/vehSJr5L8Ozco2Xt4n
Tb74/yhWCym+/HxJn4MuxON6nkgrbRP5/lcemDK4OK+LJPfxdgYtkZFxMCMSDKwZDSve0sDF
pgFf76uvtNjpiRdrqAs2Ysc5Epy6XocddEhhB09f0M7wlF69afkt7fJLIotxSVbsJsE1VZp9
oURK0V2v7EjkxKJhaaB7aiAe3j+5Ia17ajBupOZJDOpl0L5wcXChbXz/ZDruFjjXGdvxKbb8
ssvI3R7fXwJsYOKhEsZNMXYzQXpe2fGkqtGwlDXZqlbNrnxvLYOhlkQ4/gTqYfBwf0c7GQ6a
EbfZ6BCqznae3ojml7+5yHyb1D//+U9xneuQIUM87tYwx7JSLA10vQYsA+GvDLruY0H9CBVS
0B81zp/kVrpbA2R+xSe7dv4Ube6z0cRGO1mPWL8A8ivt5MmTdMXrX2mPSAquuOIK3H777W5p
Xb6uq3wuESyPpQFLA91GA3IUQxNYaz84LtbtXPgK89dbkx/70WsjNV3yClviQdMZNqnIJOpx
dIVroaPZedPJZ5/RheWiGxR5KRx0MyFdAE4W0pu2g+4HB4zTvKGtGEsD8acBfXNh1Mx0zdvd
1brSa6ar5QmFv788+EsPhacnTgIdh87bMpJ4VoOue01sbXOgrrEZb/NxIl3geqX2EhaMvwAa
GxtoFRct5/JyYVT5hnKsmj8fc7+2DbU6uo7q3Zg7l9JW7YC/vZLl225F7uNHdBRCDzaUb0Nu
7jbUBUnCfmwH4eXhiD+BYceR3aU4clo7iDJUfkGKFyJ4A3bm5eLWbeUh4jNaAx7PzUXRkWA1
GgbLOEWNfjMSpxn3EMvSgoc6wgjwsB4fVcjDUzzGl3iaTrd9+f1afNoa24lwmYfeab1Fl7GT
LBjPaRi7MCqA7F3UlOClKs+TfN/+605jdoaxdNxKL7pYPQJO5Ibk6swEgl2zRmsWhEsOQI5/
bCrGi2ecgKyHEPgFwCYCIKkRoTErfx1yR6dHgFb3IsGfVP5+3StHkZQ2jA/OSIrRjWlxe8UX
MfEHfTt1MhLfPFGPPgP7IaNP17xs/fr1RUZGOg0d2TBz5syojTnmDAN2lf6fu+gcVfhTSY07
zD57NXY8tIK+5HPFb8VDO1HtbKVtKb1R/8ZeFK3P09LzHsKRWtmE23Fw5wbc6sRb8/g+Vw+i
Yt/jyHPG37piAw5W211LDhLqq/GHbQ85+eVh28vVnvIEEmqowDYpU+4K7GAa9gpsyJuPEsLf
s3Y+1u88plHywa+h4gDW51FvSsiah6LScnDu7BWlWLH+cZRuW+9Kc8vpQHlpkSt/uXnrsa9C
6wL5xgOqD+7Eilulnguxm4oiw5lfM1ngoHyteAj7Dux08VxRtNupazsqDx7AR+c8PwycJK3H
RauBMD44L1qdeWa8k40F/Tppr0YbDecnDqTTbZNsSWizt3lCxijUp08fsWKKh6cGDx4cFaPR
hAm4c8Ui1OwpQYWzna97uxRlyMWqRRMA59f4kSeWYntZf+QXbcGWjWvQVLYVxXurnJqgXkbl
Hnw0Ng+bNxcit6EMjzxzWKRVlD6E/K0HsSC/CEUFy/HRro1Yt4MaXRr+WrlxFyat24gntxRi
6pn9yF/6rHMoLIVwy7D1jUEo3LwZa+YBJQWPoSKoNq8OO+5diZLqSYJG/qL+2F6wFLtP9cG8
FWswhThMWLAKd3xhMPl88KPG+AcrC/HelXdh85NPomD5WOwpfgBvU/vvaGtA5aFdKH5jlJec
9mMlWFu8B5PWcP6KsGjAIWz87k6RP194jqrdWJq/FU1T12DLk5sxw14GNt90biYxNJcF9mYc
ryzDxsLdmF9Aus5fREWyCX88phmq0wcP4ePm6J2hxhOB3f1HGr6IndXrCKXweWNfW5tdXAvO
I1S2RJoAb7J3YGh6Uij0wsbhk3WnTp2KyspKvPbaaxg6dChSUrj1iKRrxtCrbyITUYI/Ha7F
2qlZKHtmD4YtL8K4lG1ORg70n74O+XOnYtb4LDTUNuNKSnnndL2W3kozIlPW4bFlc8AjPcl3
5mD/c0dRt3YcXnzmEHKWbMStXxxDKZfh4eX/i7Vby1A78xKBe+FcE2yDJmPN00/j5k86adqd
vuBFSiYKf/YNTOVP7FFrsW1PES7IzotI9/3HXrEX26m1Xb75Lnx+VC9g4Qos2H0IO184jR3L
cnFF5ia0zvoKJo1NRYPobJjws2Xi31atw2VfmYORNjuq68cR4wqFuTGerf/VWJM/GXNnjacM
1eLS0dSdq1XLzhjvgzIeFpyHx74/HzwgOfbRp/FJ7lK808osfcjCiieXW7AJC2cMIN9lWPJf
JagX99tHt/52v1U3QlVB/uFGted+mfPYvOWC1wBPXNiSkuFo58VK5OdpZ0drGwZnqi978ITD
weClthMnTsThw4eRk5ODa665Bkl0HG/kXBMcqSNx+6JhWFlyGPd+fiC2HQXu/eFEpO1vdrKx
YeiILDz3yG0orHRzznGqhdvyzLHDhMHg1LbWJvqbgqSGj/EG2ZXK7etwy3ZOcbtPBn4dRas+
wIOPF2DpVo4fhjvvfwBXXcF+biFvxDg5JmNLdg3PcKrbNaC66jwGZo8UxsYdT+VGF2ix27p6
IQR5Z2KOeDoEhxY6zphXh/nkZxuCUX1PYP38XPHFr5HJgTZvYi6nbQD1YN56FHMLSZnkxJI8
shuaM8cTgs2bLgyGBtsXIwjvHQ74lAVgrQ9ynV6g5VGjYf0NXwM912CEr5uLl0In3QvOHxOJ
CfTVRl0NG39YdNDa266ZBtcKIo0mw2fNmgXes/HCCy+ICZe0tDScP38ew4YNE8NXqampYQ1d
0fwNJs7PozGgJ/DEpsGoz1yE6fSxekI0/izHaWxamo93FuRj589nYkCqg1b0zMdurV3WBOX2
V+8yLsG1NME8/N6n8eCcobATH0ftBzj0rgOXt5/CqSnLUbr/29RzqcKrz2/Cxh8/jEnX7sDl
gk4vWsbmxzW8j6X3rMOSLbuRRz0Gsi3C8WBiar9+9DcTBTv/BzPSHXRRCnDq7Tdxpr/Ww9Eg
VQ7G/OwVO7CysASLCp7E4hnZSHWUI2/uRg1d/DXGO1ZyHzbtGYuNzz6PSUMycP71R3HbBlVh
xnhsgPHSUTSsneo0lO1o1UaYaA7FnyyM3M5/LBdRDfTsXoa2VCCiCosRsa4vF2EdaNktL7ll
R6fcsg1JwOk6+cUdI13o2IwaNYqWv84VhmHfvn3YvXu368fhc+fO6TCCDHJLNWQ6lgyrx579
lZh5702eX/b2z3CcQEYOG0grmuw4duApbOWB9hb+tvXlsjDhS5ko2/gYXq5qpGGaU9jz6GoU
PvUuWj/+I1YuvQU7DlbBljUUl186mgg5W0dfJNU0Wxq45/DyvjdR52jAu4ffpVBvJJOBsI28
GjNRj4Jf/AmnKX+N1W9i/boCPPO+c0iNIE9UvI/aBt8TJbLHMmQoWb+6apQWPiB6HJ+e94PH
9mHYIPRPt6G26mVsyN9Ps9ktIC34dGOmzwHqS/AzmmxvoDwdoUUEJSRyb8IKVRafDENM7O7z
F4HKr6lHaxCCUxU3aN3BdRc541OXvHKKDytMSLLRYYU22Og4EST3SsbxM74biMhnR1pQrUD5
4vKrrrpKrKJ67bXXUVFRgaamRnzwwQf48MMPMW7cOPTv3z9MMTIw5+5cbC88jn+ZPtJJi5qq
DBqDSh2PNatysbp4LW4ppqTMKcidkon9uzbgyF2l0C+2TabVVNLqTF29GUvOrEbBPbdpNAm3
cMu/of8QB/IXvI8f59+D7U5u89YU4SoakhLapjbaryO5vrsmFys3FeC2XRp07potmChWqY7E
d57Mx8l7CrG4jIWmNjx3FX44h/PmwOdunICS4nW4p6YIO2ZRlAm/jPE3YdGEEmxauRCbmMaE
KTSQdgiFNGn/m83meJfNzkNOyUbcc4sm2OQpZN5o0nzltpnYMd0cL2M8rc5a9QlNoq+FU2wC
BtIybPAly5Td04VhSaGFG9KlZCRAdgB5JFH6Zbr1jLQGPN/bSFOPGj2tmYka+agRluqOGoPA
CPNIVBIZDV76mfDws3/ubHe04uSJT/Cr/G8ERiECUNzDEX0cmllxegVV/jr6+OOPcPToUVRV
VeHUqVNobm7GqlWrMGbMmAhw9kOClpTxh3lGBrfKDtqt7nD6/eAxtL1BDE9lZMiJCieOoOlA
KsWT2kNyDnsdbcJ0oFd6FjJS9VRYThKadr17pwXOzk478x2SBvUAGhyB0NN421IzwGIxDcqo
8Pvl7EMvocnil6MFEDENyFaY317VHzEGESLU/Q8uFHOFEdAGn/OXlZUlRnN4Ycfrr7/uRVUu
+GCe06ZNE+mfv+YGJKekUWeDNvbRx73tupGZaGltxRkbj48bO7VaGEOEHqsZD8YXpkNkaPTo
bAwcOBBnz54VvQw2Gv3E+H3ofALG5EbT1ebTly99/QbquOF0oapIHjTVhMD9ttQsmmcxg2c5
DTmbIRjGs1FzORvlJaCse/L2oOEiZuLxoRcPOgHLYsLHig5BA2wItHfSG1kaCSVFgKvxZrgK
TpS9sgGMMpueT1582PMkRiI6+eyp6tp6muCgjRsUMHIcq1YFIxgZFwyshmNOOT09XZx8y0tw
+VJznhi3XHfUgGhNuqPgF7HMIZSZV/Mh322vhJjotacYjK7RnmcRiaOdOhOcK1rpaPSDH5/F
8dPncPvnBghIfcMvi96TjHEoKFgCFgpx/1GIulXFq6YsZ2nA0kAsNeB+/7y5yrfcF4w3Vuxi
vIej9JLKHLBMapq/eIaVMKo/dnnrGk4ddN1rB+3R6Oiw0UgQraW6afwoNNI60Vc/rBEKlEqJ
iXhibEoWm+QswzGRwGISdQ1Y5Rl1FccdAy5z+YuhcDSMQv8NHUfLn6yR/JRx/JTxkoBMk2H5
lHgyHNWnXqioMjMmzj0NsZ+PdoW3tbYgMSstBXMnjMDfj500xohSrHsuQzLwpR0uPr2TRap/
6uGssKUBSwOR14D+neT3V/4iz80/RZLHVxPin4DfXgTnmFnocx4A6e4PQobDQQum2qnHYbO3
OnDy0zo6wdW9jDE+cmhWNPr4MGtKfGTWksLSQDfTgPreqf5YZ4PaA2eToG8ZgpUkUIMQKFyw
/OMantVMGedVVbZj1WfxVlUN7rpuXGxl5hI2rWtGxa/GmSLGNg8WN0sDF6UGjN4/ny90hLVE
vLT/QdPVS85htWVhgjIn+ngJq6cRtBBBIcSWm7Fo2okhHbzBj5Rie7f6FK6/4hIM7Zduqixj
QtGK1ReVnk88KFEvkxXuWg3I17xrpbg4uJu9f2bxEdYKz1v4IcmS6GGkdGq8rDVGacxCHy9x
JZ4M+xGn2ycnJiSRsdAOmkok/dsWXncV+Pa+T2pOicx1rSJU7p5FzxbOex6k25eHlYGwNaDW
mbCJWQRC0gCXgWxiQyIQABLx0P77hyVRaIWoy3CwdGbOLM0sXtLxly7hesLTRqeOJ9Chd0m0
9UEcWPjZhQYyGq1oam5ES0vsDmEQVczDCuiLQTUaen9PKAorD5YGLA0EpgGtbeAPR39OtCsM
5PQEguOPZlemR2o3eDvdiRGqE307aqvZECfREem2D45Xic1zdefPge+2iKVjm+Hdg5DFLmuI
DLNkHKcLu6LU+FjmwuJ18WnAVekuvqzHNMeyDVCY6qJ0QQEoWgKv5kCL6G6b/iJlNFgxDXzE
TwjOQfs0+NBC1h0f+mS7ZvxldCtTKz49+2kI5MJH8ehseJDzKnVnqq6aMBhHsRn0MChOcOvR
QzXgXpOv1SGz+hKN7MeSVzTk7w40Td5nddyJikG89pQdtVUQfvrj1bZ0925HFxWbjQ8qFDrm
o0RoIrxPem+0ttrQnNYVO6/Vl08Wu3yymGq6DKvpHEdOgOlhtSTrb0/VAF+92lPzFot8yfco
XpUo5ZJyKjrhJF20D2gXog7FFR/fHpZa5q5rJOXeTgfaaMltEh1Y2LV3LwWgge5ZzAFkrAeB
WGXUgwozjrLC9Yp+zoeXYGo7yn7nz/qQ8NJU2BHtHXxHeDs6eHiK79P4yYbH+H4NnKNb8r76
1a+GzcA3AWcDw4+QSteJ78VErUFeiVaEpQFLA91RA/S6yzfedPTZ4NU3a1o43j2HaoDYHXUU
A5k7aU4jgY5E7+hoQ6ujg065ra4hK9KGmtN8TV20nbOgAikvYVhYHle1IT8jOmuSi4bLw8CW
ExpQdWapxNKAkQZ6yHvjaieM8ijjnO0GBTWD0kPyLrMX5WdHhwNJCcnaoYUOGp4aOLA/Wmmp
Ld9ZEX0nGzM9J7N4Llz5U3BcZe7yKIkXu9dMl9HSi1UG0dJs7OjGus6EmDMWU4pKz6DntSVu
iOwvVrR26mE4Olpo7rsZTXTRnK03HT3OBoMuZYqy88dANj5cG0gUGXRJpeJ7JbqgLm6Pme4u
bq1YufelAfleGb50vhBjkqa+6VJSdQFVYEI4MV3E4jOvgeUl9lDt7Q60d7bT1gw6Ip3mN8SB
hXY67jY5Jdarp1xVgLTgKs0ANBIMbADkegwI6dPjXeipelLrTY8pvBhlxEh3XE88Kk6MZPHD
RooqwUhMUaOlqPp0Ced8uucudAkeQUnMI9IK6DTQ1mrna/poaI//0pLb5sYmGquiyQ3nWlwd
fBSDsrKqLJw1QdQOGe+ndkgw6xmc7e2W+lLrgvXCB1+ERu8cU1FfOKljGdd1enZxlqIooprl
RNMJN3AyHxJJDWtQnvmWcdZTrwEHHTOlDUVpe6MS6+rrSMG0acN5IJUeIbphtTYYcdIXtD94
IxrRiXPUHUPpzgOoJX2yK388F7lFR7RAl/xl3ai/LhEiikzjty5EMdMRIq3XnT7si03XvHMs
oeCsZ08J3Itw5UCf7jKAaoILWsmoUZySbHkVDdDt4LTUNok6FolJSbA11jeKAojetar6wuGw
WqCKbF7xKq4ZjoofO7/j5Kso3robY/9tFgbQhsnhM/ORjxGxE+Ci4qTWA854fNWF+C0Kvd60
BtdsSao7H12tX2+53bK5fcb5YFwpPz91tCjogjBdx+vmYfmAtN59kJzaG3zjEt/hZ+PltrwG
12bTtopHVklad0YUoSzHgBnoCttd1AFTYEB7RSn+4xc1mDvxBIpLDgGZE7DqO7fjs9/9DCVH
65E5bCa+/9j3MHUIzenYq7HjJ49ge1ml4JEzczl+mL8QIx0V2PAfv8OMFZOwZ91GnLjxX9H4
tz8KmLXz87BqyxO45qODONg2CrMmDkFF6Qb8omoERn+0HXuOEhjx2LgpH5PYulguTA0EXZHC
5Ndd0bX3R4ztcxaE2vjkIH/OP4Q/CuGlK20GE/Jo5L1MgMZKNhUeostIRRpnlAeYkmx5jTWQ
lpaJBOph8GhUAi2/TWyhc6dsthS6xi/SqjQoNJdMvtIYSKs4GjjLJX9aTDB/HW0NqDy6C8Xl
Y1G0ZSPmDT6K4oIClE/8FrZsLsDVNWXI/+83BckjTywlg9Ef+UVbsGXjGjSVbUXx3ipKa8bx
yv0oIIPRnLsIS2fNxLIFEwTOvFV3Y8qgVNSfJqNRc0HEtTUcx9E92/HRxHxs3lyI3IYyPPLM
YZEWnT+sT/mLDoeupSrLn5+W868B5/tl9JoJFXaFHo2EMc+JEbQ0gNzDUHsZnrAGeWMATyBz
xn5TIkbIL6d4AeAd4XwSuoOe7Tz/3UZnpKemplOzbKDsgKVmRar4OsWqSYKmV4QHp8BWPnig
+AnkoGjDMkykzsQld8/DnvxeeGjZLGQR1uIlOSjb9U/UYRr6T1+H/LlTMWt8Fhpqm3Elpb9z
ut5FO2dRETYtmyjCjv5HsWlXM+b+yyyMpA7EOWRQfLIG29oETFmHx4gH9y2S78zB/ueOom7t
VMFTA4rUX9K1S/2+9RopjhadeNaA893TvYLxLLGRbKImO6uzrNX8FG2Dq75rYSN8rT0iQAN1
uGlLysYUjGNDwTGm1F1i28lC02e8mPvmU6hsiYnU7aBNGh20DjeyTlOu5yqGQDioXehIFFAr
DUldizHOFcVJffoIIeSN6G2gBh4pNF5nw9ARWXjukdtQqI1OCbicFE1mhrp++hgtQH/tbext
gsNOD7YXiuO58cyxw4TB4Og2NiKCB4ei4CKhpiiIZZGMtQacLaSTrSvkUT88AjESkCRhYYJh
bQTrzJAg5fTLDLjJu32cpgPTRDCiLQlZT28NdJDCbGQ2aA6ogwwITYZr4+wddKZI6E5fCvqw
StlXmhMuABCVol+/u7PgA/Q0Ni3Nxzufz8fO3Xuxf/9uLB9GZoFsjss5DAyrpj4XiMsTk/us
1FdCVZoa75LI8lwsGlCKX60VwbXa0VCWIpgJee5JsOOn109L0tIZRgmzV+JqKVqqmn/hVyN0
+FbQWANidS33NNjkkpITaS2VGB+M5GUfxqyNYr2KXQGKcenaP8Nx4j5y2ED0gh3HDvx/9t4G
sKriShw/SV5CAgkoqIgGhYKtKPiBUlDBLYof/4Xfr0Jb0bqILVitFAu1S1epCnapLnU3dBHX
LmBV1iLtKroLXUuxVLEKpfpToWJXqIgoggaBBEjIS/I/Z+499547d+7Xy3vJS8jAy8yc73Nm
7sydO/fjUVhMr+Oqp1WCIaVpNqmF99/dBXX2bbcGqhyDOEacszq9zvCwXG+LMNpOXF5HwG5+
lbl/2tZkp0uG9bMwXALzSQyLQr2k2lEfKEYyBRIdmwicKOgDTBRDNWX8fOki6NevLz68YcVD
fZ3JJpJlGS0J57LEuy3GLefF2po0oKSNbmKNObxaoaFlvaQrXl7Ca1Clg2DGtDGwadFMuGbc
NTD9Xz+AMcMqYPczD8Drh1OAVFCS4otayNL/YhjTpwYWzLwJntx6CIpFzLjMWouVDq5lOw+L
lYypSa/VGaw2pJMIq86Uep3hcfOW8sfV0xI6tlHmLZHXWrzSXi6zbmxGNWaaW98MZV7KdXkS
l7ys65P9lXBevMQm12VzkBApiOsSZhROz6vJYyJZ2RJp5mF1LJ/r7SWXz/EVvPzyy82f4Ff7
bpt2B3y4610VNJMjvBIhp4MS07h4QUtF1WjccowLqrtSWrWEmxS1uE9RXk6bIGn8RGLaLgdb
IWNCd3XIEPljEiyntTHSbl032c34TH1oKb9uU7brbB/Jlf5yPdv6siVP2q3LlH5QX/SOnkzN
ByPnDLdylp+s3fXjmWUynOt8vHNd5jTgimECyzq3pDaVXZ8NnAxyTKACAR2A0+fNst1jIg7e
NBZkFluTtuSwvXv3Qo8ePZSPZMeGDRt8QqR9I0aMUPjPnzUCSoq74N1TFCfcCF++/JdQXFyM
70mXF++tg0iXyAIJLjuUhOs8Tt1pF245B4MFhjlEEtm65VQpThKsMoXloE0LpnFzjonVWehu
Axenx4hpdThxEE6HMz3hdVwQD8EpSV4L4v0r8SRb2k2Uuj6dXkpjnOSxZIpgSIY8KLPNlOv+
Sz/IVKbV4YzT4UxvuWkNilY5XBbLY1pTLmXreoneOnnhY0vqU1hbpIVnWVIOlRluEwdkrg7r
WG5hWzM75VJ0gHYG6/2W4U7OchUgXHiQ3wyXcWKYowcLDCObVBwlsr2V0YcmnDAKqT9gg6Q+
/aQa1v7u99zDHHfCgsIBYWK9znAn54b3NBphVURVZtESoY/IQrWDv0Exk3B2Q3WkgF6elJ5l
BuVhuohH6otsS6FE8jE4ShfT5VMu/ZD+SzjbG+ZfFL01iLMkezAJ6ANEFaaL8SxN2s2wJHmU
rmBZfHCbKBgXdUwznZRBPDRI0d/oZIUxSo+UEy7V1JZJYiz5k/BJC/OmjFsX6vIUhozuhi2c
fvu34YH750IzPrQRlGQAgmgsuGwILNN/K7MaXqIVA555eQQmaXQPY5tWTJ2CYqbHjehMtGy8
jtfrRCdlSlkSTnQSR3VTMtHEslvzzWSnlC3LJjvaCmayK5b/msG6/3qdyLl9dBzDWaSF55o5
Jxo9mewmGkmr0+i26PSSV9cXXPfbFkxLGG0EcNhtONYdUIAgF++VFUCugV1uDZFR1RQzPe4Z
CW5DpgLVBtbYRRFONTY2woABn4PKvt73JpmcD7Jbdny9P1OTkCLVNHb7yDMuG8QUQSryHi7j
JeNhMlzSMt4E0+VE1VkW5yRT52Ec51JvFC3zyENT8jO+PeXS/ij/JS37aILpcmRdllmGP+ej
xo9hiNQbJFPSMF/ucj6SuXdQnWFhWiN8RXEsMVCKT00kh21bMF1LYid5g9om0Jc8RBTS60Ps
UZxCXfjuu9uUmZV9T4ltblAgZLBUh6EZxPrvke2ZWFSDqz8emvZSoVjwj232xoGhbq7Tuxhv
ieToP0kRhpN0pjLbQDmnKLtdOi65Z9AupH2UMvGfeaI81NtFxlUdElq7RsmTeLYhk3aTcrJX
pmOXj1+3LyWV73ZDKc8SzRDPuGFUwHYgMtQUogslMEqPAuZf20RZHA+v/KK7a6mR6D2FAwcO
gLq6Otiy+e1ICdT5ubNyHsmkZo3sN1C03tahSBKT+DGzbCd6KZ/KdODwASblRR9Q3nhIuVKO
lyq4JvmJKkwG+xEsrfUx0v4w26N8M1nO/rJcq92sY4fazmpD65ggXJKUxG6T3CT87IdJjhmW
zBdXBvVriofGzyABpqIVOYtboFxxXGJ+rqtc5zASGftzVFslia3HpDyvqH4sAl94+PBh+LdH
FuOtpbWxTA8KXBDc28SuCjpW9OZzse2rFOQ7wzmXXplgjJc4OfBY+KCoBcFZqj+XeiQ2CC5p
ZJltJFhSXimntctBtjKcc2mXCcZ4ieOYSBjTMY7rSXOTTJIRBI8jP5hXDtG6JMJF4XWeoLq/
/yrJLN6gSnH42ZQCh5z5FTSAOMikDOBBcQyCZ6Ci1VnIdvpZl6lwT+Prf/dN9WGNggLrwbU4
zsWhieWZ04bcsg4gFns+EUXFJAifFE4+J+EJouXYheF1XFSdZXKu0zM8n/IoG4PwSeHkcxKe
IFqOXRhex0XVWSbnOj3Dg3M6fuWxy8dzMEdcjJJsi/NJlSqVQEWtSoTy0fuU+gQEtpHOGhaj
THG6jnypq8WwChVGFFeEqWJ8LoFSQZE/gC032m42ty19IvlSS1igfUydgA4agZCO0kE9br9u
YVtFNlfLxhSHmwqkK1ZyCRW/IyQWcydRQATow670jXBaJafo++CFRYVQUlIK9fXZfMue23jS
Dr6ma52Z0CayhVWzmedsRXJ1ljsj0BmB8AjQgdSaIyTq86iUuu2D2jFY4hxgSMGSLcXrEonZ
GjM0MSYmR71TQCZJqMnogFW6SzbT1NichuYmnCzwNUqpwmK85bb5KBQ240eYmpqgS5cumco1
8FkTgmomp62o4DaWvLbbudIwhLAT1BmBvIyAfWx7jmtpqD7EO4SSCMuSTtK4J5Mag6eqOCQb
Yd3hxUNrVZiY9XLdQNoBQXH3rX2u4wpDrTLowT5aaRBBQyN+HKKBA+ljiQnwt5bxTMA5G2qp
vphmdZK1kwhwfzi2DuR20jg+M90rA9xukoTa0ASXNDqe6snaXnHobIEiJEKWpU2dZVMEaL+7
pKgEinGl0Yife1UP9zUDLl0KMl++mBTx5ScXJxvK6jAOxCm41J2lYykCVn9IOmgcSxHKH19j
j9K2yUEHN8FRli5Oc9Th5oLdVRw2hvsmHJtQk9dZTR4BumuqsJDWF3gXFf7DEr0+BKcN0weG
ksvXOOyOoaDczKIxnQbX2Dqrx1gEOjtC6zc4H4dJYx+XPiYdkfHQwAXbNCXB+cP2Ij3CFBuC
FFoFT+B9wXSpfKhOQLwIYAgb8aWF9OW+lBV9eiOV+62IaCnUQLIh+Bqk1XBx9id4A5x0mS9j
RVuRKwq512LZ5/oahmN7mEbGgWFMo8uVcCrr9O7lAJ0yuq7LkhyWjdx+FibIbgmXMvKlrPsp
7Q3Dsf1ME8ZHtBLPvJyzDK6H0TJNUK7LknQkV8dLXWE4V47br11Ya5ZIvzvyW2OCO/irEqHV
g390TNi2KZgYNwjOrsiyImeEzRuQcbxkDANIMwKzfMkcR5fki0Mv5WerjKMDNNP0gKEkewpp
MCrCCaOstCyBDtkQ3gEnXAi3uuQnDr0eLiWXWNlIrIdhnDOccgmjsqwznQnGuLi5c8DEZYhN
5zvKYnPmE6EpxgzjXNorYVSWdaYzwRgXN8+GDJOulsltizbnY9/kjZgQDGi977snUGLcCBdv
kGoGtSyuZpnB0CwZHawgKxiKSQEGvYk2xHECST39n7+ApY8+AX/ZtlMpCAsazXQSHz3zeYPi
Nr4Xzp5J2QTT5Zvx7qSV3D7W7M9Zt65T2iVxsuyXZkFYZhCe4SyL6blOOcOYNmnO/K5MirNX
ShI9LMcrwW27KDzxmWjYTl1uVJ35wmRKnCwHyWaZQXiGsyym5zrlDGPapDnzs0wTP+sJo8Fo
K9Ygmig9jCchJhnugG60EIFaZ1NkBLPskvIJZdJhjSPuGMISnfHFRWHcqeIdt0guJ9Kn66C6
CU48bJ/Ow/IcGpQhzFBonZfs1Y89IgyTbcKzXKXEwM94ksuyZZnxzO/LlZ0YZTS2qJA++Iqu
fevmb8CA/v19tASIEkiOW3RWHvSX6YLxtiBBwA4SSJaZxIJxl/HSRNnNMky5qSFNdBJG+qJ0
ckNxLvnDypnYEyYvLs4fc38bBcny83opGc+5F5tZLSr+JqncbmG8ZKP8meSYYGEyTfRJYZn3
C/eY0XVGtQfjOdf5ccTwgxSE4CYcwWS/ojL/rPEnKo6K2ySaJEnRWNeTyY8AUTqrp67zsFru
Xx7ikIrJHkluwkuYLDOfDpP1qNiSDKKhKbCosAivSuGm+H8+/TTujBfCBRcMZh0qj3JWCbJb
hDpvYONw9GzpceQSjUy6kzo+qi5lRZUtWZZ+qTeKryV40sM/7wHUEqlmXlePhddjZ+aKByVZ
YfKicGH4KAskbybtlimPHs8oOzPF63osf73HSTzZfh6SJeOny4nCefHaAa8LM9QDxw4Prddu
r04PYaQvxCv5fWXEy/4g8RJOWh1ZyBOWWIbkZ5iJz5FrQiLMhNdl6/Kj6gGqrMEdVxgpfAic
2qpw8o2TFG1ZaUkgj4swdwi90aXx1slFeEBd+f6SlCWdNgXNz50pxF3GkQSpN5bEdC1U79kF
e6oPQF3abWCTzdI/kq3HMggWy44IojC/dLssUZm3I5vi1WnuT0ybSS7t9upKLo3bi3MpQeoh
uF63aLPvH8kN88tsh2VNS/56dWbLL0uOVzZbafU18kf3yUzPfEFt4eLDS37fdP3h/MH6pZwo
H1hHXLog2cQfVwbr1HP6CJMVFWwLejX6zbfcBj179sKGKYIZ371dp1d1UkpG8YCWbOhIRq0b
wLoJTjZwADhIXNf5nHrtZrjlmpmw3QFYhYrBY+G+u6fDkF76N8CFn+j35qXjYWb93bD2tqGa
BHN166oqmL5gtUJatlXAt36yFCYO7QU1by0BNAWeeWEq9LDZXfstvVRn36ymaobarcvgmulr
oOrZZTC4m1fv5ofHoH3zYe3MePa5+rxyuObVbw1Qrj1M1ZJcHpTUN2S9ZXKd/okxzEZiv00x
M8GYntuN7cmGLSZ9Um7u282jDStB7day2FPMuPnceErd5rKMNccqCb8jldzSXGB5Dk1AIaw3
S1viyiM1ki9ArQLL9ice1sH8XJcyJJ2E62WaKOhJcPrkayHOE6lp374FBg06E3784/k6bXDd
blXdEGkgl6lzcScggS7cLN6ElwEhedxBWL/OQ3XGWc+8A4yaUQXfGXY8HGkohvRnb8KCmfNh
5uJhsPYfRnoMYdlsa0FBBXQv7arRmA+Yum0r1IQxdlYV3HzpIChq2A1rH5oOP511F5yz6mfQ
txht7w5gflkLnRFYathfyxZXF/vE/lL9lFGz4YcFlSquJrzH8CxVpH6vSLdtvPDoGsuMpjRT
6O3GVBwTqmeqIy4f6SLaOO0m7WEbWQ/X2Yfg3O0bwTTuGBgkn+FhMoJwmfMG267HL0h3GDzI
riA4yyKrsBXVsch9SucJbB86gJmJ5NgHtM4v65KF6ckWopF1gskkZTCc6F0498NgO5gvTk4T
R0FRSskvPOusQbD2hXWw6U//Lw5vCE1wJyCmsAAE4U08ok2ULW6QvDok/DBSfm7AGdCrdyVU
VvaGfkOuhO/cPABg7V/gAEmp3QZL77wFxowZg7/xMHfZy1CnpOO740u6Qs0fn4MHZoyHyy+/
HMZMmgGrtiouRSFtTB+hb5JUwLALhkB5aQpKyyth3Iwfw/iRw8C5oblmFzy3dK4la8wkWPry
LlsTmbEO7pw03rZjElSt3Ax4dUsl0oMve8FUBy8vvRPGjJ8LW1FdzfsbYeO2GoXZtvIBtH0V
LJs7Ce1cavmmMK3zR7aNjEuY9rh0YTKicCYdJpgux0Rjgul8sk6DQvIUfiwllpfAhmD/vDYF
08W1joxyDQuTF4ZjbZJGHvuMD8qZT7aT1Y9d2yQv00tYy8pePVK+yQ+JZ70mmDwWiU7KkvQS
zvJ8OQorwE3wwiLMcV+j8Ctf+zr8bPGj0NRkvUaEBEqhLIDhJpxFY/Ex3ktvBUbCZNmkg+UE
4Rivy9HrxE/rhA8//hjqag9AdXU17Ni8Cn6yeDsMuP6LeJmoGpZ++1ZYvqkMZsyvgn+8bRS8
9Ni9cPtTb6s4NDeXQvO238KfT58CjzxSBTeeuhmqvjMNNuz3x6n8lMHwueaDcO+1l8N3718C
q15+HXbVnwG33TsFTu9C9MX4ewn+feMJMG/hQpgxFmD5nAdhG81Q6W3ww1vnwTtn3wgLlyyB
e6cOgFUP3Q1v1rCerrjiScPGqpvh3l9she/O/x4MKsdJY89G2PDRAWVrQ+17sP7xBfDYhwNg
6jcuAr6SZYoJxUUmpiEYlymXdVUReK5zrvMR3A/z9hPutEzHspLmzK/nLCcIbsIzjPIoPklr
pncHBZbFPMF1b9yJzpy8sWR5TM91Hpzdulcaw5mPsH6YV1e22k1aInXKMtMwTK8TnBLj9Zzp
TTQuzvUvTB7Tsw6uc85wlkFwCdPLEm+SIemD8AyXsnS+qLqUoZdplYGzBk48RdaeRhe89HL0
aB1OGkEdUxfBdWshx7XwXJ6lJNUTLjkOls7y186bCms9xANg4eQhQJeUlu8GmLbkARjXD78t
MnQILKx9B6YvXgcHJg5CjiO4eLgeHpo5Tu1DDMTJ4O0xU2Hd5j0wfGRvj0ToNRx+9uwSWLNy
Jfx6zXJYsHa5wvcZNQ0W3DvevixVAfP++TYYjgM+9J0JS1dXwUFaTqQq4MvTZsEZ/9+VUJmq
g101ZyJwm+K3/myHh77/DdiyBWD2Y7+C0ZW8F0OCigXdWHjyZzNBs0zg87PIg1B+WpevViU5
BnPjQ2btZrLbBMuNzZ1Sk0WgkFYZ+I9WL7jWgBQ+5KdSUVHC14i0ozbGYR/GzF6i9jTotfI1
25+H6bMWwy9/twPu6HsUsYNhSKX1MSoKRv+LLgN4/CnYXnsbFB89DBXjLnY2rgFOhkvw7uSl
b30IoE0addW74NNUJVw5aab6peuq4a3/eQJmLVoED646H2YPIF1XwJk0zlNKFQMXIdUb+h73
Adw5bgzgHGanAZ7pYMsWC/PXvQdw0ujFRE6eJlsnjGnVCYPOYFqSmJ8GH0tUy+S1xJb85uUD
jnKZuJ4sbhx3KSlJmfl50uB6fBnsTxQH+0d0yXyUkpPbJ7mP7TJNGviQBhTxnkYTvuq2CN9g
WFQc55ZbCh42oq+9ZcO6AbY6lL0ho0gyb3RXavIS7WmceMIJUF7eA3r06AGVQ78MN+KWxhsf
WHsBAFvgY3ebAj796zvIcSmciiN6CsNS88d3nL0FgEPwLp7tn35aT58hb6+4CW76yuNAOxuU
UqW9YOj46XBzH4B3du6zgLjeME3PdduWwa3zlsOX5uBlrbVrYe3zVdAHyHJOFTBnxbMwb2wF
LJ/1I9jKmy6Mbue5dVC3Tf9oH6ETsTEfbm3iBrVbZgOy8EdZrtcJmEeOtkl080MpXZ4qwkmj
uLgYSvCbS3ixyppBSor5cke0ofGa0qJyNmRMfSJaVRYprD0bS2ApnPnFPlDzyQEoP2MUjELg
nLuWwjZ8rmLP1jVw5/z1UDH2YvuMHc/ot9NKYSs+c1ELr694EOiG2jHnVfpsO/2CCQhbDnc8
vAZ2oaza2mp4fdWDsBgXCFeMON1HLwHpI7QKAeh9cgXAgV2wct49asXx6X6eHcqhR7dyGP7t
H+O6aAvepbVOTGRSUme5Y0XAf7QRRB1XflQHcl13rs0HkA4U24Su4IkBrTLoalQqlcKH/PAP
Xa8q6erc3xMgkRoxqOFMcDoDsVcZSqKJJkBVlsG0EV6CHxCRqbgcJ4Plq2Hb9++HHyyZDZ9N
nQe3TrT2ICqGTYZHpg+3yfHiVp9h8N7S6TBugQUaM2MhjHP2FFypvYbfBgtnAdw1fz7c9IwL
HzttPnwLn9Oo24ownBNMqXzQVXD9YNwHuXUikJo+g4fhSmMTzLvpSfjFQloF2rf9lg6Cu+dN
gImz58HTX70IzhHCaNov7yIAncUOEoGAY08dUrk8rgL0tjiqcW2OS9digzoFhEUAu0FxSTFe
jSpWbw8pqDztzOY0Xug/uc+p8Pof1yFrUENRB8KEmepKRjIj0OJrB3/ramshnSpVt8v6zU3j
yqEOLzmVA95NG5GI9hA0NhZBtx7l/KhIBI+F9tiAK5vadJA9scR1ErXrCFjHHK/WrT0fe5WB
fln1lhxz9jEdeMznMnhStyznUuexLXvv3r3q8jxtG9Bvw4YNvoDIPaoRI0Yo/PnDr4ITTjgR
efDdU3hFKqUe2sDvg3fv4b9G75VInZMbV2AYpPqupyKI2kextNzZljYYnMI9kTC8ZCFafuZb
wqPLHhtS5VAeOUFFy+ykaG8R4OMI7baLcmrgycN8gkcMkjqJ7y3hTaKHaNlG62qEVUP9rnNJ
BXbS5ygCqgviJFNSivuxuMmbKijAa1WpAlx+0OjEDWnSjqzWfy/Sw+KpeOk6a3kQAdX8aEdn
O+VBY4SaQKsLNX5iU9lv99boZRuKA1OBqZ0lXmP1VCUdlYN4g+AeYRlUrMvYFqO0JQNRnSw5
iQDtZTTTIxn4a0wfhcLGRnzOmGYRvF5ldRjqHHpy9yacZnXICMI/na+z3r4j4DRy+3YjsfXk
d2v6ruuzjjKaOFRyDjqTWUhk/beJk2RSMPOZYGwI50ybnVz5qUTTn9zoyI6lx6YUeudUGq9G
NeKPhvpC+jZ4Md5ue+gQPc0QkEztqPqWqYMFyOgEt3EEuBGTtFkS2jZ2r0Oo5zYSzhhAvnEV
m8nbUt6akKYVSbj8aWinSvL45wANBZOxBjIHZNGTZLcU13ZHSBsXZPyS+t/GpsdWj3dP4cxO
K9/GdBpfJ0IPImD68IOd+De4Y3BTUli4THydqT1EoKN25lzGPg97OTaj25JuSUUhsbkaf1aO
6qRG2PQ4GmX2rEcu2z9MNsXOjZ+7Ugrjab84ujxFv0L8pkZTYzPtaRRCU7oJ6vBp4qjkhimK
shOfnxFIelDnpxe5t6rt40QWqONNmoJltb8RFABJG0Sj4B3tSJb+xA5CSIRIXpAcqUuWQ8S1
c1QhvaSQ3nKL7uJ0ga9Hxz/0VDg0y4ff/F56whMUTz9bJ6RVI+BpJU1zZ6NpAcmjKrUN/+w2
xKqxxZhMWS/bm6k5N7nH9CxE0jKO+fQ6w/MtRzvJVJ+5PkCI4SyA8yBSxBvE8g0LQVztHa5W
GjRRYGpCZ1P0eDg0FUDaBsZ3UO9wsh5fSidlNiMQ1AZB8Gzq7pSVnQhwW2Fuvm1KqKERjOkJ
LMuCzCma8AQzjISKh+EmPkdoGxbQPuu/ssGykm1uiVnsL8nicpA8ic+G7iA9bQenZzca8SWF
zXhFKt3QgK/MS3UB+pxf3ZGQy1OIp/7rhkQGipyhepwAt53jnZo7IxAdAe7hbv/mh52ieXNF
wTYFyY/CB/HhUatOkYPx0QNmGG/r4Mzeu+0XzwqmJ2lcJk5ZtuuhE7lOTzztPzXjPsbRhqNq
P6MZ76DCt9w2QzG+hIrcra+vD/GQm6djBibE8U7UMRMBfx9v+0kjd8F3Jw19sMyWzlzJZfvc
RwEIokYm/KM2ppmkA+du+0U72Uiv984wNeMqg16OniqmfQ3M0034sEYDvrQQ383UBScPc/If
TGa6TmhnBNpzBPz9JY1bxgAAQABJREFUvONPGn6fs9OCuZLrtU62T+ek4Y2NXqvF1yRlko4e
xTehp+hW20LoUloKhRToo/iUX7F9622wUNUkwehOTJ5GgA5ePoBbw8TW1tcaPnV0Hbk4tklm
LuRGtUVb6IyyqX3j8TlwvJTZhKNIAa441EeY8BoVThhNoWs6U0PQ4GCCt+8AdTzrW7ONWnNy
ylVLtWa8cuVDErkdyF+DK2GXcFRv9XVZHyBJMFtAazC+VU/2gk0vxBcVqo/1oYnNNGnQBUD6
YHhpF/vV24qXAmdyggVH4ZmuM+9YEYh7QIX1nXyOSHu1O59jmsS2oHElqN/RQ4G2/CASTb0i
89H6ABpXa1TzwQazn0X0jAai1B1UOHvgZSrc4sAPbJR04c+d5q/xZpc6oW0VAfPilI/itrKq
U2/HiQCNRVHjkd3fWtTtWsTcccId4Ekjzsz0+QxcXuBDfvT9JVxRlJZFfYBJSqNG7AyyjMix
WnbO8o7VAHT6ncUI4LjizA9UcCoxdCQcj4g8IUsMI1pIwkaxYVyXYhknYbkv0222dMMBLjjw
DipcZNTX1+FX7YrxRVT4tluVTMZKw7JveNh1R6m5s9zWEeC+oedkF8Pa2sZO/e0vAvLW2XiT
hbXKlbTxxiVPL/WweCqtHEJdt6xT2fq11UlaQ0NaTRr0jXB6Ojy19Gf/Ag34lN8nn3yiEEmi
lY3Bnr4m9Ze//AW6desGvXv3hlNPPTWJCe2CVt4W2C4MzshIegum7OwZCelkOuYiIAZ+0X1o
UkjenYSAiDgSpdLsFIjBU4mQkEM0uyFC05YrI3qzbQG+rDCFkwblhTSg8S+TMLSEl/R99NFH
8Pzzz8OqVavg1VdfzcSETp7OCHRGoF1GwBoVrVUDOsCDpJ0rOMOEf0zPuUAlKvLY7F0kO9BE
sjIntvVRxj8WxnWbhMGtnXM7FOGlqVQKP/dKf+hpQXqLYSappWeX9BQ6PXSyb9++xCudTOzN
Wx6czevQuFJsDychDF8lqRrKC6OGcyCdhc4ItCACPCq38chke6BPBGSdYxlW2FrXYQ+FC45Z
ItmOTE8lpoCWkAUspRx/WyI7i7yF+OA3LQ7oofKmdDPNFfhYOI5AdK0qaSJBlHi1YdWdJogl
jp5Cp4mHeA8dOoRv3MWvQ2Uz1W6GW8aMgTHab/yMKthcTUNyeNq8dDyMefj1cKKY2D2b18B/
v/axWneryZY6jf3b+oubYNxVP4NPHdin8PBXr4KrbnoM9iPMov8U/uWqq+C2/3wb3lp0OVz+
L68p+FtLroHLF1nlhv1vwzNP/Q4+bbB4iC/uj2zRaSWMyrKubIrpe0cg02PTHuvmdmi7YUqf
JMz2IRSHFdPIEps/ULA1KTkRoILq5yEMSVFKJsnVfppHjE4qPtf0xUXF0KWkC5TR113p8pT1
cQ18jUjCSYMPGDKYy5RTI/JkEseZrl27KnripT2NrCf7jHwUThIrnnwMHnvsSVhSNQtO37Ia
Zi7eEENdOVR0SXJ3WbDIfevnw09f3KsI9AOg/4XjMHC/he0Hbf7qrfDbGgTt/j38BWGKHmG/
RvTVw/vDKaNmw+wxvP+DNgJ9rhcg/dErsGjxv8JH0fOhkkly+Uf8XOZcwqhMSeIsSOff9hsB
GqraIlEv8iY/xMYjIhDnFZHdGo/iUSGSdKZyoFV4koY4/gWStTkC30+IX3ct7lJCr0V39zRo
0I5KcnLQaXm1wXLiThzHH388lJeXq9XOqFGjEk04ug1BdXp/7+cGnAG9eldCZWVv6DfkSvjO
zQMA1v4FDhBT7TZYeuct9mpkPMxd9rK6VESoVElXqPnjc/DADFxx0Gpl0gxYtVVxEdrmnWTz
3gLLXt6lwHXbVsKMuctg3aoqxN0Czy2fC9OfQdTqmTD+zpVQqx0Fpf3PgQHNNfDatmrFv2fz
y1DTfRgMLtgNr2y1YNXbNiFuGJxfWQo172+EjdtwVhGJdF4/fTlCamDmuEmwcpv1rpnqzavg
zkn2agvtX/n6HsXVnN4G998yF9asWwGT7JXYLVWrrJgIuZ1FjgCNXu38x660aW53fu0YCDKJ
yaJHqCAJ8eA8eHPu4WKgKfcQxqvQdEGi2kMiO6nb06fB0/S519/97nfw+9//Hh588EFlP08M
Qc4ETQYmviBaKbt79+7qjimiPemkk3IyadCz7h9+/DHU1R6A6upq2IGD6E8Wb4cB138RekA1
LP32rbB8UxnMmF8F86ZdCusfnwPfXbHVNhNXGdvXwp9PnwKPPFIFkyu3wILp34GNat44AMuI
d9dQmLdwIcy+vic8PucmWLWjDt87Xwtb1j8O8xa8DmMnXwfnfPFqmDAYRQ6eALd/bQioRyn5
aCBNpX3hMpzHfrvhfaX3zd+shcHfnAJTrquA1essW9595SVoHjwaKnH1VLMHJ43dvCxRLJA6
8XyYopQAjJ32TRh2Yimk96yBiTMXwDsDJ8P8hfNh8sD3YdGsG2DNLlyK1B2B97avh3+atwrG
zqmCqtnXw/bVC+C/tppfbMadnHNL6zH0V7bXMeR2TlzFWCYNp4k+d31Rk2xSLgMTgZfSZFmK
yNcyPaehntXAS1M0exQOHjwYzjrrLNi5c6e6zESGhw32vJKI62CYLJJBexrDhw/H5U+xunvq
6NGjcUXHpqOLS2vnTYVx13wFJk6cCFNxEMUpA2ZMHgJ129bC8t0A05Y8AOOGDoHh42fCwskD
YPvidfYZ9xGAiuvhoZnjYODAITDp/iV4rr8b1m3eg7zPw+PIe/NdN8K5ffvCRRNvgQkVACte
eNexbdoji2HmpNHQf8BwuPKCPlAxZDSMHjoQirDneBZ3BeVwAc4aNb/9M65y9sA6XFT8zfkD
4YwvXgHNazfBfrTmtdU1MOxvz8J3v1Aqx591SUpV8U+qRz+4+soLsDQArv4/OLn0SMG7a57G
g3MMPHLvJBg6aChMuvcRrAEs+w1ORJYgGDNnAUwcOQQGj74BbkT7D+IZBXVs/Ycg5+yovXV8
sj1bicYH/pFMHi8YFpUzTxgd0VBiGqvmrzMN4/M/R4+s/7FMjexnkQSx1EQTRekReFFUcvW6
exRFq207Cup5Viop7QL05hB6YSHZnnrppZfUkqMUX3nLiSYG02DPMJ44qM5l5jXlUXQ0aQ0Z
MgRee+01GDBgAJx//vmJ91hMehmGwz6Mmb0EvjPseHUHQM3252H6rMXwy9/tgDv60iQ1GIbg
JR9O/S+6DODxp2B77W1QjN9Orxh3Ma5IOJ0Ml+CKYelbH0K6hzXBLZ4+ERYzGnNcMGAi3Bi4
eKAr9wiB6tPOwKuaxW0bqLwQ9S55Fd7cXA6bcGr6Fm5ZdOkxAvcrfgQbNw8DuiF50rkn49/g
VNdAuMOQpluxaF6hb7+PGgm9CaxSbxiJs8ZG+9MpdOnuxB5dbFxaWW1XVOa1kY3Fw8D6L0mP
mbI+CHCd8ziBiEtrotNhej2O/ng01N7Zks59x51k49jgclmW6PXs2ee3Rnqu9NIfAnKusUh6
JpMkEi/h+V7u2bMXVJRX4F1TKfwqeBpS1157LdDZfc+ePY0TBTvEE4mcJGSZJxSm1/OwiaMM
X2MyevRo9czGCy+8oO6gItj+/fuhT58+6vIVTWphOngWNDWMGhhPOEHtnZBdPYZ+GW4csBie
+AD3BPoSZAt8jJebBvaiMsCnf30H/14Kp+Kgu68ELwW9/A6kpwyyT8wPwbtbAE4f0xNKcT8G
lyEwZ8WvYGQ3vD0Wz9w/futPsLfnaQBH/oioE6EbCZSJx2eCOT3RIijtdyFOFUtg9r1boOLS
2ZZp5Z+HCQNqYP49c5BoLJzb214eWCzBf20ytR++/i1cp4y0J75a+MtGVH1FA6rnlYr7gRYy
Sf2UbSyeKhRZEV0GMckxlHtCI6Ii4RQpWefwiAgyqMU568mFbMuLLEpmYxN47WjHgiqzDAeR
QFhLSDV9ssomSfESL+FZj6lXeNZr3Su6Qw/cRjhSh2ea6KjzcAZdpopKPHHIwZvKYROClCn5
JJzKffHyztVXX61krVmzRj3sRw/80Y/qn332mc7irVOroS0ysW0WzB0YcQMBzvxiH6j55ACU
nzEKRiHBnLuWwrbqA7Bn6xq4c/56qBh7sX12jjPJ9kXw4KqtUJeuhddXPAirkX7MeZWQqjwP
eWtgzkP/DXtwdD60609w56w58MT/4mREyc6sivW3ZvMbSo8Lo65ld69UJVwyDKs1BTD8UrwM
he4U4HLhwsuwbVCWa5PL7Svht1Fwdx7ef3cX2os3AFx8JdafgQUrNsIB3NN5feU/w1Moa8Io
az2kwoYUnCt5Thg9UMdMRRN8RCh0+/vjOB1suu0ztxjnzMB1m8yZZnU40yfKbaEsW/KyfAkz
lk3MHkLZ3jHi4eENqkiZQTTBcKPJsR0OlpsU47HDU7EkGUBJVeQZvetRuhFPMPGLfUX4Ylu6
iyrmaSuNx95OxBOFXG1wWaeV0WA+CaMyPS9yzjnnqLuo6Mnwbdu2weHDh+Hdd9+Fv/71r3Dm
mWeq1ZDOF1ZX9uClNtoIL8EHVGQqLu8FsHw1bPv+/fCDJbPhs6k/hlsnLlckFcMmwyPTh9vk
eHGrzzB4b+l0GLfAAo2ZsRDG0W40VMIdyPvR1Hlww/pFCtlnzDS4+8pKgK1Yxf0BmU45/0qo
+MVjcOvUo/D0yilwnNsuGGCqlMLgS3AK27QNRp6DF5QQRND+F/wNwOItcMXFAx1xsuFkubz/
xTCmz3JYMPMm2FP1LEwdMgn+dcanMH3BbFiP19CoFcdMWwiThuAFt7qUExvSQ6kEV1fWlSvZ
3rYhFollFKGZieGdebuOAB/izfQdbG5+1cYtbGzBzmITBSrP+5lwL5Fb7YW4Dh/ArjtaDync
1yhK4WvSX3755Wa6PEXvgKJN4qjEE0MYXdikwXxBcghOm/JbtmyBHTt2wMd419ORI0dg2rRp
0L9/f2b35awzSK6PwQCowyfT06lSKC+VwzATpvHJ9TpIlZbjU9sM49zCIdLIy7Ypanv3m48D
z0HER61F6N0oZ1UReWAHxk2OQ7j0MNsvhDoGOQUbSRbb0m3jFUTY3JLYCwvyqijbTjWdHhaD
tXaUDJgWgrgJdDFBcAOdaC7/fiQidffs7mpLshtelxtW9yjEHqQrCOFV2kJVmpHeNjPTeNXG
M0qniiPZq0evJZeQ3DdXJ43xPXr0UAsAkrNhwwYXaZdYPh3LI0aMUNDRV1wLx/U8QW0bpHC1
4Rv+fFIMABZMKDlQEJzq9JM0BhEKL3mZhvhOP/10OAH3IOglirTKoEmDnucIS3F0mvmpK1iN
V4rPiwSnlLMn4qcJw/mpJYQ0qwOJCnSEuuZIMmPZRGp54icvoAmN3NOZqG5MyjKBEYS6DEF1
TBQDg4zeI45O1LOauCmC5AbBExnBu4JWFyHWIDejxbJBlgSnxoVoARZF5gbE1eDQSdOC1BJc
0jnMbVogi4Iszo5hjbj5XVt7EOrrG/ClhRlMGvpkEFUPM5t4TRMH8dBbb+l38sknq7u7aGM8
SQqT7crhLpD7wLs6rZJHI/dGzGneSJI8cgIYnUnJxrMKBQ/gsfohUnKI5GzDAoJ4OzrciYnB
0TCcgTwbIDyKDGLMUAOhD2T1QZYpHeIy43RWG0+ZImF6i85bc3mJlHHqvIkrLknelII8bzsD
c29RY2MTHMUJox5P3psbE+xp5CooUYO7vBU4ygY5AcUbfGXAqafKepS27OFJqzrPo32NJCYI
k0XRYBhiNdnWhBHC5UFRRSQPTsCPhaLVWPnjKXd0rYmsVasODDIb6fC/6nruH5tYdkiWR7mE
u3L5RISxzOFS+EtMw64Qr4J51CSR6NcRDqGns9mKcEqmYmvCqVsDm3uL9u/fh58DL8N3TpWo
k/yMLk9xKOQgra84klwuipo4WF+yPKhZg4LsdFVbTRB/MivCqMkS1mLFK4zaj1NnZQLMngmQ
ffTZEJuAD2yHjo0ggBQiy2ypHiZHSHsvsLMyGAE+cQxikDoSWLwDCChImZKH4RKmRNCKApGM
d8QiIcN8PA4RFiwk/bUGbWby0ygIy1LX4DRaxknWDMrBYoIxGahJzJJ97SRRi2Fiq3LPQHdO
AeDDfXizUmMTPtzXEpX6RCFlheEkHZdzM3Gw9Lg5N6Cpe2S/gVmbY50P4GA8BY910ixZ9nBQ
xcOFdVSGo4RPJQK8k4rGx9VQXT7l7QOgfApxDFGEdZKn4kBbVjDJNMFYi8KFETAhNreRjHoA
XSZ26aySkVihCOMjRxnBHLrseHWlR/3xa4snITdU+WUN+Zhbi/B+KevttvgaERoxnOc0chPe
fJFKPY9+cZOpEUywuPLi0SXWoFzCg5VGeTXSaz5qVcsK0oI/67/ZMMcQFuAA3P4pQGYh7Q0a
FhDLF45Ge/OM7TXbL6HcqBLG3JgjOAATghD8CYreScyklW1NIDSClLSYNAWxxaGNQxMkPx48
+3Hw6aWxpbkJ757Ci3h45pFo0qBLKPLnE24ASHoqh6Wkq5MwWcE4siHcjmDe7GFaYoGX11tT
kwf1VKe3coHo8CcyJuOcvXMl2sQ6gsAslnHtMfdNtJq/7dGnRDbLRuRWp5MQFCJ+Tj1QdtAq
g2UGMiqETsXDBOeWfpOt4XIzwZItynWpTgpCONmj0JwLvLJV1IlQ0dowWZZk+V1uhiZqDHxx
oXo1elJjaWBPOrhnwpPUrnB6vVuGU7cHLHmkDirlmqoRxDXdKdo4b6bobJDDxQeD6tgOvy2W
6u2zx7sx0Urkju8g12g6dlU2MnmKEbHbWMXGgqgQcF1VEvzhgT+Ixe3DkoJ7pguzzXIBWS/R
hRdbr0GZAkm4LNu2cF+SKN1/PeJWwImDuTjPuoMZC1Qf6sPvaKTU514xZ0nvv/8+F0PzqNWC
iTkTHpOclsH8zdUyeTo3N3a4nnCsLjO6TvLUw+SkXgkXGkSRJbGVVGe0gkmEjVNymZFzpmNm
hre7nB1pd4Zn2WDRkBiS5FGxVyaBVpH8aKnW4KrT6nWpRMoUPkiSjMq2XFuko8Up2Cdr5JUN
EyhLIwL4ZkWmcQ62jGxqWyZ6dUhJcRcoKcHbbek1Im+88QY0NDTAE088AbfffruyLmglYRr8
g2jZTZ0nip74dB6WlZ3c18SksYWiSWawDI/PeHQEU2ZmhvII/8izGp+XPoCtyzZG2kSkXPex
MRJz0id9y227ZRIbNtbE6w52frtdPumfSUp7hnn9duMR1yfub87AKBgtnNWLgmKosNzRPD2O
gNQGVmaXVNW12QNVOP4j9bn0jI3KMQ5MQgW2zwG6x5njt4GG+BywLYfrLN6f042/FnEQbaa+
NdIHvjNMxfg58BS+PqQYJw26gypFQaXfF77wBfVtC5YrjWOYqQFMdEzPOfPFoSUepmf+7Oai
9ZXgoOZJotXuFQEs0u9s+aa80F1B/XwgS1MsWs1G6bbd+9k2g1jrGCYeIUZVnSMn1+0mPYpb
FsZ6WFwPyXz22yVx+WTbufh4JQ6xq83MJ9tMhNNMnEWo67fXwrg2kN1htK58Mto/Kan4OH+8
NrCbunxLpts+TCdz2WZeGyRVcFkN3GyOoRG5vZRthGdaLDoxsfkkO5dJs+uBhBLGm8gWeZrZ
Et9q8TVJmSS6664A3zvVgK+boldOpejbFVQ45ZRTPGeNcYRLB4LoZaNROQ5PkKzswMMbKTMd
uZBptkT1T+6kUq0No47MndqRwPSGrioPStU2PmZHilsgeVK3i8mzUpSRdMKUO5OdsEeokG0Q
QdoqaBUTzXit6sSNwqfj2Eg+1q0xgGMdRM1cVs4xUc3jtBEXOPfyZKtG0n1W2ipZs8JzhRSL
suxTRKcGfXTIumRlEQpy4g5J8SlDhLQI1VB/FCeMRqhvqMebqFr4nEaLLOlkThQBpxNzAfsS
dycGcVenA05O1gy3FBK1xckHtccQF+2SSwJidRVKTDsqsxO6s+wCR5brHT1nf+2G1drXEyUm
VSHBCp6GKhDz2Hge9ImM+pk1kBLSJlD8CuuUVIHlYEVROiMwITyWePmyWFMeKb/4chFbzbbb
Pts69b2/g5vWwN4n7oOGTz8UVvGk6YKivHFiiGodzQgsPuFU6D35Hqi48ApXWA5L9Q1HcU+j
DJ8K74ZvIxcb4WE6eQCyGt8ynwecoNWDCW7iD9Mrcc2479J0+AgU9ejugJvr6qAJP3ReFPqi
QYe8lQvc+7m5s6keZfNOG4lVqlifpYdj7YXaNqBJToe0QVYmbGVGBlGdYR6e9ljpMI5kOfjU
2BgbbnNbOl2eUMkD91RsAsosuDPWR3YaW46mw9Gpd9QgtcKClhZtD2zLTQoJpi5iKW8lxcFN
v4FPq74N3fBjOF1KvZ9jiGuXCoXy2zDRILz+4MdKR/OMh6H7MPpeTq4SWdIMxfhZiSK8e6qk
C26C455G4uc02DyaFHgyYVgu87r/3Q77Hn0Sjr73vlJDk8XB556H2v/6DTTi5bX8S9SVZHfK
goV8YClRVqelonuACh0SKMtEojqkR5hgJLy36qln2SVNUxtUdWfbwIS8UmloYE9XlngROw+N
dIgRko/wxCv4CSRIGKvnPh7iS5g0rYHcQZYTAx9CKnckNMOen98HZUU4YRCiCREZ/pobcXyl
vWsDP8kmHaQrt8lqkNKybrgJXox3TxVDYarYveU2TDmvKsJodBzzcM54vc7wqLzx0GE4tPYl
qN++A3pOuQEadn0Eny5aChVXjYYKfVCMEtbGeOq04viIZQ3Rq2Ww7PHYeWihTO6rlZ2UhHTu
tCIRYWVhmVKo0UqYINWo8qiafSNb80Qp24HM9Njz2kExNSXqHJkmr0wab1maxFiHOWMy1eXK
zlwCcqIZeOSJY8yy6+gnH0JJWVGLT6ijvCzBwJCu1khlXbvi3VP4nWp6jUi+7WnwAcm57ORl
XxgAx93wVajGieKTeVXQ9NkBKDnzDOh+zd9CYTF/67o1QtgyHfIgSCpJdST7j5Jj/6GDzDoU
Wig9qKfqcKq3RFVSx7NOH8cBclB3POuGtGOBsgMExSmMRuPBqtWP7ZDYaJfKLeVD0GjCoMS5
YxOvDBxAeKFs8p3Q9Yopiqix+gOorboZGndsgwL8LET32U9B6rRBUP13A10hMqSkqxVSEz4J
XoSXpZrxxYUFKdwIP3jwICR5/XgubKRbwXbt2gUfffSR+uAS6SjGieDEE0+Efv36qa9NFeEX
pyr+79Vw8Dfr4NCvnoOminI4bdZ3oPTsM0NMogi3VWfj1vXq99ZCTI9AKTn4R23JsaoInkA0
nsJJuxxxBOQQck5CHIJAie0HIf3yWC0j4kF08ErSxjXFKTCohth59SlpPpE+gEFOHoFimisn
DLK+qFdfKJ+5GA7cPhq63jhbTRjpnfjd6JjychWBI3iVp7AQvw9eUqq+E5763ve+BxUVFep7
3Ndeey3O9lYj8tk+G0Jw+mb3008/7QzsEkdlornuuuucL9yRDJbHtHp+4MABWLduHbz33ntQ
XV2tPrhEPMRLdtFX/EaOHAmVx/eE2t+thwbc0+h62ShoPHAQav/nBSj5XD/oMrA/KddE63UN
nfNqcEuTZcHYZIaRHOfuDd/1qziyIixhNOdxRLYLGhU5e06M3yJR/blduG40MpvHC3cWzo0K
EejVaV1+MtEyXZQ8E2/uYbL3qL2ImCuArldaKwxpoZo47v4PvIoyAtI734YD911H7wp0E4cC
IaSrNdJRvHuqoqgQunbrii1WAKkLLrgApkyZor4RrhvABwhPIPTZ1Y0bN6qJgJYsMhEtvaPk
mmuucSYN5pd0slxTUwPr16+HP/zhD+rzrvTMCH3DluTQZEKfen3ttdfgMG50X3lSH2h+5DFI
nXIynDDjFkjv2AmfPPCvUNjzODjxB7dDYRe85uZJWkDTtTgp7cdvgFcoHf7vfHuYs1hJQ11d
Aa7mnDe2KNmyo7VUGXlq9SXRo2ILRR5xJ5aSQH+08ClxmYiPbUcuCIOcMMFzob89yMyXRuU2
se0x9EEaT6yJhWnbJr4G09Txp6yiPwnMM8nqghNGA00Yc3HCwLP8wJRAT6CMGIhC3MugJ8rr
jxy2vhMueYIGeauxLAvp1qvzzjsPaFUi0y9/+Ut48803I1cWzENG0CtMXnnlFfj85z+vPmLe
t29foM+6kj5a1Zx11lmKZuOf/gQ9PtoDFw09B06YMA7KLjwPms45Gxr37QfcoYlso62rqmD6
gtWsGvMKuHn+Epg4tJeA5ab4ctU3YO6vP4ZpS1bB+H6l9uBeC0vHXAP1VU/Dbecc5yjmybl2
88Nwzcwu8OzaKeD/anktPEy885+GmUPxI/HErf44YhIWqF1F13UEih7JaCaV9Am1tT258At7
TvDZbdtb2rEtsDst9y29T6lmkm1l0dMFhbZuM2kVtZGnTufS3vNpYzOSN5ZHfnTD+zhh3IsT
Bo6BviSZYujx8WcAwL1vXNU04clvHT7kl4YUnc0vW7YM9u3bpyaCoIlD6qKVQFfcUafE9DSZ
JEn0FPpLL72kLkdddtllMGDAAIedBk9acdDv+OOPB3qZ4pb9+2HEDTdA2dlnKbrCrmVw3I0T
0Rl8TgPfiRKU6ratUBPG2FlVcPOlgyCV/hjWPjQdFsy6C85Z9TMYVBrEmQV43Vb4z9W7KUjw
zMo3YfzM4Y7Q4gqAervGkwVV6aAoLXNXTfIgoTI0l8Lo2bOgsV83RRvc9WzhsTKr2yv5fPBy
5+Qjguux5HVcItlW7c1LPlbb3m7Rmah/qX6tW8Udj+FMyPX8zOnuojiXjcgb3UPySE0Y9+C4
VmuYMIhAho5G81ZIRXhpigYbej16ET6zkerVq5c6y6fLQXE7FdFJWnkgyTL7QzCmZzxNGh9/
/DFUVlbCqaeeyqS+nOz7XP/+sB4vYR0tK8VJvAkfLrEeLyks7+aj1wHpI/S+lQoYdsEQKFcT
RCWMm/Fj2Fn/CpQp4jRsXrkQ5i9aDTi8A/QZBrPunQ1XDiyHum0r4bsP7Yarh3wAi5ZvQjGD
YdodX4V9//nPsHxLDVT0GQX/8OAPYHhv88yz59VfwhYYCz+Z1wNmzV4OW789HAbZ8wE9WcJN
nq7eDAt/NB9Wb9kNBadcCpO/VAcF3QeomJEN//BkDXz5gmqYt+AdmP/sP8NHf1wHcNolMLj7
Dvin7/wChl53Jiyb9+9ofwEMGDsD5s8cC9YahDRwLwsqk9PUnhJvweiv9z5foqHEuVVrP39l
LKTVxlFLEnT8clAIgkKWcURYYHIBtMLwnNgkF5F7jpgrDZMhNGEcevQeaD4YMGEQkwxfK600
6PkM2o4oKy3Dt9zisxq0YujTp49aepgciYLxJMB0PDlw3ZRLGrpMRXsluhzmoyXRYcRTrNLq
Ib5kA1b5KYNhANTAnIljYMYDS2HVy6/Drvoz4LZ7pwBeLYK6rcthJk4YQ2fMhyWPVMH1vTbB
/L9fATTVpBtqYfuWZ2DR5oFQ9ch8GHvSFlg0Zw5sHnI7PLJwDpy3ez3M/vmf2FQtr4U1j66H
PpP/DwwdfjkMxunjuVf3KBqvB9Xw71Nnwur3B8Lchx6BfxxfAo8v/yPASdbqqeFoDWxZ/zhO
GK/B2MnXwelo856Nm2DnkTQafwTe274e5s9bBWPvrYKq2dfB9tVV8Nzb0S8ms+KtX54hy9g6
vay51+6qNDG2O6PbzmCKFceLu4RjDQM4Z2JmcAhFgWkEiIssxlHICD23CPO6HXEgV6sNWnFE
/KR3NGHULrkHuv/g0Ug+lhvnMpjUkXEZb7UtxT3jBryq09CQhsL9eNnn1VdfVT9dKA0s/JMD
PdPxQG/CMQ3lEs9lylO4H/HZZ5+pzXCaOPREsxtthG/bhvct2/SF+IHzRKnXcPjZs0tg1uSx
AH9eDgvmzIKbvnI1TJq7EqpRUKrneTBj9kKYPm4ornpOgc+d3gegXF7uGgBVD0yBIQOHwje/
iTJgAsydMhoGDhoJN0zGS2ob/wIHDAald70Cj+8ugImjKhFbCV8eA7D20TVqMpKHVnrXa7Cy
tgBmPvRDuOTMgTBiwp0wf8Ip0GzNL47k2/5tMcyc9CXoJfbTC+zHU8bMWQATRw6BwV+6ASZX
FECt8xpk0uQckY4sF6QPpPLAllbKsiumPZbMA44hRu3RuZbYrIeA65z7ZAcifJRq9nG6EPHp
vCaYQQxx6qxmsraD0iUjXm2E5AVd3askNGHUVM2AHnc+imfx+JqkED4vrnWCQU2XwtUGTVbp
dAOk6A4mujS1d+9eT6B5cPcAsSLhsqzTRdXpOYyTTjpJPZ9Bk9bw4cOdfRLmpUnjxRdfVLfi
0u23mTxPUle9Cz5NVcKVk2aqX7quGt76nydg1qJF8OCq8+H+q08CeON+uHreFlaLl6i4iBeR
Kr4I/e2rT0Xdrfde8bTVALSMLDFOY1t/84wSsmDqOPipM1I9A6/sug6uoHnETkf27cQD4Wz4
Qm9LKk3Eg67AF5E9fdRefVE+Bi4eyJfArNUBHTz0O4R/TuiO77lHedikUI91Cyc7FJc5t5UT
LRbp0hTxkAQylcs2lYK7ZaL3gSQ6P8tkc2fyR4DjojoCorUu4jv5V3jJpIvUOwfWrf+aaF2R
LieoTn2VdOh6guhbGU4DfsSnKwoqusFx969QhjXsoNtqp0CPe5ZaEwZBw/jJbU6kqxUSjfON
NCig7qJi/LbGN7/5TfURJno1emsm2jgnnR988IG6U0q/hZdsIRhNaJTT3gZvviex8+0VN8Gs
Z6537kRKlfaCoeOnw83PrIandu6DrcurYMHqgTD/yWdhaO9yOLDxAfjKA7TjYKcaLiTI0+/D
L5Zvh8GT58CMUb3xdjVcVeG65vFbZ8OyNZvhyimfV5MvNUZxRS8s/xn2HCyAM+ybufZseR33
NIYoGhqhC7qfBOVqpCYbaHWg/7D3EEzDxbGY+6AjnjQwMEwA0sQh84qQHJkOGl6JmdXIjsz0
t+REKTNbc8/liYanIsIkm84xSScmhIyrxWRkdWRkUmAdJv2ZyMsej3XpKFxexR0/geJ+ZwFN
GPvnfAOOm/NzVSeu+j+/imf0IfwimKSrNRJ+IRwa8YWx9MLCUtzXKBw0aBCceeaZMHDgwNj6
TXdKmWBhAunSFD24R79LLrlEPchH9Lzyob0OkkkrkP79+0O/fv3U7bhhMk240y+YgODlcMfD
a2BX9QGora2G11c9CItx1/uKEafjPgmi+5wIPbvhsL7jZXhg9lq8PFUPh0zCYsKqX/s1bMLl
yo3jR6LdA1Vs+w0cDtfi5azdy38FO3A7glNpv2EwCitzfrQMdhyog+qtq+DuRbjqsfc0FF0m
ExcryIucejr+RIdvS7MKlB3SGFluS8vaQDeOO2ro4RBQhcpcZ5MIrggZwDkRMpIJvALoJJUx
zJWdPDdSW2QbrRJo0A/4lf/9/VD2xavVhPHZ966F1ADrbtCmQwfh0Asr4MDdNwfy+mSGrUha
5ISXmU6UaDO8Cz4RXoJXiFITvvp1nEXSuOlb73v2wsuKDY+tT5+Gpecx9uzZo1YAREO34NKd
UITjPRCdV6+TIWeffbZaQdClKrrld/fu3WoPg2gvvvhidWfV5ZdfruDd8F0s9I3apKnX8Ntg
4SyAu+bPh5usK0ZKxNhp8+Fb+JxGuuckGLB8Pky9xkIOG4b7FJuegVuXjoJlFyMp3hrrSbJe
0lXb/yDKOnh1OcoaNQvOKfd26jNGfwXg8fnwwtbDeFGLb7mthDsemQUf3Yo2fOVxpWrAYFRC
Gy6cpE6EubwpQAugBG+D41SCD3bwrbwMa9vcGn2sgRr7EI8xrWoUKqWmsEwxaPa2k4Gg44Nk
COxYmZsqLJCmANuCVWbCm0Jr85hQeQ5TE2TICqDb5RPxTd1vw2czv6Zuq61/8ffQVIPPm2Fq
eP2NaO9ECElXa6SupXg5rcfx+IxGgzqRL+jX/6zmI/ikXxpfNf7J3p2hNnz66adw7733qsmC
LhlNmzZN0S/C/QGaOOg3d+5c9XR3qCCBJL2bN2+GQ4cOAW3KP//880rOpEmT4MILL1SXYgR5
C4ppXGUcwktFRdCtRzleLpKJcHWQKi0HenC7jj6LaJclVbyyaNVE51deG+LpyncqGQscs7Fq
dfRW6u1OeFw7lA0Ej3nEdcTLURwW60YWjA2FR28SButwh5BjKgkY5mjgQsyc+aXMmKyCTLaZ
5aNA5rj45iV9oXeJd3SRKovwxatNeHIsb6s9ed17iuTj0f0lqbEsffu4vgHO/cMHRjoTkPat
6dk3kkG/DRs2+MhYPsVtxIgRCj/2mm9Cj+494RA+vtDU1Eg3MOEtONhGdLYflYiGNqTpEhJd
OqIBnhLzkkF02SlJIiNpQ5wmD8pJNhlM5eymFL7epEeASMK5z16XinIAQw7AXhtyoKANRMqD
v+1eAUETBSWaJ5yB0gJ1/lWB8YeBh28vRranLBMVc+hwrwS3FkQfl9+VlFclMj/EhcZ3tjvm
ll13A16eGuLUK+56ANLbN8ORp550YKGFED2hfAmRDXgV6iCuhugqAS0W8B0cBTgBFAPfvhkm
jyaFqVOnqltkaZAnAZTOPfdcNVlcgXf9HHec+1qMMFmMo8lHPtzXu3dvdWDT5MSzHtPmf84H
AlnaSi2al0GhOOj+63XdcBOPTtPCulLRCnpaaGa+sLuLMVPb6XEkGoLFSUwn5TJMlxtHXv7Q
0IeT4jwRThb3uPUfPYZ3u2IibrROhMNP/ocH7qlwmBCoPtLkQeam0oTHckGqED92l8YrNThp
NOJWfUFxUezmpg3zJJvmSd2gial9JtGa7dOBLFmdf3Hg4ax9D0dZah6fGDlwM1K2oY6XOC4z
Decs5xjMKQQxw7B7ZL+WBSimnpYpoYeqG+BQw0Hc98a3ceAXAwvpLqVUUSrZd19bakWH4OcD
hpyRZaq3UmuSqlhJty8WUwuIMvE/E55kJlpnzrnXk8yqtqamvsE/15bcxaq1+6LrU2uUik86
FerT2McC7p7KFpx0kK7WSIV4NagO3z5xpO4g3ux0FAqb8RJTAT4mjguQ1tDfAXT4D7BkTrWU
X2rLpiwptyXl/BuUO3t2Ju0Z1Y6E5182IxylN5kvdIm7NX99//4+OIwz7lGcNDg62czppYH1
+B2NQzhuV35/brJgZEiN3+tTnLQlUVd3CFIFeMeT+nWuNRKGlDt3Ng+YJCbE1RuXLonuTtqO
GYE4fYX7vYyACSbxQWXSR7xSL8OCePIb3uNLVwHgZxd2PXgPHN39YU6MLelzKk4Y90H3v7ky
J/J1oU24eYKf1FB7zUfxsYoUbUQX4YTRJNtN5+qsaxHggyRp0Jie+TWxsaosIxYxErVEV1wd
nXQdKwKt2WeS9uf8jzRNHGryyLGprXU7cTNuYeBOBs7teAck3XJbVGg/GGZdxMyxm+1dPHXw
TA+ojndwtJfWpK7Nt90mtbm1DsykduWOPtP+HWQR9/sguQRnmiAZyeDHXpsli09SavUJW2wi
+iRFIW5lpPDalPq4RsZHVVILOgx9Bh2dWNSx4xQSRiMDnQk1dExyfsld0MDV2l7LdmSbTDC2
y9RfJD3TBeU8MLMuptNl6Himy1Xe2vpy5UfHltvQ1IAO4seX8C7bwsIS2tMowvt98fUfCK6v
z68XUORnU+gHGlsZdgAgj/VfPWDGHMGrFtKhy9P16nhXavsosT+t4YcpnrmOUph/tDlr6bcW
+DIGuq1Y10FsOsMp5yRFMczXlxyEXWBBOjwbdWmclCcNlTQSLumP1XJ22obuks00FeNzfHSj
VFMTPs9Hkwc9Fk69sgD3NrrghzY6U1QEZAeXtEGdPSk9yZQdxcQfpEvak89l6VN798UUZ2tS
CL5MIicN6T/HhWGyzmVbH1WZzGcCI0KJfFytB2Bf2M7W09x+NHGMyOLsxKmWXo+UQSouLcE3
duBqHT+IV4TPaaSa6eE+fCo8VZT8ZYAZ6G+HLPLAkw0pXYloVGZzyJyCFCLKOl6vC9J2U+Qg
SIM7gl/sj9tPeBXhnfyZjnLyOygeAu6KtHmI107Omx+RKJCO9XBOvKaYs04TjhVmM28tPdm0
2RPkbArOe1m0Sula1hUK8EWMtDLGh8NxRxzjUUT3VHUmfwQwLHheqF1WkmRhB4AdUyJxwhtG
L+VyOSk98+Vb7glCKxjHAW/b+MlX4egrD8syslPayGW2PyhUTIe5mkBi0AWRdMKzGoGDm9bA
nsfvg4ZPM73lNqjtrTYvPuFU6D0ZPw07LNNbboPkm8PQgJ/ZLinugtvfdPcUvkaEHuyjQZEe
Gsnn1Iz3BzcdPgJFPbo7ZtJyqQkfOCnK4QsGObx09mgOEVOY4kcwG29mdnxJXmC9xGnSnVxi
9jnIxiDbguDZsiLX8oPttJqa9Ms28tO70ZF0bDfmqihxugyWwDw6Pk6dZcShjaJhW032ROmJ
wkfpzg88TRifVn0bylMF0KUs2ctbvR5wLBnqxrT+4MdKB8z8txZMHCw3Oqe7p+iuKbo01Uiv
EiEWerjPfvdgtIQ2oqj73+2w79En8V307ysLaLI4+NzzUPtfv8EXaYkv7WXZPhoA+OcV7Tai
Fx5U0zuBXg/iiwMnWdmUF0dnDJpAk5LGLoauvCKx/HMvU1Ef8vrMdUmT3AWvzOT8gQ2UXJTi
IHvCbArTF8aXoTlZYwuz26tkz8/vgzIcXLtQw8Z+lUgSWlCySQfpSp7Il2Sxpk9e0LfBm5vx
zSF0yy1tgONbqHBPPJmg5Ma2jKPx0GE4tPYlqN++A3pOuQEadn0Eny5aChVXjYYK7YBsmSad
m+MS1HEIH4QjWcwfJFeHx61H6Y0rJ4d0Ptd9gBwqb2vRbp+I7J6e45j5ch0r1tNaccq1P63l
R7ieo598CCVlOJpGNrouJyo+XnwJNh/papWEuugBP7xbSq0yUkXFJdY3aVNeo1rFGE2JHmh5
PbgMP15y3A1fhWqcKD6ZVwVNnx2AkjPPgO7X/C0UxvgWiKYqC1U+6DjPgshAEaxDbyOqMy6Q
uQ0Rur1taErOVXt9jbOCoHGF6KgFXW4qyTZ1MdlzQconqV4LsqfnGJTEq4uYrpdNvgu6XjEF
qZuhsfoDqKm6GRp3bIcC/FJp99lPQeq0M6H67waapZGuxEnvX/EENOCkQc+BN+GNU3jRjV5W
iN/jbsONcLoVbNeuXfDRRx/BkSNH8EAqUB92OvHEE6Ffv37qa1NF+Mr0iv97NRz8zTo49Kvn
oKmiHE6b9R0oPfvMeF53CCrTwc2dIBeDS4cIWps4YZ1oBrWJvx1p8nBPToP4suEK3w6cDVmZ
yvD7n6mk3PC10L6YzVc2+U5nwiA/inr1hYqZi2H/7aOh642z1YSR3rlVnlHkxt0IqXhFCueI
ArxE1aj6KE4aOIMgKOSzthEiW4Y+cOAArFu3Dt577z2orq5WX/Cja2i06qAPMZ1++ukwcuRI
qDy+J9T+bj004J5G18tGQeOBg1D7Py9Ayef6QZeB/a1TtpaZkqfc1IHDUhQ+jLcTl7sIxBk5
rCfVacJorcS63Ekqjp1oINmoSOPQR3mTDRlROtoGr165EXMF0PXKqT4j1cRx93/gVZQRkN75
Nhy47zrrSpCPEpsDN6hbIxXh11ibm3BMple+Yz9I0VeZinAqKSxoHQOkk/Rp1/Xr18Mf/vAH
9V3x888/31pV4D4LTSZ//etf4bXXXoPDuNF95Ul9oPmRxyB1yslwwoxbIL1jJ3zywL9CYc/j
4MQf3A6FOX0wkY9qU4ycowldw7Kqmuik50nKJIv163wMz4I+dxTRlbTTumqIPLWd25RyfsUJ
mZqsHfnybfiqxg0B07uQuCW0K5lpAYIzaZMs9vEAq/xgk7MmmJ9TxSkmqYFbgZwJYy5OGLiX
G5gy0sPxDJTqQxzFb5EXFeD6gvc0CvG2qdKuXeAo3r5qSkEdjfcfJJ5gXGe8SSbB6IGRN954
A1555RX4/Oc/jx8xvwhOO60vlJWV4ftNCuHw4cNw9tlnK5oNmzZBj4/2wEVDz4ETJoyDsgvP
g6ZzzobGfftx2sNZMEhJBHzP5jWwqeFcGDe0dwSlSYMbfPbZEWKfzkXFgOlrty6Da6avgapn
l8EQ91PlNroWHh5zDdTPfxpmDpVfNWT9tm11W+GWcdPhi1XPwhS/EFblyz22a3YzLq4fuvCW
8uvysl93n8yWsjP1V8qIKltzNLUh9y3OTZyyrf02W81GzxJZMoxxt9uWpLua3JLUauSXBL4y
24cIxyWTbBPMJ0wALLke/7AitDk+ExPbzQL0eDCcc8ZzPSxn2ToPwx1esaeh45iX4W6TWB4x
Pv0+rjDuxQkDx0CmZZyjhwoxVzQuj4ycC40q1eMHmFLFpfhQHz4Ijh/sS3XBQbq8vAL248fD
kyRyhhyhH5eT8B/F1cNLL72kLkdddtllMGDAACdAJIc++0q/448/Ht5//33Y8tlnMOKGG6Ds
7LOUmsKuZXDcjRNxiYbPaZRk9jT7vvXzYUF9VYxJI8wzOhDMjZFJXPyaSmH07FmQPr2bhtIP
wDTQOUkJTqJxE3dInT47dutSW7uux8ev3z1ocSBFcq63hv/2+O43ygiRvlA5g/6msyUzwGiV
EShNNRIkAbIw4a9sqBiigvo4scZp5yh+nwloMl02UrLF9Mx0avAX7jCc8waaMO7Bca3WXmHY
tKZJoznxngLFk34hBrAhIi/r0hW3vumxDOTFve/CE/DyDj3ld9GIocpRcpZ/gs+ZIHTjOaic
Sx6WI3EMa8CH9fbs2QO9evWCyspKyebRRfjP9e8PB3HWPVpWipMrfWnQsrEIN8NTxx3nHu22
FMarvHEvrKyaAWPGjFG/GVWroBrptq2cC9OfwcLqmTD+zpWg3spSuw2W3jnJpr0Flr28Cwlq
YSXC5q7ahmUKdgHUbv0lTJr0MOxKYxXqYOOKB2A8yr/88svhu4t+A/sNB2T99mfh1pnPwiHb
dsCVwdxJc+GdejfeZC/RzZi7DH6/egFcccWt8P8O1cNf//h7eP8zeyV4YCs8PPNGxF2Bvwnw
T89ugUbko9QN89/+6qcwcwLhroBbF6yGgzZOEQT8oTbln4nEE08hT4dT3UqWTyzLhTMkv3Kr
T1sxIMtk8+k+suU6nH3U4Uxv5bKtudsSjMoS542fV4Zb4zaz7HfhXPLKZKjdizV9jGU/qC7L
jPfndptz0zsEPoCDyWaBbeScZdPQKJOMVVC8JH2Sskc27TPwagNztceBMM4Jx2VpB5Vpwjj0
6D3QfBAnDCGDy/S6J9/POeYsiykOpl8Sf3TaErwSVUDvnMKT8xTebVs487tT4TB+wo/2NcKS
NITopMNhfJJWb1jCNeGERZeiTPKIvg4vmx2mO6qQNo2rEy1GJMLTuXUdW5ffAw//ugBmL3wE
Fs6ZDFtwML5r5TY48fyrYcJgZB48AW7/2hAohQOw7Nu3wvJdQ2HewoUw+/qe8Picm2DVjhQM
HAiwfsEapLDSG88tht0DB8HJeFJPk8/sxRthwuwqWDD3W7Bz5U/gB/+xxTMIk03pI/tg+5Z9
tgSyuRG27X4DjqiJxwHjx9tr4c8vPwHzFrwOYydfB6eXAuzZuAk+qKNeVA0P3zQdVm4ZqPyZ
P+NSWLtoJjz48h4loAz/7l6/ES66owqqZl8P29HX/9pa64mPq8ktkX38o3YwtYVLHV6y4q8f
suE8bY1l3ym3fLfst3zxWmeCMYUJJ2Hmvsvc/lzy+rFWvyca+mWn3UxawmDWxGDyC0eIMMbc
4yLUR8eLfAuOq2wbbgMFo8MUddMqQK0EyA77xzDOZRBowqhdgq8G+cGjDi/TBeVqMiEr7Qbg
XMrNRvloHV6FQh/wi334UlucNLrjHUqVuLlM999yig6oayjz6Dk7YB2EXizDUngp5TO87ESb
4XSrLSfipR9NKLQR/u6776p6MT6PgQ+zKzKTjayTCBz8UVrmVcP+gwB9R3wNnnykCv7+4pOh
R7/hcOUFfaBiyGgYPXQgpLc9D4/vBrj5rhvh3L594aKJt8CECoAVL7wLg8ZNQhnPwMY91Prv
weq1ANdPGIb3Kx+AF5/YBJ+78Ycw/qL+0P/CL8N9Nw+A7Y+vh322D8hgJZxgHJsYBt4NDImf
9shimPF3X4KeRaTTSuk9b8HK2gKY8dhsGD1oIJw/9jsw/+YJ0L+4QcWHIjh2zhKYOHIIDP7S
12Ey2l+Dt8kFJdKnJ469hBOZpNVppN3MJ+llmfH5kJvs0n0jO03+Sft1vF4nWpLLyaQ3Di6M
xmQ30Ufp0vGyLsus25ezW/6u5CPNBwDHifNom9jBaEqiUPcT0VBq+NEqgeEFXbs5feLojj/j
8xkzoMedj0JhV3xNkoFXh1mrFSL0J2q3WG3nZzVCilLFuHWcgmKcMEq7lNG7pwqg94m91ABt
5LCB0gjiiZ+I1tujiL8ElzonnXSSej5jw4YNMHz4cOiGD7TIRJPGiy++CPv27cN9l3IoLcXT
bkzSFknPZTkWnvn1H8PUD34Ei2bfCouIYMAYmHf3DMDFAxyht4/UW6f6aVUBWDx9IiwmOjsN
wDzVezhcjwPw06/sgsvO3wibYBjcMggH/Nq34I81gJPELPjy48xBEx7A+3i9q5d3TmACy35p
JGJcn8ioMXDxwFK1usJu6PDVf/IelgfA6SfgDISpoKAYhk68DYZSpe4ztafRvQe/3j4N9ZoO
ItOTq9c7sHnpvO0nccEYSZW/5Xj+W/ZLWvbIBNOPj6g6y+KcZOo8jONc6g2ilTTMl4s8RjfL
hVpHZpD/DkFGBerZ7rEXJoLjrOygcVycp3lwJATFFlR0g+PuX6FENuzAPYy5U6DHPUutCYOg
gt8xQTeH6uY5Q8nN5p8i+vgS3j1ViHdPNWJjp354zz/C3r374OKLLsymHkcWDaB6p6JA0h1S
ffr0gZ07d8KhQ4c8kxYHmu6woltvafKgvY2uXXFDBhM1DtM4ikRB6jy4pxZGzHwYJt6Leyjb
3oRf/GQ2zJ5+Ijy7corFYY+xpbjhDlABc1b8CkZ2S0Max+WP3/oT7O15GsJ7wFVThsHyFf8F
z+94FSrGfg/60RP05afB8O4FcOq3H4N7rzwZjjQ0Q7r6Xdj0dhrO0icMNTfVq/5A9qerdwIu
bMyp4kSg6dPy0TproHKzemp/LxymexZw/iTY68segBd7fxVmXkq9iJLscRbE9FceaBxLyiXc
xKfD6LBizToun+vSz7j+Mw/TB/lnwjMv8eh4iQuSyXBJy3Iol3CmzX2OLR/6ht3cWqD7rdel
dooP4emHwXLGYknjLwf3bFuMj4UuJTXZG+GEJDqV7PmH6hV3/ASK+50FNGHsn/MN6HHvo6pO
dPV/fhUvT1ksOp80muSQrtZIXfDOqS54wt6QboKGo/VQ+MO7vg/pRtpcDldPQedfOKWFVY1j
E+odmuopvNTUr18/9bvkkkvUg3xETs9u0ERBE0YRXkOjFUj//v0VHa80bLG+A0XXSXq2r5wO
UybMg8176qFX5UA44xTmtvKazW/AtuoDkKo8D0ZBDcx56L9hDw7wh3b9Ce6cNQee+F9cSmCq
HHUN9Nn9DCxYvRtuHD/IYsbJ5OxR5bB+/oPw8o5DUFC/B379wO3w45/jU5xaSpWVo70r4Tdb
9kLdgW3w+I8WIEVXKBZ09FFFlSyVTrw57uX9/wYubK6B2Q+shD2417N3y7PwgydegILjejJn
7NwUK72dwoSZ+IPok8gNkhEfHtGRbUEm+4Ps5PjHtYHpOSe+JPrC9GRLDumQ9pl0Et6fCGaC
+ynbFGKb6AzaZDX6o35ZMcwdsFmuEkvnbDTo2z/euOZ6+d/fD2VfvBrS72+Fz753LaQGWHeD
Nh06CIdeWAEH7/mWs9nNPKZcyW0yt4PHniz4WoKTRteyblCMl6kwgJBa+NDP1CLRW9QAAEAA
SURBVABdaOwgwRq581KjBLESDTnASdaLcKUxePBgtYKgvQra26C7qWgPg+guvvhidVcV3ZG0
e/dutcqgS1qsT5fLOvR86DerYMxrM2DmDS/ZqMEwe8lEtZtwyvlXQsXyx+HWqUfhaVx53LFk
Nnw0dR7csJ4uZBVAnzHT4O4rKy2+HufBxGEFsOCd8XBpP+syGSGGT18IN+69HeZM/YpFVzEM
5j3yZVoIOAMF+VM6cCzMGPUULJh5g7r8dfKFZyOFu4+jJhDrqhM0l7sdkoTSDcV15HjpQPiH
hd+F6bf/FG4Ypy624T7+LLh5eC8UtQenILrl1trzUXzlBUAXu4ISx1LHk72ZppbwZqozUz6y
VfYjlsM+mPCMY1qZJ6WXvEnKJj3EH2Yby6eWdY9IhobxEnXS/pCU3rUjumSyPowryOMwnng4
UzvQbalq4xpjpvctou92+UR8UzeuMHDCoNtq61/8PTQe/EwpbHj9DQ+Pak/bXVlm6/gwVTgE
Uq7rZNrMc+uVTnj7FBTj+NuIX3otGDjw3OYu+FWmGjR8BzrT2imNrzjfvHmzukS1f/9+eP75
59Wlq0mTJsGFF16YtSCk62qhDq85lZe7A77Z1zTU1uLtrSl8fqWUB2BsOefYMR8Qlny8YhXx
bY86fM9WOlWKsu0ZwmxEBJRtbKmcCDWd6A4WATrTDpsgMnXXHtkcdvMx4qDzssAHuPQluR9v
XtIXepcEH9tF+OLVJjwJVrfV2nE4ed17qvTx6P6eyMgJQJ8QqL7naBrO/cMHDg/T8yTi1IkC
6ffu3auefSM4/WgvWU8OD9LTA9eUvvb1aXjnVBfcz2iEerw8leqCu/i0M55KZfaAnK40aZ2M
pA1xmjwop8tT5DSVs5lSpeXavUpB0mlikRsSfKARfXAniiu/1CM7yIYouG5jFH0nvuNEgAe1
4L7o9ZXpg68IeOkzqZEtrCeuXZnoIR3Zl88DpeuDZVuz2q8x6Quxg8hNLLa7je9st0sFUHbd
DXh5arBdx72Oux6A9PbNcOSpJx2YU9BlGvTwxOL6Y3PjeBo/+X07dKgG75xK4weYGnClgW+5
pUtDtKSiDzG1RaJ9i1NPPdVR3bt3bzVp0MsKfc47VK1bsGKeJPCta1+0Nn9HiObppMi/CFA7
UkrSF4mW+ZAzCavSFfdPzgR77I9rTRI6PjP387hx8+KCfcWTcfXwnpfeXOtx6488iG5XXAeA
v8NP0qSBl7m0dvbVDfe88MRBgoP9kmqDfFQSFGE9Ph9XiK8PSeM+czPu0qcKcZXRcOSwc2eS
FNcWZXp1SP4kucoIsgqDTnFX/Si4MwVxJ4M7ipKxdVJ30Ahwf6BcJnM/tKBmnOTOrMw2ZEs+
yvOJzJbsMA9ZKdJQ0bk7LKZuIotF2gy7R/ZDYpmEbndQkQTecoCeeJOFFBUgyCahh6obcNKg
D/YV4OY7rjRwcxmfSGmoT/buKamy45eDgmo1stO3gsgyDpCSnDG3y5h1w1zRnaVWiAD3A0M7
qk0K2wQkI0r6a1wdG9htzjbMLIstA9hA62SNYO7KiHG5MlXagTrsWLpaCe/WgqwoPulUqP90
N3SJ9X0iXWa0fNZbj1eHSFfLU7RO2gBXrxApxNUG3lpT2Ii32+KL0ePEo+X25Z0EraOE2mei
tQKuOrbbu0OlJENyg5Ju1s95Mkmd1PkYgbhtyf1A+mDxeiRIMoVgrERIGdkuJ9FDtrF9bIe1
QUvzoDclkevljFezFJJe5+djjGdD5ffnwiG87l+Pz2o04ZgQ/cO7cx06KvMvmJdkkw7S1RqJ
7pjqUtwFKsq7w3H4XaMUPomCGxzpVntQpDWcjKtDnaSF9gW8iugsT4OkhgoIYsoQ3pq6MjSx
k01EwDf6CVw2iv7+aT53YTuy1X9YHvmQiUzklyJQilZVwTH7olBZ/kM+2KszzTT/GMGWmv3u
8aWrAOYvgV0P3gNHd38YYSfLMpGZ5RNlSZ9TccK4D5QuE2uWYU24l0EPYzekG6AEr0ype8Ma
PY8gtlwjb2DztTWuk2SGtVxL7iRIey2b1V+l0I/TG1curV2czmfJdfFKuPhjphcEGRSlTL0d
gnASTip1vgzMyBmL31ZlsdLnx/ljzzTSR4ZJoyVewqlsptepZJ0GDr8tRGGSxZxkg46Xdrk4
a2DK7QAcNvixxZwjrfVfeR3E6dprjg1Ly15u68GTRJ9GMtIHDNZMg3m8AT3Ie5KdQGGwKVnB
4IiGT4Lji2PxqlRZKX7viCaMIvpieCuk/AmD5azbMV3n3YPNDwvD0ZFAeDoz0ZOJT6eR9aT0
kjduOUxHGC6u/NamM9nMbWHGuQ1F+CiaOP6YZMThy4SGdJn6byaykvPwkcy5LsGNrYshGP6s
/wpsoiKE61eQfMWeoz+kU/t5zPBUcmhDjkRnIDZVVAxHG/CKFF2Vwl+KXtdxxeWj4LwhX/Ac
OOazFq/GODTyQKJO0hoh91oZVtOtcbsx+ybtZ0kmHA9QTGPKFR8RukeFicyB6XqsgUK32SFv
s4I5RmSO/2yYjWTfqG7mz8xPlhsmU+JkmW3Tc5apw4PqTM+yrSYnf9z+FcQbBNdlWnRemaSP
6FivV5Y3nmYa6poWXRTe3LZyItOOdqzG8d5S77XV60db1HR79HqmNpEcjkq2ZGZqSzBfSSne
LIX/SvGB5674OqQUvU+kBN9iSM9r1NJ70+3EnYeqgR2IkIGd1OqAOq+US+z5lshe10Z35UAw
9oXxbp28sBqdYQoS+wD0RoFl6HqkTC9HdI1lSkqWTzAdL/0N4mG4zsvwIBlx8NI2pg/L2Qbm
k3VZJhl6XcnFdncO31ZpN9ZG2s0DBtupKAw2meJrgkl+KlOSsi2I+zdIBlOE4W0zkdTrU5g+
Vy6VvHyMa185tS37IcsmL/R+wHXmN/EkhxXgCiHT1NBwVD38nW5qwGc1GiDVv39faLS/udCM
T4VTh/AlOlXCJHHcCRRMw0scSZN1JSiP/7D3js3Sb81PdMzxxIlNBMxhsOWyHoab4mnUwwxx
c2G71Gmym0VyLLhOuUMvgUI2gT3yBR3xenDU1wJ4jXqELL0obSUdXFdyNB26TpLl47GAuhpV
Z9uifGE9xMQ8XoHcf9haL1byM4YpHXm2bw5exJRhlDv0DBR8jGN/VF3DM86RpcWU8e7wwZba
CoU8NkHmFh/xRMREMcWhkdKTlHXZVNd8CRVnnWgGxsHES7HxqfABTJwGmNleS5r6PqmBJxxU
c7AWuuMXUpsK8O3f+OaO1Mm9T8CnwcOZwrDcWcJo2htO+sQHVJgPUTQ6nuVzHiY727gonWRr
FE1LbMqlfN1uPe5J7db5pXxZJrl63a/LGox47HQHFcUtyOnwNh/4TKTbxXDKo+2Q1PHL3naz
fDFzJx/sLI64fOGxMduUBCrtCPMzSCbd0RaEC4AnpQ8QY4FJWHZjlMa7pqj9y7uW47eXTobU
hg2b4LLRI0PNCEN6O1MYZfvAyYMu7OBM4g3L1OVZdfcSmC6T+HQenSZOnfWbaLOlwyS7NWHS
x2zEjGxnmSZ5ettRnekDY4rH8v/P3pcAaFFc+b+Z+eZkBlCUQ1BBSBRFs7IadINRFJGNJitq
gsaMmiDx9g8x4kFUUIlKNLAhKllFY4ir7CZgNpBVojGKxgN1TUAxcisCIw4wzAxzfTPzf6+q
X/fr6urj++abAQkF33TVO37v1avqqu7qi3dpdXAZOliwlBdBmw96cNAy0j5RzLKHlG1ODqBB
/6JRpa4nqaofGoOwgS9UwQPuUM7uayaQDW8thR2/vgtaP4u75ZZQw+yF17PgoP5wwHdug9IT
xoS4Fa4bohBJLsOP43XrVg5l+P4++hCT+qyPeWrEnZ+QZGflnUHypbUwupTZu/P+BpT1MeOQ
TT0knqcfPDKRO7zUYR+YlrTMtlieyozBvLCt9IVlpG4Upk2XMcytxDR5mZYlVpR/SXElnl/H
33ayvlJH+yCumRAI7tfmWYcu88Vk2vH9/dFv2wGJlfG02CcZE+Iy3ZM0c9EHNqZ0oGxUw38k
ntsBLmA7UwL6yu4qzzJ0jyaMup9dDd1TeVBcGv62W79bmRlt2rVV2YDrH4qYOPwWOlIqwY/f
5eUXQktrMzTirbf5Lfh6XTdKCZBlB+POx9sE6nu1CO/EYU7a6mmjmfo2GRvN1MtFWbaXxIuy
H8WTGLnId74t+9laErs2GRstPg48DDmS1tEow9Ep3mhWEsnqZ49pmEGuPdXQP2GEaRC9q+NB
A7f2lC2z31Femrwdv7oLSgtwwiAs8TGmJPm8hPKETTbIVlekNF4Ih7ZmvJ7RAg2NDfrdU394
9gVY8F8L4V/P+6byIazjhNFJKVteV1Q6qY2oOjBGnEwYP4zOuOY2St7kRZVNnrQjeTJPMrIs
8yYvDI/ppq6pz5May3GZ9ZNuWT9MPlt+nJ5pzy7vDEbuiEnl4MBr6ppl0xaVpYzMmzxbmWiU
TL0gTZ79EJfOPPx14jJxbcmtujsZaH19xNqRYdpmLQmN7SeRTS6T3vYJFJUWWGMaiYIh4CjI
XJhOEbpPtroi0aRB39EowbMNeiN6fil+gKm8W3fokcUnQ3PlsK3TSuy23fiFq1deh9bt+gtX
xGur2gaNb74DbfjZ065JndPJusb3bK10XZ1p0IkbeLKtxZ7VkzGkvCyTZ0zj7Z71Nmhd+ss+
esNbfLvxhEPIrCcxic64lOfENFOW+Z2zZatZoyc8W+Azj9LKW6DXr9aoX89ZL0LBYYPVGUoe
fl61x92/V3SWtW4D/Slrz0MVC/BN6PROrPyCfPzkK17TKMBX3tKHNejdImHJHNSb8Y249LEk
2lIqKsaXWeH3L2ibadpW9SmsXf13oIstvXv3gb7i2xqM1bZjJ+x88FEoPnE4dJ9YCfh4ItQ8
8ito27YNio6Ygp9BjfsaHyPZttRNuDOH8W30KFocJukmkYmy0dk88i9ZMvtHMi0txbo0+Oij
0ai2yARZykbVJVf2bO0ZZVf6J/M2HMnPTZ7jHo2GvnAVjDCxPk/0XI7GIy4Dxkv6JTo/Ltl6
5vcTS0asAnyHUHrpLVB25gRdQuMFvQ6FismPwM7rR0HZJVMhddhQSH+0KgIvZx6HuajoNK4X
F5fg83yFUFxUDHi5Jo/ecZso0Yur1q1bC1vxc4X1+NnSFvySEyV6MLAbfpGu3yGHwKBBR+CM
lPy1JFVbN8Oflj6rJpwjhx4NXz/vgoAveXghpvCw/rD7N7/DyOZDOz6E2LjkWSj7Ni6nFRcG
5DMjRLVwNo1COlGY7F0SGZbtqm1S33PvT/JBJ3PbzkqKbpXIsHN7s1DyeJAN7+WWrO/4asK6
VWCGS8CMoeuykvviqnQog/b0f2My9/ucWbv5dZO7l61emAUDD4sGRSlmcxDTjm+gTfoqv7Ix
zoRBbe68GFVNHLf9GoqOOgknjPeh5s4LQ/Ha8V1Q4f0lrO6Z0ykO9DXTInyOr7CoEF9YiDMG
fVOjoDl6oKcJY+WKv8GWzZvVAx50ZtG3b1+g15Bs374davD73nV49kGTybBjj0s8cTTh2cru
+nrYuWNH6PJEwQE9oftVE6CtZhfU/+w/1PtPys49Gyoqx0M++hGVWhvTUGD7Hjc+pIJvUQE8
0YpIGC01GpCIbWfmrkY8zkfARbLQH1ppE/7QaWHuEvlnqwNbYL6tHp3tG/vQGVtRH2v1Rb1Z
VO3AjrCeDWId89bs/aKR3ccnanXOJxEssMPEkfpMl7Sgtp2Cuvq/YgcHThtmEnukx3J2y4pK
IgETAUIEQBzL7wO1j0zB+hKXlk7RrbBG9gFgISt3PSV3wpiOE0b9bonuz3sqfnqOS3RSQeN9
I14K2FZVBam0ehocZ8eYBl29+kM1YdAy1rBhw+Dwww9XS1p0etqA1xzeXL5cLVnRpFJSWgpf
PPKoRK4X46lPGy6PEQ5NHpS3LpXRGQY+hdjeind7YbBofQ1vGo620bgGbjv3KoDvPQw//tYQ
Tza9BqafcxU0XfkADJ57AzTd8xu4+njbFwOppwC89/g4+FHTj2DRlcMRw2ZT0rJryQ//60a4
6bGVno8q1w8uvPPHMP7LAwx6NsU4vyRf5gHsvlXAOTfMhAlnirhm41ZWOhRvv492GL2z23mS
inj6v3NU7fGSWgr6Q5pBqoccz42XDYtBGN2PGCx5cVDeKZgwLF0/P4aMlo3vl/ZHR9v2JMLs
ehLZ5QhX+xY9YbD/JE+3VnM5xipf04gRi2KnN+IZxh04YeC4GpnIVhckGs+79+wB/UoOwROH
d/U3wpta8NoEDtZhqa52F2z55BM1oB9zzDEwcOBAnyhdj+jVqxfU4VkGDfqbUfYQXKoqr+ju
k7MV6EK8Xs9uh4PxmoYtte2sgV1zH4eWd/8G5dd+X138blr8HNQ9+Rsor/wW5OOpkzWVDIFv
nAFw33+/BDU4afC0sHvVS/AuVMBNpxwNB/a8EVoO62ZV9zp1OZQXl6GM2XG4A8ptCFQcuaUB
p/Oz4b45F0E5vt8F0rXw+n/dA/NvvxuOf2YufLEjl23ibMfxLb6t+N9/h7kPTIEvfXkhnMCB
jcPJCZ/agOIdn3hQUNJxKsi3ieiDy+Q2fX3E7C4+l23WfAKiYNo3y0I066w3wSrPkhxVsxu8
NW1b6TH11sZNpByWvXpKUK+66LTrt/RV5qWmP9+OV4xpiSrzpP1q3oATxu3job0uZsJAA2Sr
KxJdu95RvR0K+xRC/wGH4nMauExDl8ZpmSgsffrpp4pP3++mMwxb4usbxCMj2/AidZLU44AD
1PWQArwOctLIU9QEYuq14xlIy5r1UPpvuCQ14TvQc+JlUDz2DGh+/wMA8ZJFU4/Kx339EoDa
p+HtrVhPJ/3t2acBjhgPx/VqhPXL/wybdug7sNb98WG4cuyZMG7sGKi8+j546xNNLyzqBnXL
n4OHfnQJ8pB/2XT4azXh5cG6Z+6DW3/2a3joBtKTPIzDmkUw+YZF4DZ/4yq4D3U/1LDsjrMl
qV4woG8fOKT/ADjk8KFwHi6/AayFTWSrcRMsuOtKbQPtTL5rAWwmF6rfgFu/ORleF/V7a+5k
mP5feAENP8743jOznTqRb7fCn9bo989ov+c7fo9B3p1Yp7CXmmnfBgvfzvrmeYhfi0uVuMG0
/YMl6IeOQeXVs534RPPIh/ueXIL1wrheNg9qIvzVsZwLix+/VbXPOKzz4ldfgfk3nKdiUolx
fWurDCzt+c5EELpvESPs52pTJrNEprV5paeyopwMjEFMRT248AXoIJbU43xQyk/xbKjB0xtB
/WJuyZMPkoRNHw7r8JY1pTzRQhuLFbLcOnYM8+SiXnYy7ZrlhGb5TCPJ1oBswTOM+sduh/Zd
eACZRJ9kuiDtrNkBm7dsgnVr10BNTQ3k02xFD/jtrg1/mVXtrl3qOgZdw7B11saGBtiFMpSI
TxMI6SRJ3bt3h76H9Fd6B/fubcXPw5dl9bh6AvSYUAl0fSMf35fV4/vfhYpvf4uu0ESaKTtq
FJyEEs+/vkHL4dLU/7wAcNK3TgM6d/j0zeWwqQHfE//JErjhgYVwHC65/PvP74Z/3vYCzJjw
nzjgUy8rBVi3BDYN/g7cN/tuOLX+Fbj/ybcVXrp+Paz6w69g07BbgryG7bDhve3arpaG9Vv/
CmguJOEH3F1OI/z15Vex1A/69EzBX//ju/D0qwfCD37yMDxwzyRoePVReGTpBpxnBsKA2pWw
4OXVWhPrt/CZlTDgC72h+YOn4Edzl8Bx19+HdfopnNdrOcy5ZYGaxLTf89Hvqej3Xb46uS64
GYxU7Sp46c034HUcqF//8xK474af4MR7CQztBdC69UWYMGk2wNduVDE4DZbAtIt/Dp+ifhSP
fHh9/mx4estgqLzsX6Awyt90HcZyIcxbORju/vl9cObBK2HeXdNh1bDr4IHZd8Cwra/AjPlv
uR5Ts6ndPnTfD2M4g4uLRHJhsizEOrilLCam6FJH/7J9Dc4lO2o0N6jjOazH+CT6JCPkMOug
CHjmm1sWsUWIZVmGt0F05kRv2YbQRxN6otBbrx5+mXjcEAkcyNXZBp1xxPwkQgte9K579Hbo
ftNjjl48jppYJEgn5dvwEkZTQz3sqtkJ2z77FFJt7Thg4sXsZnw8PC7ZJgzSqcEL1LQ0xYlm
blqmSpLodq5//vII2Ih3ZS1//TXo3acvXqEv8qnmdyuDklO/4qMVHNIH6BefBsDYcytg2pO4
RHXuECjEpalVOBDffSLpej7jQa5KtTt2Q+rLJ8DVjz4OZ27Bm7OI2lwNcMKNcNd3xwDdLpD6
5mB46b9XQs31I5CHR+GKdzry2n08vKnMksImORx98YzosrF4FiTSwHPvhqO6peGTk26EH4wZ
Aacc1QN2VzcAXTH6oKoW/w6Esd8bDH987C+4BDcUStdQ/U6EK4/tBQWf/RNcefMJMPq0oXim
Ug0DD++HZyZObJvxaEb5PSpQp+BqE06agBPO7cuFZ5itqIMa7DZVLzyOhdFw+be+Cn0xd8EP
robF1z4Er6y5Eoa9EcFTaGfDLx6aBL0x34pnS6H+KlmcMGZMgGNwqW7AZefAH28vgpu+O0ot
O36zcjC8/szf8WxlpLsMKcc1pe7+CRucSCCK5wIEMrQUpgZdVnfGIDEU6ZGV+QEESSCtCEE0
FMF1dH2WJbjICxkFGI0qFHUWxVW9seTX9JcCepYpJigjKXF4Upbzom5MUluJRTI2OSnjU3YK
EXycKJIM5nnl3pI4nWHUzZ4MPX/8G8grxSV9wkiSksolwYqQoW+Yt+P42JJqgyK8rpyiV9ym
081Go/sRivE5CLo4zWcTkktnGevWr5MkoKUm0kma6FbbocOOhb++8zYMPGIwHPdPxye++yqJ
jaH/WgnwzEOwquZSKKWlKRwsj1Jt5nWagsPPgruvXA33zp0O1zxOqP3gvJtvh2NwdKaj//LB
/dTgSpx0Cy3X4O1n+DeKZ++QhGBLOIjjwDt19vnQHVFb8LvtpQceBkf010N4X9wunHEB/FSE
eqAz/h9xxniAx36s6lexdAnAGTfBYXTj1UE4FP/tXrjg3pWeQRrVcUfRfve11MnWYXHSrLgE
nvzvSnV2RgjNW9+Amy77Ecx99ky4DJfV8FwObjj/eWK5qb6BljzDeS044Zafe4aaMEipINRf
4qLHFSfCIKdbFXavQFq7agPi4rky/tVtouLuVoMzPDhwmbRylQiT8TVmkOJIoJjywOeGX9cc
gj0vfUoeOZCTeEl1ksqxMWmDabS14dhorGPjMbaNx3pRW9Y3ZbLFM3EiynSsHLqSoPXyKrpB
z3sWqEILXcO4cwL0vOMxPWFQ/GL0XevJjstd8WwzdGsvzU8FeK2mNb8NzzRa03hZoAlK8bW3
YenAA3rBJ0UfA13b2Im31vbE5SJKtAz19w8/hOpqHFScRGcZ9NwG6SRNdHX+K6eOwuc/NsOy
F19QZylE24W2+vTtB/3wgT+ahMLOdOLsFB3+L3AmPATPLf4twAsAZ97zz+5gqXXzoLWmCkpP
nAi/HjcZ6qs3wOu/+3eYc8+dcNwJv9J3wYZf8gFwebKzYp5GZuAlJ7RR/TFUhTqLg17FIXDc
UUNw6DNTFTw04Ufwwbm3wryfngIHlqRh4WVfh6X4ShiVep0IF+Jk8Nxzz0GPP9TChT8/RpE/
XHAjzP3DYJj2y0Xwpb7lUPPmfXDZT1gJRZqkvxoq6d+ivl+CU9Dmoq27oKUY2/+Iy+GXD42H
UrrFGarh/5athkOO6AE73ori+a1F+4u9tjZTf+UgIfN+u7ko0VmGe7ZBgFj23XAjy5GuRDIz
dDUKS8YySs5m0tMlTS4FUYgjqL6ioLsIZIvpvCWamdgi0UlOlp2iT91XICVMQoezNjEtnPiv
XpKKFq/Apd3CgUcDTRg7p30Xek57HFJYpqo0vfcaLk9F6zOXbHVFwqtoQI9c0I9SfmNDozod
KsO7mMLSQb0Phl4HHaSua7z11luwYcMGqNpaBW+//TZ8/PHHAbWDDj4YDu6DR7kZpP6HHgqn
jxmrJoY/P78U/viHxbDU+b2I5R34HEfyxL2ANfrA6O8Ng3fnP4p3TZ0IY3Hpxks68E0f/R5u
mDAOFry5AVLd+8KQQYejiFi+8hQwZzaWLJNt+uFSFb4KAOC38MKKKmiuWQP/OQPX/fFYPerp
C2eVDOVEatwOG7HYr+9BUAKN8OGfH4f5W5HQREfXlMph1GWj4d3HZsNLcDaMGqIPAOg9Y9C3
NxxQkYLtG1+B2bfjmUC3lpBaUR1kPQiXE/aN2s2weuMGWLdmjfote/I+5cM5p30RvnDK2XjN
51F48o+rcO0uDWuX/RJmPDBdXaiP4jE6b+3+Njv+mm1KWjYao4XVhfm53hr22DUZVpl3zdsE
XaYlw/IWlooH8a2GhILEMPwWUvas1LVLaKopR0MPp0xtsh4heCiaKsoBdlgchI4FMWiD7SfY
0rhKg37Ir/zGe6D0y2PVhLHjB9+C1GCcLEi8Hp9Be2EB1Nw2MVQ3gJn0jERZ6MiffJww2vAy
Bn6ECU8UUvTARhE+Ip6XCn8unJamvnjkkeo5DHqA77333sPP/6XcJ8LZHTrLKMeHQEjW+qwF
C1q2JH8MPhRID7S9hdc2NuCV+gZc+lqP2424/PUFfO7jwAMPtGgGSb4jPoc9+KvfgHJ8DqLb
186FI8SoTUf1NLaWHVsJN4z7EH56+0R4yunTZ17/UxiG4/5aw0SqEIk0H2DyLltopVQhrv93
0/miIWfDlV9ZAHNvrIT5KNvnhGNwcKVlqGBKFYZP2lAyFK66cjTcNPcHcPFc1MVlmlNPqICX
8O6jv1YuhC+hL71PPBMG4hJRaeVZ7nLPF07/Dgxc8BP4f+cvVAb/6YTBAG8thBseHwm3uS6w
32jfqZPLcjKpQor78zDtCrn8RM9p/AzGH0UT1Hhc2tsAP3rgevjjA1rpnBse1rfi9gjnfYii
3cSbZzx/FyGnHTx/T4FfnIykCo3t/pVlil83PkdzGtAV7MIMjUdsnrcB8ybDLAcUkCAHOmlE
0m16Jk3KZ2rXwXIggkgmHpdREv/rEtMISyKwn/E02r/NpFAltNsIpqRRtmD5JcIEfMZQheRw
7R/JUWcA3XApuXn9+7Bj8jfVbbVNL/0Z2mp3Kv2Wd951TJvYDtnYkK2uSPSJ14I23Lfw9U1t
WMe8444/rZ0G6lb8/uuy1/4U6UN9XS2sev99qP7sM3WbGj+UR8tG9KOzkaFHH4230Mq9ORIy
wKSJ5xM8e1m1cgV8vHEDfFq1VU0e37vyGjh80KCAfG4IomOkG2F3UxqK8aMjdGFbJ+TrPoFF
QVNMLjuigU0eNNfXQbqgGD9iImargFwCgvINJ7hutLCPq/j1aScfpUtyjZAqptcAaF9A5eP8
jsIM4Tmx07YMmSieT7TV8bcb+ov9FG+31v76hFR7qCZxq+FmDMGuLIp+5PYXm332NVJIKApc
t/8RW9KFuMqyDUmX8ja+lJV5Ty9+wJa4fj09yNn50lpY3mabZP2Dp8QPRfIY6CJ56cfw2DrH
mF59PDoDEKUd1p16GPShjhuSCo4cDG34Gqb2XbxKgIsBL65H6TzYOmqQo8X2QkAcchXe9XrE
Sx9FCwluw/ZtQI9N8Hj9+uuvC67O8iUAGodPOukkRfzS8NOhDC9f0IlCK55x4ApKOQYsDYVt
4WcajEyTwfATToTteA1j8yeboB53aDJShu+G6tevP04avTp8AZvwBhx2GByIDwt+hs960FkG
XWyn5zm6JKVKoCzQ5tiIvgVqs/NEe1aEMcavr0cLJeH6fEvhhBFw1IJCcny9qh2K8EFM6tyd
knz+GRaieEqUYkp+FQh/8dK28tfAcvZTn5ohsseLkSGO6z8Gn4s+TCZSTYmBZSb55DgSzGR5
piffhg3adgSy5/jl5IJyHt/lhVRDes+yqppuXd0Msy1bCwqqRWtKrswzvAFAIjYxR7z1A2/d
ovTCi3F56lgGgopb74H02hXQ8PSTLi0yE2EnUi9DJq0C0YttC1K0roLfCC/CO53y8UVUSW65
JVsEQNcs6NeZiZ4yPwx/fdT7rdL4Ilu67TPDRL3cDaybcUCoA5k0YhFNdi7OsyyXWZa2YYll
WTdMbj/d3hYUF4qh1yb2gWsvjC+6za3Prau89LnqK+i6spJkybyDynHwjpBRKHBgw4o2UPYq
bqsrwghSWqGzCcXwFRxRoqF2UFhCeXlHnAjZ2uSjZQ+0IzmbFxF4bSif8EJ2z6tm+IDKx1yI
5Quh4T+TTRr4tESXpHy8w7YAX4lOV6Xa8Sq9+txrPn4FSj0Z3iUuZGYkk1t3/chOY9PG1pdN
oivn6BGYu2f6kf0lV9FPphAjy9upDfb+YtYRUDHF2KqWsrZt1tA5UHRGPdzQGK58dFBVHv8E
+4SWcrtboE5M8NDsGNq2vd8xRiZV1H3YpqHQvD+GCPtJWxKy2WYZR5VFHWnJ9WmH2nRw9vQm
rLoWv7aMHGihZkDyBSYDvQxF87EX0122eThPFBTgW25xEsGZET9PiG+63acS97qEnUyJ4x/f
zhjQZVCKFDFlWUYvfGeTUvvzcRGQewVegMPRUFLitDuHT22ewIuwroHaalAn5/jMwJD1DfrK
nLQZb9vXh8lOEn+VnPwT3oeVB64bhvPKFjFNOmHbaJqsOPhH+Y7qLjypfY5SQe/+0PTZFiiO
e5lqB+vUhLfbkq2uSAVFuBqFK1I0aRTiElWquKQY3yWSD63pgq6w30U2sMOjJb3zRHU/JeWd
UISKqi4tfDcFDb5T1FKmrIDZnw2JgC1mvqCqUcWTIp5XCgE1yKaOg2/FkbJxdlCWxRnS8I7I
ioV/GE2IKj954nDleIIxatE5RbRqOuQYUv6y0wHjNkYIkKPLE2hwomNwGybz4rd0QTcqcXzd
RkPxaI0oNHyedtIdUH3LRLyDCr9yF3+ZOBrMwqUDpxZc/qrHZaKDJ0+zSOSelJ9foB7YTuGE
Qdc2cKWqAB9ATOMA25FQ5d7RjiLGTxhkQdc5WHWOBXd4KnM+3jOSVAgME6+yXyIqAjSyYAq2
U5RSFM9tIUcoqm2ZZ+qY+CyHdNHuIusqMI00IlEFJE8i4Roa1ZNjK67ZhBk0qv/75F00NyPZ
VqIUCN19lGZAPUDwY7klGT2ZdwW6PNPt1LMA7nkEts26A9JbPsm5fZo0UnjT0cGTp0PZV8fk
HN8GWFiM31vCyYL6Bd1+m2rBJ6ro3ttm5yt8NqXc0ahhKSXtFFo68782fGk7qoPZdKUHkk95
xnVksOgNblJWYuzPJ4+Ac9YoFaKaT8qF5mW7cPtJmk0xji90hH9WdIZymCxDCMxiNFX2EX0F
R8wzmOxgidHNbXBJyrXmZoRJypp0hhSVElnFdVVUxi2xZoZbie7FISkIWc9z/yTVipajiUNN
HtFiWXHlRf6uOtDHb4JjkPLwwT59coEfYcJnkHH9rRXfP9W5STZu51rKPTr7HtPBWUw5ECOb
eyf3QUQ9iKlIcjgxxirMTqw7NkjGhczXoHHCHp999SheLoLnHWx44l4uTNH0MUzOQwrNIZRV
20oMRUGGnuhDJVw8NxMq6mdQXVnH6Rtc9AtmVCIINXEI9IwA9nFhelsJvg4dI0/XFemFhZih
txi24NXxzkuyY+eglQOOys4UYFoIpg9m2VSx8b06qSUBVFFeuKKeT/LowETel8q5O/JxYosb
FU43pv5oRQ+yftnwUgi4TyGJjE8htkB9Jjzl3l64LeZwsJ0y+xfnCsmZ11tYl6HFtuOTvDKo
EHPT/tq5uGqKKoRmudq5wAo1sgcYBdhZ6UJ4Id45lY95dSG8CR8Pb8dXmRe1dtbZBoeTapzr
kCbBZplc2kZMCesUbTvF/kkjaU/ngGJonaxvYHBirHqRasqw9iTlMF4mvoRh2PCZRlsnYVaU
mOouX3IdmWHrO8xzDkm8ospJ9DBfDRVrkXEIw8lLkk2H+cSTpg11VlUi3h8mJ9yGGbOry/0t
dwcydluSyu3p67NSIAf5bOtGn7/INuHHuKGiWwXeYVuM317CaxqlBxwMtR+vUy+kou91d07i
Rpe9q6OWGFPiJMUn3aSyEp/ypl3CMZdR/NiyoU20fancsR1UxFVkVXw4nA6dNuEDLCuzUiYR
Zl3SCdNnmRg+irGk6YHnu5bgwUZZDR1xwtAYPcwf5odtGdfUZ7pFz2RJVeRJtmJ5fwwwlpQA
JEJ0prEM0ZlGeTN5OnJ/61ifNG3Elz0v4mWzkehI3eQ3jzKx3dzcDE34jsICvIsqjU8Upr54
1nn45bdqqKv+DNtKN5BspkzA42Xjkb0dKgrNwaGN24/cTJRiB3nSf88ehc0rkQmfYz6bXd2J
fcY7oSA7cfbwGC8OLQWSg2mEkUWytxOnyYZtchlaRyh31UbBSmzG0rTQecLnBuuzro/ZgQLj
MkQCfFIhMVPVIRNSsv1YAph22YBpjOWkrrJIf/Z4Mr1K4hDXNInsnpAh/+jlsc1NzepNt6mi
8mIoKDkIr3TQScieT3oARk9C9yThpdtCbgYrQHxZ5jqxno3HMnFbqct4WkdZddluJg7Q4Osz
FoMYWqQJKMmgzTswy0o9mQ8z1LkTnRPHDELG9QnzNzO6arkIFX87a8EoZ4nnYFrFbHgR5gMs
xg8wckBI6FuEmO4rUoDy1kAE/HUPviLFo5jJbQWM55Cwa/lSqHriTmj5LNktt6reUdUSvtE+
XHhQf+hz6e1QccKZgpPLrD+OdLMUXtXAN6HjtW+82zZFH/xow2vgnXodPMP6+F3Wyu14S3Db
7gYo6IGfQ3RSO54ytWGFCgLfCTcRqCyTbCHmSZqUtfEdGm4opzRDJzmJFZcnJLbnl7UP7nZZ
vyaVkk0uQT0bRdoMi5lNz0aTWAbfZPnKYXZZKIxv2AiJtV9KYhG+LPslvVKcTBzfQ7LnOqpv
Q+XYmTxpS8u4kk4mOImzDglw3sQNlv27UHI9jeR6FQTuQgpNGJ/NugrK8Y3SxaVJXiiamXM0
aTTt2qpstE96CLqfmOtnNYJtRndNFRYVq4WotiZ891RVHQ7GeP9tfQPeg5uZ/4mlg26IwRZR
mB/V7I0froW6pS9Cj3O/BkX4gSSaLGp/9yzOdq1QfsHXoUB9V1wiyHwSV6O8sEQGxdkCa2or
/lISy0lk+Cwhiawp0xFdjcV10jX2jgh12bQXXvbjuAE0w8uwkk55pPsHFpslqWTj22jsl59n
jxs755fNrJQLjMwsRkm7Z5LslhtCN+OoO40gSnrQMOVIgMEcYbVhmk1eyjGf5SUvLM86Yfyu
oVc9fieU4+s2imknSfjiwow8Q1iFjY9OkK3cTRrhsS7Ba90lZSX4RdV2+mofpJrwonorfvuV
tp2VbM0paZznrc391vrdUP/8y9C0dgMcOOFiaNm0GT57cB5UnDUKKtRIYtMyayQtcJ62rOts
xcbdoUyoQJmUCItxAwKJCVQd6nNxScrwmQhv1eiqMOjNlHimQWBCwZVDcjJ72iGGoJK7Zk/Y
sUnru7FWALFKPoH4yMZLeIDsj0fZn8MIuCF0M4GwKI73J8D3E2xxNhtfyoTZNXX8VvaWUvO2
T6CoFL/Eo8akzvOqCMNBtjqWZNwZKRj/Ipo0ikvVR/fy8/E1IqTGP1bbU1sOtO6P/iWVUvx4
Sc+LL4BqnCi2zZgFbTtqoOioL0B3PPPIx2+SxycZDMpTrZnGZQ/FFk6P66iiECNonsT0SScu
uDEwRmQerE0glic653mrndMeqr9GR3blUNBgmWawHIxIkGJRUySLpD9wfsUwnq6EX9aHLxUz
bQuUZzdD7VhM7zMkrLTb52QcuYIcHCxb4+PxbX3V6182bLYRxWOZvXxLZxcZnGGUXnoLlJ05
QVWqtfpjqJ01EVo3rIE8/CxE96lPQ+qwoVD9nSFepb0wZ2THA5A5ijcByrhLA1o2Re+bKkyp
J8LpDir1anTFknpatsv+0q1gmzZtgs2bN6ur9LQsUIhfiToYv9kxcOBA9bWpAvziVMU3xsKu
516E+v/+HbRVlMNhU66FkmOOQj+DFY133l5h6vB2jh+R5FTyCfsKfgWjZF/68IRoJ3NteORA
jnFoAuB8QCgBoaP6CUzEi1BMk4fQj+fT9RX8cm6JDKEcizpZYmfrggv9uc2E1ZyCJJMp5wXP
lJRa0ZE1Mf2awRJZylQniNIplIRuyQmD/CjodShUTH4Edl4/CsoumaomjPRHqzq5mvHO0rhC
75emC+J0fUOdaajARbd2p8SWQGtqauDFF1+E9evXQzV+EZAcow890cOGFfi98cMPPxxGjhwJ
Aw44EOr+tAxa1m+EstNPgdaaXVD3vy9A0RGDoHjIIPUqFLcPBfoTB8aspJ/OgzRLeUdHUdX3
Y3ijUJgOo4fxc0xPOvvk2KwfjmIUX2+SUNF0Mw6KWfaBS1yZ9wmFFxzXpCb1g3b3qDtcdd/m
iIhQlru5l9HVVwOKw0YZVywQnHCOAxTQCBKET4rpcywovgco7bjUTzcXJUllY/QZhpRVE8dt
v8ZVlJMg/dH7UHPnhX48EQKy1RWJJg06qGxJN2ED44VwdbDFo2VXeCBs1NbWwrJly+DVV1+F
g/D74scff7w+q8BH1mt27oR169bB22+/Dbvx4ZIxvftB+9wnIHVIX3z98BWQ3vARbLv3Z5B/
4AFw8M3XQz5e3belNN5hhQtyqqJcTRpH03hBB/ATpCmeNmVjuG1BmTTU1dRDqlsPkJ/41hOK
K+iYzrwTE4Iw7VXBSvTYiXNc6cQKnSXo1DQsRLK+Zlhdl0yGUHJZbsbVissIFCFKOHaOENoH
s1hnqrYMo8pLAlcbBZFs42iJcI7msyGSo3w2ifXibGWDnYUOudFBV9wJYzpOGHgtNzR10E4o
rsGgCLfiwXxrSyvk4fIUHtPvmUSPtb/77rvwl7/8Bb74xS/C1772NTjjjDPglFNOUWcWo0aN
gnPOOUd93PyDVavgDZQtGH4c9P7hNdDtpBNwqepf4cDvXwqFffv41+O5D6lqNcKzN58DY0ff
CmtxkqREcd6weBqMRexnt+KEwgkZXhtQDn/pTTBr3Fg49/zz4eG/1bCk5glpby/zEIRwdNan
Ugfzx42GcfNWWHTq4KHRo2HWO9IPT8xXbY+89+Xc+lLGLUQPGZ6YqI+txlZBoSOzNn3N1wcE
UrYz8zafbbTO9IGxvZh4xxrkC/tDfHqWSP9YK7OtZ0PraUydl7YyQ81GOkk9WEZ56QUl3Bxf
00iyDUFJb8QzjNtxwqjFCSMOJwQjl+R8eqEtnmGk6VUkGAN1I7Fstlwai8KiR9NffvlltRx1
+umnw+DBg33iPfAaBv0OwGWpjRs3wko88zjp4ouh9JijlVx+WSn0vGQ8tOMDJvp2W0+d6qO7
eQmcc/dM+P25U+CKWS/C8zefhvep/Rkun70Mhk2cA+cMML47jkq0ZscpvWk5LKmtgGlPPgUj
+5Qw2diStQwTqpAVFXdTvRwA/1sG0RIYNXUKpA/v5jOmrkUQhXBwtGPvFayi+cRdvqZK43QK
6tiVZL96x0sWn3z7YgjfP5DbHOSas4sWIGYZW24Lg9xFRVtdbLQucgfNBK0LCmbdeGGeOG7k
3UyUr1KI8wI/SjWS5/MkUtJk8vKLSfeVnU5Kspxo36Mk9dvxttSOLBu1qAkDx7W6kDMMzzyu
FHH82KNcbsmQF9Nm9X7CVvVyW32igTwRi1xaDsWiSWPr1q3Qq1cvGDBgQKgc8Y8YNAh27d4N
zaV4r7B7awI+o1jeDR/26+F3HuPIoaQ65VUMhx/POA/g+bth3hvvwLwf3g3Q71KYPl5PPmuf
mQ63LMCLTSq1w4al90Ll9MWwfc0i+OblDyK1FqZdPBEWranDfCO8seBeGIdH/KPxN+mhP4I6
7k+vhnuvmA5LX1wAlQ7vilmLNY9wa1bAQ5Mqlc7oS26Be2+5AqYvYpskkCQ1wto3XoSNO/Ds
KL0B7q28AhajT9SskNcIixFzwSpd1jQPk+LhxsQjezml4BRl3pPIMkdgFkBF9njKP/zjTlrC
mr9fMhbXRggGsklkHCXHth+Cbfmp+3JJ7S+i2jr2msA8VcKGkm1FNEXXojpELoG55jYqkknb
juSSykbZQ/+xgnJC4DxPDFrbb0/rkAv6JhRVjjszkHzDJZow6h+7Hdp3JTjDYBwDozOKLfj0
d1u6RS1NFZWUqDfdajuywTvDcggmLVPtxgnB3ziecCNek9iN7z0h99I40egU46zRj3qN+D5M
O7sfPIVH6k9tGQwzZlcCTjWqp+/e/i58UI3XN5zU8PF7sOXdKmjveyJMOFuf/Zx9zffgxL4l
sGbRdJj6yBtw3tRZMGva92HjwpkwZf7fcC5pgPVrl8HMGYvhnGnIm3oRrF0yG/4HB3GAanjo
ssmwcOMQmDZnLkzDBzhfWL4W1m73XkVvuMuuBLZVbyyHjxrwFLGxFt7bshaqKK9CkYaqD9ZC
tTp9RDW9t2t95JNIIGJqFNAMyUvqiwYP+2tYVP44VqQBFhM0kbU4zVzpMfkQRo/yz+GxDwJS
hi8MYd+iY+VDKq26iYiNqreS5Zh7kVChdKBk3u2AJo6naskF8S1CBikjA4auLqqB3+G4k4JT
pomSfl5/ozxVmLZOwhso1NkGnXHE/FiFtjRh1D16O3S/6bFYPcZ1j58lUM7zWLlW/AATXtNI
4aMNZfj2DVytUm8VQVOy5jm3HACkBknhbbU7duxQF8PphVhmasM7qOhC+Jo1eN+yI5+P70AJ
prgOloJjTz1Zqw0+HY7pRUcVDko7LQbRKp2DUUT0IiguHwBjv3465gfjdhQMKK+Hl361HAZf
ehuMO3kQDDrhG3DnxCNg7RPLoFot8gGMnjYbxo88Fo4ddTFcWoHnKGn8kO6m12BhLcCUuXfA
yKFDYGTlHXANzkU0nXBiV7gcu3XsaTnSZgTOG/GgyjLLkWYN15bgu7SsMgFkjcJk3oZhs+tx
cq4+KxBB5l0BI+MBc1iUGqryoBAcGAyIfa2IIfGiEl85LavvqHFjhmoUfbMFVCyRSDrq5xpy
MyGaSLYiEj1XyfTWwXUHByp7ftIYREnXSep6Mrh+oz/oxGcCIdu8Mm+ZmSaM2lmToMctj0F+
Gb4mKUQnSJc+KNdy+MfDLiqkb4QXQmEx/nDicIcfX5xyaDoMioz37t1bPZ/x2muvwYgRI6Cs
rEw1EbtLk8ZLL/1Z3YpLt9+W4KmRTiTBDcXSuKVKcFEablwD905ZCHgPL8DaR+GnfzwJ7hgz
0JG1KWjlRnw5F8BuvNOKyh/Bmzj4r31iCpz7hObz3427T0EpgIN78B1caeBzosYdVcgZDP3U
qQ15XQLHjuxHq14dSmU+7Xac5gCca/2aw9XiMLG8KmuiZFGeVCSNVTq0RUDG9oGzfxZw2ReV
mPfHIp0JyaldbCUjnMvE3OdENjYclnqoXc1tF0TgkJlgWDZJwQ7ByhZDikT8AEoILQwjSKfB
X/Y1n4QyGbTrTRzIQwAuU56k1cCOR+Y4perJxQeqC3kV3aDnPQtUoWUD3VY7AXrcPk9PGESN
ejuHDANNLp2aVI2gFe3kF+RDAR7k0+MQKQoafsHP2iSd6U8B3lZ7yCGHwMcff6yWp2iCMBPR
6DkO2tK1DZpUvKQr5JUxJ0lOcKljvDL7RlgOx8LcRbOh9uFKmDLzNlg2fD6M7OUoFLtzJz6b
70N0CghWfjh8GeecQ676JU44faERV5fS1ath+ftpONp1K9jaqYoDEWMt4F27eOsvwTXCile2
AHyZ8mFJ+GMTQds0SRWlChxuK+Ddy5iwPlRhJ1FOf/9YEpgb3Mr+GORmRyFM1yM3Q1jKuyBo
rBNSwAcYxLJRhEP2RzGywLTZ+YegcTBFW2JWlZxmkq3FIVFarMrE2C23iw0xVjlzATRDu1LY
pEKThW9JnQRRoQ1H2LaY5ycqbvgJFA48GmjC2Dntu9Bz2uOqTE42vfcaLk9FuCuq37kXwj0f
mprwqBknC3ppISX6el/Y7utpdUKOlqbowT36feUrX1EP8pEZenaDJgq61kETC52BDBo0CAYO
HAilpcbdTgG/nI6FdaLYUqPXrZgP056vhfNm3AZfQOLw7+MyUfsWmHbr02qJKIWH6LVPPQtr
auqgatVi+PFTOKDTipVIFCPAqyDDvloBy2beD69swBmgcSssuec6mPHY+0IymC0ZeCKcguRp
d82HDfjw4opF98GDawF6q2WwoDxRtmz6ANZs2KCW5WhpbtWqDVDnXQJB/w6D03ACe+Wt96Cu
sQbeefpeWIh1LcafEwEXWJXFROIyuijj+uNmyDAVVFCtXgTdZeVwHSuQIho6DBWu0CFOpvAk
b/7IAaZJZzLFlrrZ5G0+hONkJu3HMdrIzzRKuY2Cb+A3LFExim9OHOqsg44badAP+ZXfeA+U
fnmsmjB2/OBbkBqsb8hpq98F9S8sgJrbJobqBjCDx6jkcs5TC14ET+NSO8WiDe9WxUfb6JoG
zaiZNFzH/aLTnGHDhqmH+mipiq5tVOHdVHQNg7rFv5x8srqrip7d2LJlC3TDd7EUqTfZxtnG
U0YekFo3wM9/8ATkfRVvuT2pl1ZMDYFJMy+FZVMegZ+/+BX44deuhWFPTIUrz1+C/Aq8w2kY
bFnviBbSyO6tPY64bg5c+ul1MO3y87VAxYkwY+6/4QnEeqCTDe/IH/M48ejlogEw9ckZMOPK
qXD5+CfQxDAYhgN+tfWMBvXIzWUPwpXLtAn9tx/MfOZhsQTVA866/mx4asZUvVRWfoQjXKBr
Tk2JQeQWpXiqMw5Hqqs21KXItv4jM+yZ4Ynjt5JUipIfoiNFYvMMGobF/FigUIEw5DCFMHkb
3UYLw80J3Wk8HRVpPSpOxKOjcMcDVJOaPr+IwXLJGI6UtuFTSVgwxzkaCOmnhz+/pzwpaL6f
x+ZYxsNFOYXJEv5ttzPGQ/P692HH5G+q22qbXvoztNXuVEIt77zrF7aVhBtujG1yGdEY1NoY
6hmNPJwsaMmNDubzvvv4n9vb081QX70NFtz07YxMZSvMLpJ+C16VX7FiBeyur4cd+CzGc88+
i8tl+VD5ne/ACSecYJnMSNteOe0PThnSgCaqv0rL+yM4+NR3XSM+IF7uPPWtARjHU9F20411
anmqPPAdDwHJ2cYN8Ou5f4Jjvn0pDO9Dy041ML/yfFh62iyYP+FYlspq245+1LW0A/nhVtmX
0f7KcKkp1ZXJymyoEu1c7hDBNhwXvDZzGLRxeQ6kjaZYLMigRGSao2vdsLwpy3SpZMpgTbgD
SLF9ME81t0ZEhSQYl/AQEIopH7M/EljAjumNickemHKaLptN90mWt7cpy4S1dxyf0JUMuvO3
rxwGfYpSuuyZdXMFRw6GNjwIVrfVOtS+L65Xua2jBrlyYRnp49amFvjSqx+HiQbon376qXr2
jTDo9/rrrzsyXhw5dlSfk046SfFPHX0+yqegvKIHjs14AxOtiquzHE8vYKwjBIalZqe82fy0
PtYHL4jTLV10YbwOl6fa0GHKhycbkpbmSlt1lXHTA5LEgLgTgPbYh2Po0eRirGBZzSliyQEA
HzwFUy5+Ck45+2zY8fISWFnbD2acOzRcJ4KjXXHqUNwN8MOLKhFFee5mHBBHlEo6S0dWKKn/
O0KdtHFtc0bHlqxRjqmudUlwBZjo6bryiTNRuoyfGGzfE6QQGCHSUUkSG0Mxg+iQpjrOUDqq
FKHNdkJ8imFHALssGijloMwMGgs8P5lqbB0hdZ2BhEPcbMVb4zmVXngxLk95B44Vt94L6bUr
oOHpJ1kkehtiI1qJuRwwKksgWneSZVwtw2vKhUW4ioEsipG6EK4GEInBuFluCYrMSkgbjeDp
ukX//v0pq1KfPn3UpFFBR8++kZslTGSm49YpDUx6AABAAElEQVQqr/m60f3BEJqk7C86Ja0R
pse1sqo6xB5Q+YvFcPI7r8GK1Z9C84Rp8MPT8AWMCWcd17LKuCWrQebqpShdYppfAan6v4qZ
veZ+jYxKbljYetCCfSckeX1kypp2u9Fcu46NmiscG/bnieYcSLgu63bQRbcxXW4wY8aR29tP
l6iMkWhA9u2bEf4oczYrbE0PeoFxJQJSa3pnSxgp6qEeoJFrxyPwtrS/3oaIW+xx5d1unjLd
zhwPgL/dT/7aR/cVhGmylX0K8zFI5wv7LfixPkopvoNE+JK9H0LThmejCRWVpVeHKLfto4oj
HqyYGmwEV9rKdMKImHuEu2TB5ocQcbMlMGT4KPy5hNhMvM9+CNoR1Ckykm1ehXqLhpQ86suY
+dEzLClA9iICNeCUlvWaPgFGqGsRdkN1/tEZHG+Kg8xHxcUmRzSKv9meiCqaxc1SRsG4lCiD
4TyFE4/B+4masAjNqYLeh8hrJIQNAshqx6Oy4N7igNDGyYY7qjlbRg6ME4nmJ7QTDuIGPlwE
OXn57VCAlwzUbV1oU73jFZepQmMUhSZNcp62nZvYUoQVrJg/nv6SXzPGY6tqjI7fQMYl7tSZ
KqojKG/E9dR5B7DxWIonD1XG+un/zM1yGxMna2zJlMmgMmOZPJtrLGvj7aeFR4DiZsbXLIdr
+zk2PcQXZMpS17RZ9WOZJdZQCJopcE3psLLcHbyzD30QRRbCkpwwtFn869gv7N0fmj7bAsU0
qHZGcmCb8CFCstXxxLEMRyIJNz4469P8oSucTdAJzPkRjFMfyu4FiSrEvxh3nEqoDuxUgjqU
7FR+hIS4fqWuKfEEQdZkhTKyritPk1d4DNz9JAEyxctMTgxlB1IiNllTNxfljthxfHf7lyxL
3yTdzCeRSyJDuDKZdmRZypl5ljPpuSyzDd6KPhToB3F2nR01IEbYmSUeEL2DNTs28aWsknd2
EKLT79Ab74R6vAbQjM9q0LXZzvg1ITbZGPDD6ZlVNEvplpY2vGuKnj9pxTupWvXyVDaToj2s
WXqVc7XMOk50XTLD8leFkDPTz0zas0Z9l+cLxpD1YpqnkTRHmhIpqZ7UkXmp7x2zxfsXL6GR
0RaZc8Vt/rtM6UwG+bD6mBBJ5Gz+mThcToJHsknlGDdsSzgdjVUYtp/OHqvlK5tJqyus5ceK
K0koOQlwXulzsziTAu1ckq8s4x+134kO1+O0swB+8ihs+snt0LSlo9/wDtaEfCjq1x8njDuh
+6ljggIZUWyBDgK009OG+GtTD2fghXA601DXbbKLf9DCnqL4/KdCkoD4lEI8l1gsnytsi8kk
0BY1XV/2zxk3sUfLjm5VS0AklzzkBAqRIlxB2gkjBXPAZFu8zQHkXg+Rq6AyDm2TxC+pnAwg
4uIsQejcFxQKm5Zm3byS1iABk66QNBLI+6QcuMB+4vjAsuySBtNUnk/4DEVjtONgfhYcjb/O
SNJPbTcQhJyb1W2DdaZq40+9r4KI/qBE281ENhopV1y/R1QfbtBwC1qHO6uU012CKF4uswhJ
tEzz0mamulqejt+dy9seQHxAPNmEOX/UhZLBoKI2H163ZG0mbERlw81Eae3nZR0Bo8EzwtGN
JT+vy/tkXDOqfuXaipN2BX0Z2k+8811kCZjAPqQ0HQG/cRczF7tZCLRro8szaudEq/TWXqwg
Xhf/vKVwj6nB+BdXK4oDd86ArDJBf6j5KPGW8uH2ibtXJOlulzpkN6wjFowbtxVtdXIzTtmO
x9LJt4STK6zkVpNJJvUrqVwyq/FSTltEmtVLNmo/UnKRwjEmyZ62yf3CruDZIGlvH/bodr1w
Kg2E6qhddUREVVDaF9bSR/VUcuz42VrM68gsxerop+efl3PZKkMixLNB+yVlKTNpqZk0ryZP
fGEhXtHAJSr8RriqgFOLpibfe1JDMR3xUH5HGSoMogGi8dAbckgrRYh6Xov2C8hrswTmyfuF
kjYS6ydcIkLDSZH9/ngl2TGpkysPnMp6nd6TT55LtpSkbaBVMixDqCpm1o7jg7Is74sA8029
JF67gA64qZMMU8bTRNiXym67qUqJ2GDfUZEM7Iu6bcz9yBMTGBkHitudFAnH63sK1YRGceUj
i6OObLdM+r1rGStGei6u8oIMsEeYQSbX14yD242ljKNLGEkSYRK+9IH0sq0bvf4j29SO1y/a
6V2AqULc8qThNERxsfN4cQw6VaQzk+4cZu8Is2iGNVxONq6twTWN7YpaclY7FmbAobMwi/k7
MVN9WzTMVn30DAvcoXhHUZ44lWZahpCeOOIEa6Y7NQtpG54Ud3zNlzX0ZFhX745eyUM29WRZ
yoflTVvJ9TmeYcj7Ct3rG3qA5jLXn8v++jqyTIwNa5gAtY/kme3lGEAyc3jfZdNq6zJpYPU4
dt89PuVInDxQakoZ90fpEvMcOdz4kqOiMbCQxKYPwFJgn0wWtwnRM7VTVye/4mMiR5TRmeKS
MijC+aGlqRnvnnKiZcQoAkEEOFKqq5hJPPeOVsgr3SGcijtuejQiqO7jcHDjmnAzHi8yl0w+
mVSkIStT4WLFZEezCiYhUoDk3kg6ZMAIlYTy6sW5CGGpmLO8tMc+5Ax8HwSiwdKLWdyg5OsS
qKb3IVtYomJPPM+mTVvRUIxdC3RDgogyEQrqMAgQndeeBCcMkoqCl/WOi1mcKy6fQhJl1BXs
/Ay94qm5tQny0/lqCKDH/NR/fQ9DMgcSNHEyoD0g5bWDVwvZ6OEd2NNM5rZd3k5NhphEijut
V7skWslkNDbVAH8qaJnUJsojEydM1pSL8hsxwmCi1P7heZnE2OkGTsxo7FUDOsWdf4rHDcFb
M8hkM4FdR0RJ4x/W8Nl1qaaN8DLvMyThHwvCdTqbs7f4QfVsxdei19fUQlNzA0aXLoSjd/xL
GghurKTye06OzjC8swzlt3Qe+7C/cUSnxqzaAZTzUimqNqwfIa8MEl//ZIc1kfkMQdeBsckv
XS+SZxnWJSklSTKK6KzPepVREqznSgk+8xjTv3Us4EaoCBGuG5JUGNQfwRdZ7aAgUNZKNGQS
FiNMJ0TYL5YgAv59SLeg00u8gtuuLseCLPqOhatIsk0xT7bVD5m65+Sw/4T58A9Gp28f5een
oKG2ERp249vA6VshNHBl+r0Fbru9t4m8ycJtY3aaCDGOe2yp5CKFZOJlgwOyXYfleKtcxlFa
TjLM461ySo7kmKd6BHZqp3KsFzZxSFvBCnsRCvKIYq+XTzZWJFZAwKmaivL+bOdGgNrG6wOy
JPPhPoS1l4cZpqs0HTEXBY2S3f0p9xEowKe/6V8rPuBHH2RK0b239BZDetw9m2TTim/2bCzZ
dLjLsEXPGzl2kqbH0ThKUxHpD+trHv015bVMkOppsC8eJVc5NambFRLgcfxg7YSyyFIXiDCj
JONsCbiE2aiYJoToJLHoSbOTjH7OYVVr0h/Z6TqhiSW8f88zje9dAaUDtc9dvyKf6R8OEC0t
OGlQsUC9tTG7lpWNl23zZD8QCZ+VI/gHSdaBT4iSn14xpAauQAg/28oKvajOIwdwPiMQqm7H
s/FIjrHD+BLLy1Ol4+vrtVcyeY2fiSxpuA2g1ZVfJs1hqU0YL4wudXOZN+MXZ1/Kx8lm46cN
n2g5suXAu1YcWHUMGmsmRsAFFe46NDIj2bTPK5vZhKgLdXi/7EKTHTeFwaZ3T6VbmqG1DT/3
Sg9qpOnVtwnWp2QjddwTjUBfk/r73/+uPudK39KQ39ZIZgO9ko7JvAMgdw/VuYjuI2oIRfL+
ONoMKBUcltowX9LC88k7DdnzjkrkEYpt5+CB3IavkTyfbLI8udh4nqaXYzvWCdoTS5Cj+Jmx
5TLzOMZcTgCrRBgnqXxH5djPKJwkMlH6xMs0DjY89iM3MbL1Sa9ZyQbbM31hupBhUlRNhTgj
fl4mDvb387Sl90+l1bfC8Zbberzvtg1vqWpoin/4Izfdyx+qTzZvhv/FT7zSMyJHH300XHDB
BX6ByJLoXY5ckIIM4bjKinL8oCeEA75Ia1FyniIPzh4lOiflZV7uhJIu84zMNN6adFvZlGWZ
Dm8xZBw1nnjsmCzFW5JKFmONl4ms3YNkVPJP2PIVBV2BybokQw9OEJlimD5Iu8RjvCg5qcN5
R89VczOOgMPHDa2HK64pwlBq68kz2aEoD20vMiQ4lmEdG8Xj7c9lEwHaT/GOKfVdjfwC/Nxr
Eb6ysLU9H4rwMfFsUrDRMkNpxqfQ6/Ghkx3btwN9+pXwIvuWghdWMStKPuOEk25oBCgp0S/Z
Iq4LngZ6AL6kRL1+S3RqV8DBCvMozKqj1uWbNNRUVUMtrjmW9jwIepWXdLkHdoNGnDC8OsJm
nO3anx8q1tOoque7w2C+tepWogNBimF8k2eWPS90znQiDNfUiyqbGNpG/AGZh5lIFmHZe5In
q3SGk0jXM7U/l2EEWvG6d2trC47PBZBfVAj5jU10ltECDc0tGUJpcdVwmM12S08Zqovw2PJ1
9fW4Zkb3c0Ulp+dw7yHDISkPqmDO18+BsZXzoNonUw3zKsfCORN/C68/OBrO+Ok7Yp8kYLKB
E1hkb3QMsx8+fF2oWzEPRo+eBzUWXi5JNWuWwqTRY+H8iy+Gyy67DMafew5UTl8AVfrrjLk0
1UEs2UtsUBxM3rIM63F5b9kafrpuuhmfoyStNAw1n1BOCtkaoIO2DHUDFXL0cSOjEIkawVQY
DERbkUgtsItGYAnV/dkMItDa1opnGfn4nfBSXBEqg1RpCQ7aeMrRXlKUAYxflNqJ2zPTNutW
VqbOMOiQoS9e04jXR0v8aKjfDUupD1z18DWw5MoH4f5Fp8I944YomTWL7oentwLc+uvzYcin
vWEqeF/Akp1Q14lrZsI7noaxSZwuGFUAFGHdosRM5EzK6U1L4bwrZkLFKRPhkWvPhgE9UlC9
+mW457qZ8O1P2uG3vxgPPTIB7FRZillUJIgXJ9OpDmYIzv6iz67bsn5EpKRp9LS17F+Sp/Nh
fyWmlGF8SaN8mLwpZ5aT9lO2i3acOuHihWeW2MoF7Yf+i0Shpixz2XRDlrWypOzPd3EEaA0q
vwDPMpzVqPwNq1bChg/eg0/WrsnaFdmulM/k1/OAA6BbeTm+DCsFI085RR860DlnZPL4wZ3Q
r1gyZBzMvGgwLH/wRniFTjdqXoEbH1wOx0ycA6P6pKB24xvwxtpa1aHXPHMvTJo1H346Cc8+
zhgNo78zDd6p5sP1Onhx3nQ8c0D66PNg1oL5cMsVs2ANrn6tWYT0cZVQWYm/KybBpCsq4d5F
a/VOUrsJfufqVcK8Vza5DlavWgyTxhHeaBiHWGyrcc0iuOKWh2DRvFsce1JP7mmN8OyDMwH6
XQrz7xgPA3uV450NJdBn6BiY/cspAGsfgd+swPOc9Aa4t/IKWLyG3j1D+o2w+JYrYMGqsHfR
kIz8uS5nnkGYuDbKHHQv1FBd0uuXnoeS5uRdWcnzNII5agtKvHVK3ES6KP765RxpwU9qV6iE
ZulWTGRKyADBU1Yu4x/qEyqPLNpyMqF8TBaybMlkhFmLxn5S0gjk5Rco0TZcBVLXN177xd2w
/PH74cMlT+qoc/S7aNu9ogL6H3KI6hu9Dz44aR9RlYgbjFQnQsnhE26Ds6EWpt31U5h1xzSo
7X4e3PatoQqj7tM34M0tu5TddN16WLH4Cdg4bCrMmXM3jK5bBnf96m0lt2rBj2DGU8vgoqmz
Yc6MS+CdR56A5Ws/gF04pxxw7Fkw5arvwRXXXgtjDlwJK9dthf5fOADjSWdvy+CRNw+GGXPm
wKSzAZ6adr+aaNJVL8L462YDnDMFbc2AM2EJTBk/BxfUcIxvqYO1yxfCg28eino/d/QeQD3e
vXjbBFUf4Jwx5gQoV16KPwNGwEUVebD4zY9xjqiD97asg6oGXvpLo95aqMbXAwSTPhpWOzWb
yahVJCIC8GDiYkm+kbc2aBJFA6fLitI3rigbJ55J07uYjc5a3pb05ZkJlqU5FgyaYI6xZUHe
GuyMiiYGleUvCMaThMlhJNZ2YVhQCbhcNTHwfu2K+GRUgVn7tzmIAD7Fh0+E4/lGXr6Kf35x
aTmUdz8A16uSveE2Bz74IOiuqREjRkBhYSG89tpr0Nzc7OPbC3Jnskv4O9YAuGru1QAr/wBL
VlbAlJ99H3qhmh6jaLjFV/7i3/am3QAnToH7J4yCoUNHwAUXDobal9/DaxJ18NbTK2HwxF/A
hFHHwtAR4+D+H41Whgvxb68hI2DMmFEw8phCeGV5Hpx4zRyoHEYWKFXAjAeugRFDh+I1lMlY
qlYTzeqljyFvNFw7/qtw6KFfgotvvAbLS+DPa/j19KR3taP3A1ePEN3UuA1W4EnS8EEHuiQv
UwB4AqeTvtbvsbok541w7j4daRfb1MrfmwcB1WvQa5uPNhpVMIwuK+9MEEZA/EUuJcGT2Jnm
2Y6p13G7ah9FGBfJzSCN6CzgmFYTj+MO800Z08v95RxEgIKtBkva4udeK3ocCIUFKWhsxAFz
DyW61fbYY4+Ft99+GwYPHgzHH388FOAaWmgK68ehCniX1JAxMLHfQ/D08JthzAA9inIf5b5J
C1EVQ/o5d1rlQUszxaQICho/hldwcB55XF9tAe33GDAI8+/hj1E2waxzb4K1X50C/36uPosB
oAnwTDjKHbwLxRkBTSrPw5XnPo9bTngzAN3tlYrSY1nclvSFf+4HsPBvn8DkkX0Eg7LNUL0F
oHd5KeYboMzg0jkQT08GS+2wiubGmetoSpKAjecoMtsVcTMmkOqTqh2seAHxfwiCG36qra/Q
ldUPb7PkXgSd96GGF3wmVP9woXxKPrn9hRxHACcMfJOI2jPp2lWqolsPfGgDhw81k+TYWEK4
0tJSGDVqFGzGZzZeeOEFoLUzou3cuRP69eunHvgrwdtm8/D0iHYet9+E4OvBRzJ1B6OhuLy7
GD6RHJC1jaQlh8CX8YL222s/g8qj9QxQ8/F6RGOsRlg6/bt4nnA2PHn7GPDf7FoMtukv3YwX
WAZPVBeqixvxKUvYDm+/vBr6D8LL1riihG+wR72wmvIOUw5fHF4BtQt/Dxu+PxwG4lxYs2IB
3Pv8AXDJv2yChdjMk0YMwPWu1aCmP/VFeNJthVqcBIPJsMdmfIIkY2X4pJTrPjFfwS+LwppL
fxPiGwh7TzE3/nNLyP5pRlDy9p76m55wTTy632+zVp5cMIeymYgjQPQdkEEL+ynBCKhxF294
0EtUtMXJIo23VBXQmlXOUrCjxEEfeuihMHbsWNXIS5cuhcWLF7s/Ku/YsbNDE0ac/SBf9s4e
MOyr3WHlv98DS1dVQdX7S+H2Gd4Zwiq8ED5zGcBFPx4HqapNsGnTJqiqxjOGiPSFU89RF6of
W7oKzyzSsPrlx2HqzGnwiXuZIVkMR1xyM/TD6yaXX/MQrKiqg0a8HrJ8yUy4bup/ApwyBcYO
xGXH8sPgNJz0XnnrPahrrIF3FtyLEwpNS2GJ6s715y3LmuVkfrJ26NaE9QnmyIYPszMKOfLT
gfGFhAo+Qmf4H4ZJDvGPZGQ+TIfpYY6H0Vlv/3aviQDOEXRfXQFeEKdfio7q2/BTfsUltIyx
5xLNYscddxze/ZNS1zbWrFkDu3fvhtWrV8O6devgqKOGQq9etrX7OJ+dPRDFyvnEQKjQXbF0
kkU/yuuk987CIlQo1/kRk38Jk5qnwMxrL1YiwwbjKLz2QPQXr3c8+5baj5669XJ4ykGoOG8m
zB+FBRSz7e0lQ8bDrGvWw+SZ18GSmdrweVMehhF4olG3GctKzwHzbbQ/LqnXCHjkl9Phvuvu
gMkX01SgUz/U37IMn0OpOh1G9ukBZ13/NXhqxlQ49wnkVwx2pGznQA5LbQxbktUpeR0HPSh1
te2OVIj9JoyO+q2xFErGUKhL6hnrZVJ3WdfkeuraA+1k2VUsuaH9kjmPQArbjc426FkNmj7y
hv/zqPYGfDQ6hffg/vX/Xs6RQe5Ymfde6lwfffQRrFyJtwJv2ABbt26FBlznv+baa+CIQYNi
/fOf+oaIC/eoH1Py+rLN51ZYsegJeLf3GVD5lYFKfs2iSXDlg8Pgt89frp+DIBybqpKmPyFM
XBqso+WpknJwHk53NeyZEBwUbqypgXp8JUxxt15QXlIHS+ctgH4XTIBj+UGNxnqowws35eXd
7NA+KgfJR3QK4T5oAVPXlDeDZcoTiqnjmE60MfETKWUpJH3viM9sHvEYkuACVWEbAYYWdsks
x7j70tat5L5UqU6vC73nr0ePHmo1h5btXn/99YBNXs6jcfikk05S/JNP+Tp+6rUU9QpwOR+/
EU69sgALbbhE1fHU8cYkpw8//HA46KCDYNu2z/AsYy1epG+EA/F5jswS73GsZZaRTu5iip9o
UlBRvgmemHY5LD1hNByDF8CfX74ZV38mqQmDJp74XdQxpk16f/G5CvcuJ48akou2UoIdwrue
Ug5jJkzw4+DEpK/IROHY/LTEzo8cUZK2GFvSbKpxfJsO08hGR/QZJ9NtNjbt8XCpnHFdkTZk
3hX4B8l0pO5mUDuC9Y8RblqNokGSVoMoWqk2fOUt7WR8xJ19GHLbGN26las33/bt2wcv1LdC
WVmmy2fSH6qqU/ZvIoYXoY/ZgWfeAb/9wgp4Y+Ua2FF/JMy84nQYPlAfwsdPOsmj6puAfP3Z
V0gO6EqK+nAsArWXMqTINiWdaS6wJcMyUk/iWVQUifXC+HF00x7JE62juFF2CdtmN0qHeeyX
8DFbKBOSy/u3IgK24IrYC8l9P2uLhb3W6kI40DVvfcNKKo0vomrBJY3uPbrbNRJTeQcgBZlP
DGAIagy6a4p3SqJEVVUO3mrwdd3QWjwxEtnFcmWYYrHgyPQYeCyMwV92iQ1Z8AWgkmJXXDrr
uoQMMtH2PKAwuTC6p2nP2fSI1pG62C1FU7vCXkdtCH3M0lty3Oi5LDcTXl1WUqK+AuqY5XCY
vZ9DdUkQD7MiOQ1Blj6YPu2xcgbxw2cz8vCeW/UWkTa8e2p3Qy1eBC+h26j2mPvxhqmC+JOz
glAismY5ciRNWZmwei7X4flFzPr7uRLKlzfVfEwquFYxbxMWfGbzNoDVUQLb4rqRoTBjJGPj
2WhJ/IrSY78IJ0ouiR2uWxLZvVwmo6o4cWMdKhqh1AdNBnEvD4HdPa6knWun6odHVe3VH8Lg
n10jmpqND9GIeyuXLl+ovuN0nfxSugCLFzlqazv7Xay5CIn2mptabQNt59TMZo4VmRfQjWU4
AoZihElGtG8ZJwjgp1CJf3akwAihxBjFZodoNjopEp11qSwT60haXD4MK04vU342vmVqowvk
sRoZ18QMMQEoEI+hDqRU0aN1QW32kAmzjvodWSoGGQd3D1VhLzFLj2Xo8YCubeCF8KJifGgO
zzKaGhr2Ehej3fC1t68Qomf2nRCxzMgOaCJsKSQdJrrkYVGwaYnCnoghBJVQqLCQNXVIMUpP
AXfwj2nTLNvgk8jY9PZ2mq3dLD53pElU6OgPgiQ0Z/FgHyHZ+pGNto9UtxOrkYcPBeuFKLym
gf0qVYJPXtMrO+gts3t7ognP2SUCw6b2nfaUkCT6C+MEJYVQkOmnsKkMVDwAVvYogZyL62YC
Ih4hTCaMHmc/ju9ZtuekPuelLzaaHSk5lTCljeSanS/J9c3Akq8qvoIdxCaiQmIwjKIdbD91
fwS8CNDjGHT5Qj2rQe+eKinB71kgkSaPvTvpK/e8+0UOEcxkYWNHUUWDFqw7KzOHFBwabijn
XTcRPHdaYz3eskETl/ldtc3GPvue1EcpL/Okn439OLudgWmzSXbM+tjkckDjKmViTrnnKJp6
iV1PLJiDSu6H+DxEgB6DKMA5og333Xw81Uh1794d0q1pKExl/xGmrqy42hfMHcJ0QPJlnuSc
fcpUiR4MCMRT9HYrCe6XCeJ7+n4eY9j4zPNrdF4prg7ZWvYiphCMYraonl5Xx8mznCyXoX8+
cW4TH9FqNjKsPnVfwYrVMSL35c620zEv92sni4BqRXxGI58uaeAEgrfctuL3X9N41NyG38y2
va0vGXDnSmEn5D2CtwGDVDXurDrLpciu6zI5wwZMbafsI7MOOeNjiDLxsk0SP1sMU4/9NOls
i/lcNuWyKRMm4TG2xMilHYnbGXn2P6nPWchzqJT7Se2QMNsy650JhqmbTZn96Gq7Nl99wbQJ
/MPQWnGczzbRhXCaI/B8A3djXJ6qq6+BVnx4rmbXTvz+a/gr7LI1mEwvrnG5I0o07pRCV1ys
oKwtsZbLCxBcDmaYiWAST5GZx/IswHRZdvK0cdjsnxWKIdWW8XzELAvsk6nONpjPZVMumzJX
mrFNjFzaMrE7o8z1SYKdiSzhmTHKJDbSFuNkop+kPjEyyTt1DNB+dmdEoK4u7Eud0dbonVMp
fFFhaxq/3IdnG/nNLS3QjB8f2m1/V3Y0WpdxqfObP3PHEB/xQZaUlm4qrTCmEjSZbMdBITaP
/A5J7+yKgReLSJ5+jENCmscbYrtch0VS/uRK+MkdKtmMIQ195nfOuL7G2jHiouRtNAYKsc3s
Pb6N8l06Z6uH5Mt8JrKOXlI3XDOkYFPKwraLmU3G2f+U2a62nY2/+3WSRqAJX+OkEn2aAi+I
pwoLU9CWTkFRqffWIgnGg4n+QpbkODh8dIHFMBnWCsfSnSyczwi05R0kQcckERZ3ILyL1w7B
tzExHWXGUGxTRo25PkM6JHjhPmDMcSgI4fMi+cBtqCUqesZ1vLlyXj3Y7+j28HA8s36ap88S
xPfsMXXPbWmylNZ1gesvOV2W94WQnfMRxQTv94q7W3j/88uHlbx289sNk6c2JZtaOqlOOJrJ
Mf3hMsnpOmubkq55djrjZ9LOjG3qMF1i7lq+FKqeuBPS1ZuZrLZS16bnE3YKLCd1Cw/qD30u
vR26nzjGppKYRu+SUu+Vsmiob2c49JaWVmjB5S3qjeqFhfTuqZaWZmioz/zUhStE2LJSjq2I
jTIv+GZZsJxsO54Rte1uhAL1uhOne+IM2IavQClw3vjHOw2pKET8Q1tOks80b8udXWogVwGR
FPM9jbgcxceLC+vTVtpgumsoDjaGz9iMGyNuYfv9tgh0iMT1z96/DpkXynLCoL7B5Y7Vv4Px
D3SD5HHqmN8iMImyXE8dN+VlclcTWUgkFIiX1uJ9nWISlpLGKwzDRq9964/w2ayroKIwH4pL
g48x0Hhg0yMfvbHC85hlJa9p11ZlAyY/3KGJg954u2PHDs+YyBGPE32KO40TB421+fh4Rv6U
yd+HHvg1uwJkUCIn5Y8VzS1XhulclrqcZxlzy3xqV9aXMh4fHz5cvQ62P/YkNK/foGTbcear
/Z/noP73S6ENJxSZuJvwlnhZ9+cM9gZqWP5Jfygv6+L1Y92BNM+TCcrLmnhyEhOpjg3i+2VM
X8wy+yw7ppSRdijvJbbpbZkn5VTepydbQ+Kxdtdudb1125mWw+pu0rm+OvZe/KPwqM0oeVia
whimrlnOvt2kTd12jM31oLLMO54R1fkRX/9INvsdTGln8MffX7jk9zUIJ2MV1s+DWlQ/tmDj
aprE3vrYdCgtyINi0qO7jVqxX4kf0fjHdC7HbfPwdlf6leAZQhk+cPfpL+8K+Ef+2n427+nD
d/T9IjMRjXicSvGxDHrVFD6sgS+PbYP8Hj0q4PprJuD3NPSkwYKZbilwSQLs4UY3honVWo/X
XV54GT594CHY/X9/g9r/fR4+e3AeNK3fiIGkQUgORJ4VNyfZ0aYdFVbgrYsUmpGNxR2JhM26
aFooTIh8IqetoDb7UjDMbyljy9v2p1BbycNoM9WptLD62+pio7FzNp6kyTzp2OLHWMn43gAh
+5vEsOVNP7StqP5l4QmS17RezmY3N7Tc2EgarzA5GUPK86952ydQjOv+Nj2mtTkHlxwPpmey
LcL4ky1K7AtvGTduW1ZWBkcffTQcgJ+doOUo+lGeaMTjRJcyClP4xb6CFF7SwIvi6zdshEMH
9IeBhw1wjZPznMIcIRnmSXnSc8sUTCyTnEtTwJ6uT17xPH2pV3rkYOh58QXw2c/nwbYZs6Bt
Rw0UHfUFqPi3f4U8Y7Yk70WfdlCdDTG86vl5qiSZMm8RdUgyFixliw3HgHksy1uTb5apVnKg
kXYlnfAkj/HNrU2GfWPbrCNlWUbyKC/pUt7EYj29TRZjv05uStJHRuQ6SJ85zzyW5a3JN8sk
x7p61/L6P9MllkljHm8J35ThMtsmWc4zj2gyb+NLbI9PmoSnt/xXFV2am2E2bnkvtPFYLHaH
ZMGcbGX9CZDrmBNwBKEzAXXGYAGk0VDH12OWXnoLlJ2pv3uT/uwjqJ01EVo3rIG8bt2g+9Sn
ofDwo6H6O0PQUQL39AiHzlRsietk1tUmS5PDkUce6bJYhzGIQZcvCgqLoKy0DFqL8N1TQwYf
Ac3NzdCnb29XMWcZ6mXmaGaAk3N0Kxh9V3vLli34lT79DqyioiI4+OCDYeDAgeprUwW4xlbx
jbGw67kXof6/fwdtFeVw2JRroeSYo/yIGFgRWz+vU0pkzb+0wYHX5oLeyAZhl2w0P04wlCaf
sXibIPy+nSYMz+Yb2/i8b2Xd/PXPZbt5WHp38MqB+MXsLywf7jdL2LYRdm3iiiZ0KMvjFG8D
ekJe8UIFA5p6z81EXkP4241pNCFYTHQCidvC9UPYjeKVXHIzlI7+nutRQa9DoWLyI7Dz+lFQ
dslUSB02FNIfrdIxF5hKwSy7KLnP0KczivBDTGUl9MVPvHvqpltuV9HdvHlr7q0lGL537doF
f/rTn2D9+vWwfft2XDPDh0icHaeiogIOO+wwGDlyJAw44ECo+9MyaF63AcpOPwVaa3ZB3f++
AIWDDofiIYOcERWPwAybKrYcYLM/uzVmAZcQkpEAWkcOAtxBaMt10C0u9chVXWb5EGO+AZ1l
WJfKpr7kET9q/JGyjOP3mxD25eSdtdnrT+27B9otaNbXCB1rtxhwnyWvED/46n3BjReGjSIX
r+fZ8HJK0ytG5Mz+KsvsEatT3IjPbS3jyDKZbKUtqUdH/234Y3w3Bk5XUmUnXzbG+LImRk1N
HLf9GldRTsIJ433YdddF6tkIqUf2qBx2piH9yUU+3ZLGC+Et0I6XNehgPjX1lh+qQE76wVS1
pcrqAEcPOlHOcMBYxmxA6lJEq8NnQ5YtWwavvvqqOqs4/vjj1VkFra3RZLJu3Tp45513oAEd
HtO7H7T/4glIHdIXDpp8JaQ3fATb7v0Z5B3QAw6+6XrIxwcTTbtkP033GOObfFPYUKo7us6k
8TOyACWxH+Z2Wpgr49tSR/TiZLMvxeP4Upbyprzu9MntmXiyLDu9aUfKheUzrTfvrGF4XU+n
jqDbNq7+cXzTd5KX8dHt5g0kZJcndJLLJHW83Tw/4uql68EOqr3HcZX3CeZxDbyY6nqZfJbj
LeNwOYdbx3RH45XEI18cya6otnsQyzTeophPTxnSbVM89GQ1YdRMvxBgt/P2caFHooTrYitd
708Q1+Nlk0sV0Vf7AFeB6qGlLa2/Ef7w3Hn4wkI69fASd2qPEp+TDeSTtuwZrXhG8e6778Jf
/vIXtaZGHzGnK/al+OJEqvTu3bvVBRmSeeOtt6DH5io4efhx0Gvc2VB24vHQdtwx0Lp9J7Tj
xRkjnsJ0Fcw552JY0u8i+K/5E+BAl1MN8yrHw1MwEZ6Z/y3nu9ku08nUwUOjx0HTzN/CxMLf
wLmTfw8zn3kGhuuPbCsf61Y8BP82eSE2niVVXASLFn5PYdviQjRbqlsxD20BLHzhcvX9cZYh
ec1bDD/5neeH5GfaWWx+EV6Yb2xLb8n/YM3DdUlW1tks+9G7ohRXfxs/vH46btwGvP/Y5Jmn
62jG0SwHI2Hzi6RstoLadkq4LreTbDuZt+ApdoyMo0ax8O8KyfQsVv0kdhuphO+PuV8025Kt
HdTRP901hf+4LzA+x9jOYyk80N34PtTccSG0480/LgaFheokE92JhcnFxYq68prVgb9srB3o
m0tkPI2XMdrb8DUiE6+4DgfqCuiJyz+U2AFViPljk7XRGEby6DrKSy+9hBdZWmDUqFEwePBg
FlNbuk+Yfj179oQNGzbAip07YcS3vwOlxxytfMzDhxF7VH4LLzq1Qn4Rvf6EKylh+sDVc6+B
P1z5IPxk0alwz7l4QQnTmkX3w1NbAKY+eT4O6qJ3SVUohVFTp0D68G5QkvoqTJl0DAwu9zo0
dcRuQ74Nv3z8G1BY2g5/feQ6mPnGV2HO3G9DBdYJCnv6JiNZd2kmQKc74CrwNBANeNa0Rslh
p6Ifw+CIbnSaLVF03sQyy0GN6PY29ePKJr4p7+dbKuAX6JJStI/h8QnTC6NTZcJ4Jt0s2wIR
JWPy4somvilv8qPLSdrV21dt/djEN/2RZZknPbOssez7i2knqmzHDdqjQZWXjYJ7sGeBeDbM
5g3vQc3t46G9Tk8YjKFkvbApXXrGTmLwhME0t+yZzSinJ3S8xRcvgtOjfbsa8Fm+ZnxWo7Ss
O5TilfoW/FZ4VyaaNLZu3Qq9evWCAQMG2E2j1716HQRHDDoCduFpWjNOFG3i1oR8fKiPLpCb
hxGy25YMGQf3XTQYlv/8RnilGs3UvAI3Prgchk2cAyfX/h6umLQI3McaG1fB9MrpsAqXrQAa
Ye0bL8LGHQ2Q3rEO/vD827BD0YWrJT3Qd3w6s9cAOLQ/3UhwEBzap4+qz4A+KXhjwb0wbvSZ
MBp/lbc8BqtqvFavemcRTBo3Gnn4q7wFlq4RX06s3QS/mzdd80ZXwrxXNimjph/VKxbDLZWM
MQkWvVMlnMs26/mYLUK8XlfYiPfiH1Oio7HvTH2553Zd69Dgavtl5YF4DiPuuQsTvwXPMOof
ux3ad+12n+XIBENOFjxhKBtJZmbTGXWupIkpnDToVSJNzU04T+CkkUoV4rtEivAe3Y49pxGw
mZBAb1/cjRMCV9inhn2osbEBl/Ua1PkAnR7h3I4/6rj48/Vfmrlp5icRL0/l4d+7Dc6GXTDt
rp/CrDumQW3FeXDbeLwzoWE7rF25HRU4pWHNlnehIU3ldqh64034qKEV5T6GlStfg+2KzrLm
ltYeHb9wu2bBzTD1kedhxDXTYNbMKdBr+VNw3WUPAc1b6U1L4eIpD0L1iGtgzqNz4JohH8DM
K6fACjUp0Svql8Ejbx4MM+bMgUlnAzw17X5YgzzpR7pqKYyfPBs+GHIpzJwzEy4dshEenHIx
LN0U6aTptFP2/A4R2E/eKyPgtFtnrL1Y60v2aAfLZco1Xua+0dhj+2WOhBq0NEVnGwl+Ep8m
jLpH8dUgNz3m6tKZBP8Ij/PqDAPL4vjZhZLjKNfJZWaacZqmrr4W6nGMppcWlpQU47Ma6qtM
+OU+fDy8KxPNhPTk4Y4dO2HZK8ugAWcyPTtSx9SpDZee3n77bVizZrXikTw6rOcLFPMkWYNq
ST+T0x+uwmUqWLkElqysgClzvg+9SIWWggI7gXPRglhu0t8aST6t1sBLT78H/S6aDTeP+woc
O/xMuP/R/wdQ+1v4w6p6WP3ibxF5NNx/8zgYOnAojLtjLlxz0UhIuW+mr4AZD1wNI4YOhXMm
TsbVqmrYpeYCz4/VSzXG3DsqYfjQ4VCJGKMRdf5zeItepyczvpkadHpjpmr7rDzFE380+KsJ
wClH1pdkdNI5r8z04DaJTFDLo+Si3Xgf5a2Hnrsc1bOjdc3SGx7MY8448sq8a8g0YdTOmgQ9
cDUiH1d+Ys8uXGx7e3R4snCrrtuoppbehN6CX3ctgEI6waAxkyaMwsKunTTIeO/evdUF79df
e03dSeX66mToZVp03aO6uhpf216Esxx+zxx50d3Bzi0ZciZM7JcHFWffDGMOVbOFaS6kbMfz
hC0eNW6DFbUAJ395kCuW6jsY6KpNM76GHprx9PPsMdDH5faBcRMqYah63QudTZ0JR/HchWeC
nHXFKdOMZzanjPRhjMRZo86deHzSOSzExcM0lam8qf8PUMYQqfkCq6qilWHI7ENHWNzCpMko
G+ZtGEZn0XNpN6yeneW7g0sDOn26IuJHE0bPexYohZYNeNF7+gSomDRbTxhEjdD18chWFyQ6
s6FvadCkUYAvuM1vwSP8Rlz+6dov96EL6MAhh/THKrfjqc9u9bZFtbQkjvxp0qipqVE8urYh
H20PjZXs+66QJtJwXI7v2VJdk/6oo/cm1Q4kmv5sI+D1cSNFdT6F5Mq7B4olFXA4Uj/euBP/
OjJN1fCpkmzXZl9+z7uWkt4A8265F96o4qWlYvrcSUTCOxn+f3vXHmxXVd6/e+953HvuKyFP
QCAZQ5vykMlYQonaVmIrjsxUnBFm6gOrtXTqMI2FKhYUHEWpNp3YaCc+4gz+IVXa0umkLXEU
BFMdwIpI0QDBoJFCkhtyX+fec8599fdb63x7r73O3vvsc+69IQl3J+futb71vda3vvWtvffa
ey2Wfv+nEs6EjMtTDxOoc1NR3ViSfKTV0aVqhadLd6qkX6b6eeZP14Kl/DlEJunkWza3K9FN
t8zoJCGYjy3mVwX7WAqtg4Ce9Ou78XOSX3eBcMAYvv1PZPDju02ekqtP/jCRrpHfiaknx4Yc
biq4cKG506hhYmN0GLcfGE1O1MHgmsejpvPWnSfnnXeevG7L64Qf8vEYw7cbHCg418E7oMsu
u0zWr18v69atk55Ss33MW3B42DvXw2v4f5X7njgslZEDctcndyBfkqTHUBqOg4HAdNy4hlsj
W97eL4/u+Kjs+flhGT92QHbfhrkUeYNsxe3EuZt+HxW9S77w7Z9LZXpcHr57h9z96EEpDWa7
A8JnNrJ+yx8Y3Xd882EZGR+RH9+7Xe7G3c3b38D7GR5xetmS+L/E118chmvbON4sd3HIw8/H
8T1ZYNQ1rl4ni35xemh7LbTeC80vTvc42MslN06XNmG8S2AoTfj1/fVnpGfzlWbAOP5X10ju
1RcYQbPlUSl/95sy8rEPJNI28KSsE3AwDvMin1MZjNs5buU3NvqSjI3z2ciJ6Dg2kHA3qIsv
ukhWrVxp5jZewhK9L7zwIuYwfmTMsGXLFvMW0tatW83yIn14U6qIrxHjj7qzNVG/L1yDy7Dp
3vBW2faGu2XHh94lXwHkzEsvFnkWk+6wCX9cqbKGnz0wmOALwSBbD4h24gnyCyWZqz9HIs7v
XL9LPnD0JtlxwzuFQ1FHx8Vy6+6bZH0eha99r3z6vc/L33z2BvnOZ8m9X667fadcjC8uzZtc
GD+NDiwCM9WHWTOoYWzp+613y85tQ3LDjlvk+1Qex5s+uFPefbF5xmUB3l/y0cOdMCMsqcyF
E8/eDTLFQ/nR/nEdPg5mCBflT6Ouofy0MlVGcVzbKExxeHbLXTjTPn4arqFlm0BN2tVpnnqR
2tdkI3/muOKpV+zKcvUI7+BDe0SYLWUWzAK0Ne82ko7erddipe6fyfEPvcO8Vlt98HsyO8Yn
EnhG8OOfJJHFwqN9MRZlQYAI1ZjDgL/xhAGk4/zf+O25ickxfKexUp74yfcbhJTLZTOnYPeY
JVmyQRqIGwCho5NLwM3UPsh5VITbw+8khKYZjhXkK729eKU41DvkZ7lG/8bJIAY7pNsRXaqk
MtUtjafLR9NpchSnnbPPNynIkLeWNdKY0rp4teV8fKLOap4nX09ll9Q2LE+uo61PGk/lHz2H
/u3CVY4L07TKUAsGFgUgyW+U1j+7cpQvcdQPkfJJnDwls1zPTlHm5HxoMwt5RSBG4+7CVjka
F5vz3nz5W/B4Co/McZcxMLgMT2gwKVNI+DiOih85csQ8OuJHdnw9N93xkhTQrhB2hMA9Q49O
ILa0cR1IeSih5nmuVavmMdeRI4fNhLsdOBSzfgbrwM1B5MrQDuh2PqVOK1Oc8KxasfPagUfp
Q5z4lOKpDjwrLJ7iREBZHz1s3VQ/hepZ66t59+zWI47eLXfpmqWVLo2nW+amk3grz6Ryhav/
KL7y5llhiqtn9Y6wh2hJ9Kz0yjNaanMqpwEncPIgkXABFOrZwKMuUPVgNg6Hd0DzH3zqwl6h
p8a4m+2xdRZz8fs4Pv5nXOeLSLFx0WNUrVbs/uC44zAT4fwzeMYKZOz6Ii4+31oaGBiQlfVH
SG0PGPQj/nBwjKDj1bMWmPrXDVJRRJ8H82YMwh8urEW9+ViL9bAHMIjEUz1puFuioGNrx4jr
FHVGDSfSKF1YGNVd+fGs6RB3cVPx8miMpKOZjmm0STxDuOqj57Ck/ZRpxhbJ49styoQ6ur9o
aXKuuT5pNoz6TrKU5iWUQn/PcjRrDy3XczLPhdM/WcbpWdIYdxeunvFxMZ3/DBYsrFQnsYRf
j/T19ksnR55ufGnNAv/gIykOGu0fzu164ENMZPTguuA0h2fHDH/kHQgyHZ0T7HaS3+piOpBb
oRDdQDXwu51CYS5ZNN1afVxaynF/bpmmm8tXzOZnl1eaXdPKrBQ1nJ7txUCUf9QuLHPLXW3T
yly8pLTla3Vx2y4JfyHgzdqtXRlxg43KUp5JdtTyVs7NbJ8mq5E29IdWdFjCDS0w/7gb8opL
0ZdsXMw2k45eay46+vCYvxdPpnL92Jdiegqfh8cMGhTI16zaO/wBQ53JgWdiHA08LontXMrX
LQnTRax+y4NB0GDijwbEJHo36KR1mFBKug4+j5B/ct1C3tQ3G55Lk5Ruxou6NsNJ4v1yw329
fbu3qp9P7/J30+Tr5y2sucR2WtbXy5USpwfL0z3U5RCfdv0iSUY8ZVYoLZFFy6x4WeWenHjt
x91s9dG4aLGb23QWq9tO42PrGjZk6lyzdi3WFKnhmVW2USeTSghyGqQbArPTS2xZE44OvouZ
iRYEHdyrUI+6T/LUoFcdx+0QaZ1TWWY5k6fLN6ThlXeYa0wlVL4RMRUSLzuV5JQrdOvIdluI
tktuN/qPbTv3rEZzdVFY4xltm9i8jU6hdUqqlw/385nicaOSsZAG3rFYLQKNLRIN0iKzJfRm
Foj6aKO/ufQ5vG5rnBVvhXXhVapctTqFj+vKLs780gyQ4GDUiImIrbmF5eUq1MgykOaiRdNA
idBZ5aI4JhfVzjWs21FcuM+Ecjhgxh3xdI0DB2UR1/IJmakOyidrXnVRfOaVB88uXHH1zDLF
VZibd2ldOHHjaJWHf/Zp/fJW8i6vNP2y8nT5RWm0s9mzW1+XRnVQWJCPMnNybHPl7YC9ZJqv
eagmq/6k8hVH9dJ8K+fWaNWX/bo5MaMV4a9QXG4bcdddd8njjz9uLHDJJZfIddddl+3j5zZs
xrmMWXwEPoevCxGtpPPFF56XWqU6r7Wn9u/ZKTffvF1+cNR+IEhnjkZp1VSdRvO+85Tlvu23
yZ4DWGZDJuS7O2+TLz10yLAiT8NXSZueKasuzxeT0CFtp0pm7Hc2YvqwOB4+ThxdslRbEsej
GY0t923enF/7srJp5GKdCFlxMuJgrl5Mx+HEwXw6N5/ssw1O6ZJlTC8Ej6io5PpF/SgZL8ov
Pqd9M8rT4mpZPOUSVOSee+4JBgzag4MHYYt1FLCEUxHLPtVwgzGBG4xcGV9gd2IjI44hbR0z
z8l/7HlS+HnKv9//M9ly7UUpbHhVHecoIcnIoSNYfhePyrAw4Sg2Xnr+nCyLKZEn9ddzyC9M
NSuPDxIhvU016yxJ5Ulwn7/m0/D9svR8451MnIw0HmllyotnHy8LTK9UlVbzLt8saaVPwm23
vBmdLy8N3y8L8nql4Y0wQbkvxMm7OG6aKNF88h1lFM8yb4RF/UjbSfE076iWMYk+mx4SPD5t
ximPy6mVVQPZuj/11FMN6vuw7du3G5wbb7yxAbcdQGdXHnPfM9i9ryKdc5jcmEOQnp7OEpwb
xR3/8f3yDJbN27xpjQw/8G15runUSEyjQ74ly0n4zXevXH3nLvlEfeMkV/JMjYOKC8majpGd
lXQJz7FAW8Z36BuTDDrtB55GfqcGBHZkvaGstahrVzc939ooLz3Pl19In73d6rJxMmOko4qT
BGP20aV+GlpYU6FN4vpJHEwp53ue4R4a+CIcy9vKNGK1+WpkBhswRSaMM0spy3/veUTk/PfI
O6/JyyOP7Zb7f3pc3rdpueHw3H07ZdczF8gnbtgq5h2m6nOy8yNfkvO3fUyuXIc1PaqH5N4v
f1X2Pmk3D9p01dWm99hFg/mo6pPyzCV/LjdsXQd+M3LgoX+Wr37jAXNXIxio3vz+P5WrLz0H
ZaFBtfsZBZb+eBZwu6drMw8tyCq+jxvN69VmQNZCQmnp9JpugfwkRKXNovaJVxJ49n98cSYe
CaRmCErXYb62VnoNVppP0siFG80c9Zyki7aUDiwQtdDll18ue/bsCUqZIIyH3mH8+te/juTn
c8eBdWOlgMdTVb5hi3mNTsHbRV14PJXDr+Xj6OOyB/F+8xUXSXH5b8obl4k88l8Pi96zTE8+
L8PPDgV5wd3M85VhGanwm5BRufe2OzBgVOVt198kN297j4zv+Td5DCt+5+s2mjwyLM8O2e3y
Dj30j/J3GDCKm98h227aJm/bJLJ39x3ytUePZlA7avR0AnZ6/Smm5nk+RQ9zJY+aBVUIEjEV
0vr6RUlwH6/1fCtBp3XuC0GRZi+Xf1Zfy4rn8mY6axsonq+3wn2+7eXZbi21HavtVz2A+QXt
6XS6U11xxRXYojtcvJVpwhbrmMZeGpy+4DqFMzUMGrxS6MCaIl0YSVo99u/bC5I1cumreW/Q
K5dcdq7Ir+6T/wniOB2Uy3zXHdUdl44/JQ9iImTz9R+RKzdtkHUbt8iNn3x3XQU4j/GfOek2
iXH50X8+iTuad8jH37dVNm7YKFde/2G5CuIe+Zd9Er77Fed0cbC6mMgprjPZRyYMtNmCbYTh
SZKp18HRpnldaDO1m54dBqY93fwrIR1nh3nWexFYWo3IWH/z1HFRyV0dF80Yi1qDl4M5t4jQ
OwvKZ1q3jeAdBX/cQps/zc9Hzy7s6sqHqFxkdgZ3GrmOTgwYuMuYmW78Ijxd0Ivy4F77WOmL
H/5gBHXvvmdly9UbnEAbFttP7UTKh3+BXbiXyZYL7KMsg7HqHLnQJBjA3WNCsMGfLNt0trPP
RK9c9Jo1suc7xCP+fJzOk1fPulBvjtJV7iROc8CIV49wY7HgxYQ4+8XAyC8GHC9lCZrFAqFv
NTNsQmOmCiFPn66ZnFSGbRQ2k3+i9WmjCicRCV+5ffrppwONmCZMB46gYIESnL6Ynclzb3A8
msJ3GtwfnAGk1benRp94UB6DUm98/81yxTosQ4K56a6uiuz7yp2yd+935EUMGqYzdM9h4qTu
uBPYK6NekVwvl/Aelh89PSobL+ZSJVBi7LA8i9Nqg+M6UlGWY9nw4WF3P+8Z+dVBDlr4MNHg
+45pgBn+kE5lNQZZLcnA6CRDaaxLsoJ+LdWWPlxNFQNPZr5UEmsBtTEKjQtmsWkWHFeY+rZL
58h1URclDVkqLlAhSCyKxNOd6Q+xy+m3vvUtvMWE5/j1g/MXt9xyi1xzzTXBHch85jCUb3DG
ADGLYF7EHuFcIr3Ttik+4GqpLavy6LcfAM/Xyx9euk5WrVora/Fl+apV62TrW14P+GPy4BMj
WE4XG0MM/0T27X9Rjh76qXzpE7txd2GP4jmXyRsxEOz74hfkoQOH5fjQfvnaHSj39MDO4SAY
lE1vwrOox74uO/c8Ki8ePSQ/uHeHfANPrC58+xaJXx2LjDxmddmhJxPg4KiD1/GckihJwOdk
TTQfMMyAHqlgWBdzd2JswT+eUUK0pdR8LGDMWp8PCG815sPRo9V207NX3HKWfPSXkVhFB34W
JDIyWEJTC/BO4lOf+pT5qM8dMLScMH7wRxziLuRh9tCoN30nNmLKcTemliayqE31oDz0DKcY
fk+ch0tGbNwJwgAADgtJREFUz4HXvB6PmPbJA9/7X7n2z/5YNu+7U+7Zcbvcg9I1558n8swv
pWA+Sx+Qa2/bJsN/i13rtt8ud6O8eM6Fcu4wRgJzWI8bLNiJkHVX/aW8Z3iXfH3Pbnmy/uLA
hW++Xv7id/n2FA91SPVUwphWOPNpBwKtX0zSBqCPdLLlMw4YEbWjdorGMN9+fj7CaCmTagF1
JtiwLTNG2ylVlBGg8vQMilZYBAIc+gDGhM/Mzdv+FPWlCPFSpgUL3H///aJvRKWREYe4V111
VRpai2WY/EbM7sSchhlALnnt1rlZfKsxXavIk0/8IMLs4MGDsn79+gisnQzXh5dct/QWOQB4
vQWXtTWUT+EhVm8JMx7qnx5aIHemKuXytOSw4mKRS6JkOA4e/EWTekCo/W+4GdH8k6hLknIZ
lElFUYGK1IqcaB2Ug3+2FwghblBXv118wqX8AljADuhBG7Rsc/pHKz5BlaM+xbvI8CJRy5rx
VDw1geIT7qbdcq2rC9P00jnNAnFxl3cQWQYN8uUE+K233pomwpTFyYkj2rzlSin22H2XcoU8
7jTQ7uZda/NMIo5k/rBwow91sCjPIgYAfXdL3TMeE3RdRekd0On0KJ/knHKNw6iXUSCSRq4K
13OELBYYwYh21Cz4JE/T0WMfZJUGMpDUXFDsJTRYuE1NmqwaeuyWsm1YIHrl7TRatKDO2W+d
+bdUrBjjOe3yrntd/eQ6U1RWDEIb9js9SPx2bV6rrAMGObWC21wy4gqeRpm3bOtrv2LXa3zo
h5kNvk4VdzDQ6Ac8ceULAaNzuYGsLZ5x7QCYu18v66GB08ogUXiYbhPXdxQtriwkR0oRI8AM
mWZ0frkqome0XxMpWu/4tlQ+TZgsFS+ABWhrexXuMkMvQ9aWWTjT820X3ytcfn6Zq42fVjql
UV3reMgaiEFTXJZpWul8vkl5j38S2ikJz2YLP+7u2rVrQWur8SATUzQj42gHJsI78V0flp3C
O7gIpkmv3E5NTWXi2zaS+lUmBi0go23YPBWszsgjOVg6PE2SfxwYiWNABEePujNk8wmHNIlA
dXD4xqI2BiCHuXmDTR0kzgYqxaVZSi+yBertmGz75JLsmvnOksST8KQyX5qLZ/nzYo8pe1fh
lvu0SXlSW14hRjt8QurTIbXYcVfjYjZb8aYCbTyDT8P50i2Xu+XB3aL8g5Me3E/2RB/R29ok
6XQs61zmLsXzM3Xk0dFRM3mTxCWEh/wanDji176Dh4XagaJ9wMcPJSantDKWVvmanBHHgUJ/
US60HQcJ/dFGiutimtoGf9ySpfTiWCD0A6aMjwftpBIVxzQygJpnuZv28TWfdFZ/iiuP40u8
JHjIw/Q7ZE1dQnBMyjgaMWPKXkkg16ZuOmqDExF3s8dFtu8s1pzCOAGV8/kurh6CD/uwrMes
GUWiyq9YsUKOHrWfd3PbV+4vG3e1GqVqJVc3XLL9IE+dkg7nIjJtndB3RQbMCpZ754BXqUzi
VeBVRqlG51YeLgdXhhWpEPMdnEFViGFr/wDEIlPisnNQsiWVGJzs/wiZ4R+B2Iytm9KGCH57
JeGFFEupxbFA2DZ65xfKCcsszG1lpv1ypUyC1+mVTei4SuidA0QHnsTbokQHjDjcOBhp42Q5
Yk/rJG3SvP6LFXfpd9WqjYt8RVfjYjOTF0t56e4uSamnH59RFDARDoparYp5jcZG1glsbnQ+
Pj7ejHeb5daI6oRkYjSpq2MHDdVNDZ5NVBdeE6NhtB7xVOTp8a+LSZbm4ZNxHRR8YB0IU9wA
4CXiytMfObkMwkHA3nloGeGuTQkPcRVr6bzQFvAH6YXhr56o52SuwYAEVGJb74rzsWQezUpM
nyRSwDaU1Iw2Wq71CRhFixc4tzht066SWvdG+r6+PnNxvlhxl3cyzeNiqBd3ds3lpyWPN6fy
XRg0uHPf5OSE9Pb1hlhOigE3Peg6yC0nQ8O5AS4MblpOp9K0TTo567ue37n8qJblyRQpPeQU
3qQIjoDMlR6U2kSAEyQ8hOZZX/c4CsO9Xqm4zuDzsNq0r1OcDkuwk9gCaOrk1k7x34YqRXHp
V4ZvhHkk08AhHlDny1PkSqsdXvESTmWoxt3gIuBlrEx1vCydsx1SKZakMIhXbmu1CSkUu6V/
AF9vxxyLrjScxvhN3VfC4E5lCGx0IoPv6BqlAT8guDDDoZGNx59c44cUU4A/Lk+FBWdfKVPg
Co1DsDIjdfSVDwREE7Zd7B1JszZK1ruZflGZS7mT3wLxvuC2c1odUvDgqsaDgRL1pxSaBlH1
PqBuz3I7pYpEK3waGJ+2gPj2PHHV5QVpB+5MuGPfseND+NyuG1/UYZQvlXpl+bKV8tY/epdU
UDiJz9CncEtSw2+amzRhIqSGZ2E1fADIV694m3LW2jWyCnMehw8fll8eOoS1SRisO4RzJFwE
cZaLsMM5Vq0+W1asWI2yWRkfG5XjENyDD0XWrj1TisUe6RsYxJ1Mn/BtgfExOwcxVZvGBuYd
RnYFz97ymEsp9ZTMhDbTRSqOR0+ch6lA1xrekJqFAl34erxQ6EY5bqEKRalilyneRVF3fsDI
uubzVrdJzHWUy+Mwxrj09g9Kf9+AuaPKg64Lr5blTD2wqiM2IOEa8hXwqlTtei+dfPUMryjz
R775fB71xs5WeMw3NVXFm2izMoXlhPn8sIaFIPtQP/aToWNDpk60d3ehx9SBsrr4HnT9a8u+
/n6BqbApVs14Buubw3aLOeLgXxV1LZdHTb1Wrl5tbEd9uOE7D9qBLzXUpmoyhXkdtuUkaOyL
DnyxEzZA+01PAwftOzMzZ9bKn0Ydjw0dkaGjR2Rg2XK0Dd6qo060BX5cHrkGnbBAMm5Rc9jF
C7SoG83DlS/Z6WmL8gTacHIMsBkji/6Swy1tqX+5fV2PV5UcGPF/FjyZmAWu3X8Y6/aj/Qrw
i84c68vD/s2h3ciL6/rPQM5Lxw5LPleQPC54aHsek2hP2r2vH2v01w/ahY8pGejo0xPlEfjZ
SwaPPkp4qdQPOw4Yv4WZuSAb6l+Q0eHjqM8Y2ocfpUJP09bdRqbxASDnwZu+Sv1p68/cEX5U
deDAAVVjUc8bNmwI+P/9P+yW5YNnmHajnarVmoxPlqW7WDSLzbHCJTz+oF241DWbg803iz/s
SxX08Un0CU58sg8sA6++/j4TI+g3U7UpzBPaPkV7En8GuHNoQ/oTm4v2on3MAXl8VbOEPs9+
wnWLuBQF+w51mYEfVumroJ2CP7EvTBnfnIKPwT+Aw/btKdmlwA/Xt6em3pRLeXn6CxL4Shki
GYjAHzrQzej3rGe5PCxf+PydgZ3+6ct/h2fzORkaHpfR8Qm0LSZ70X/p88WebhlEXKL9Dg8d
gw9MQpdpWXf2CukvdctLo2UZHZs09RqfqMgUaCnfLB9OCZCXR6A9Y6AE+2F/bag1PFaWkTHa
1+pMm0NTe0BPVBO+1CklxK47Pvd5LZGP3vJp2AbbccMG/YhT5fKYTCCm0d7sD5TZhV31irgL
WH7GSmP7WhW762GNKNqbB+1C32U7dCE2UzfGpS5Mas+hAzNGTqJNq/hNoY9XIa+YL8rA4DLY
rgt9GXJg654+zGmAB/pi3qyO2IPldtlw1S4EhjmYAAbt7ikYZ5qbm0YejQxjMEDTAdiJOUj0
9Q/I6tVrZGR0DLgIKTB6vlBCkJmW5RhUzn7VegwS3eisZWP4s846F5VfBlgJlegwg1U31oMf
HhmWInSgAWZ7GOAx1wJnYiUHGcQQPEEghe6icWA6HvWdRiPMYgOOAjY/58w+OwQ3QjcdYHYS
xgqdtgDeDHA0jgbSbgR0DmI9COQ9SHPCh+8iUzdUzwRVnDDa4raMHQ9l7Ezmy0jA6JBwV+MY
s7BTFYMRB6kJONM0bukKXfh6HYHQNCQbHrbp7Rs0AwkbkvUrgm8RNijoQAXb1TBAceDrw+PB
aTQsByPalAGNzrEWwbIPd4fcSasLOuToIKgr8+xsvEKZ6phCe6B9exDksVIlBwp2vhJ+E+gI
fIMiX+gydR8dHTF3nHzeyUG5BH3Iw6xJxnZFJyyhDVhbdsQOOCIHvhqC9DQG+akZdvoplNm1
92Ex0NNwsAE6dSFXNE5LetqTC59xWOHgMjOFQR+6wRion/3MswM+yGDPQauG+uNyBLwQZMAT
JODNgIi5OLRBPt9tbMQLHMotwjbsID04U4Vp6DaN3R5nu2Ar2I8/doQc/IX4HDCKxV7w6jId
t4D2yKMtRo4fg81mjS2Ix/qVejHAwMeMvdn21GeWg2kH5v3G5MwzzwRPe/BFjI0bN2p2Uc77
9++PyOxB8KA/s2/WEOjot3n4Hy+W6PMMBn3wdT344RYv9BgMRvOj0oELO15+cDBmEB8cXI6n
EKgv+x/8ixcZDM0V2H4G9mCGAwEsawYK8uKTC/bXGfgIL1zysCf7PI1VRb7Gtgah8QRE/1no
io5vdCjC5zsQtGjPHvRjcxGKMgblKQyAxSIHvALKObjYnXuoK52N/cl0RMQg+kseAz8v4Ogw
nehnbtss70eMQh8AU2y/gMCJmIDII6Plirz4fxXEE/SzwQF51ZoVkj/zDMSnManANrWxYZmo
on/Cn8bKiC+oCf15hrZBfWnH5QM9cu7qAVmzYsD02ReGRmSwOycr0e8PDw3LC0OjUsHWqfRN
xhNuijeAwegsXFyXzlgW0ZOxjDFiCn2AfaGnm/MdeTtA0v8A4wDNmGQuoBDkeeFbQHuzLzOO
2UAGaUiz/c0FOfow++fIyBHTd9jXO9EvutHnyI9tb30IA6mxNS6OeVEOm/4/xk/3di8LMxUA
AAAASUVORK5CYII=
--------------070906010909060804060007--

--------------050000050304080003000008--


From nobody Mon Sep 14 06:44:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCE01B5E4E for ; Mon, 14 Sep 2015 06:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0ZdEuf3BMgo for ; Mon, 14 Sep 2015 06:44:42 -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 A03421B5E3C for ; Mon, 14 Sep 2015 06:44:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B785C8FE; Mon, 14 Sep 2015 15:43:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HKtGMlBDJrH4; Mon, 14 Sep 2015 15:43:37 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 14 Sep 2015 15:43:37 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58F5720048; Mon, 14 Sep 2015 15:43:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JxIVLm_Rw-ze; Mon, 14 Sep 2015 15:43: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 62DC62004E; Mon, 14 Sep 2015 15:43:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D5B0537208AE; Mon, 14 Sep 2015 15:43:30 +0200 (CEST)
Date: Mon, 14 Sep 2015 15:43:30 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20150914134328.GC67363@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150914.151914.2175290465760083078.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 13:44:44 -0000

On Mon, Sep 14, 2015 at 03:19:14PM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Martin Bjorklund  wrote:
> > Hi,
> > 
> > I think we agreed that is ok for a YANG 1.1 module to import a YANG
> > 1.0 module.
> > 
> > But should it also be ok for a 1.0 module to import a 1.1 module?
> > 
> > If we make this illegal, we might run into problems.  For example,
> > ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
> > and the new version use YANG 1.1.  Is it ok for a server to implement
> > the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
> > answer is no, it means that we either have to update all modules to
> > 1.1 more or less at the same time (including vendor models!), or we
> > keep existing modules on 1.0 "forever".
> 
> I suggest we add this text:
> 
> -------------------
> 
> * Coexistence with YANG version 1
> 
> A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> and vice versa.

Vice versa? I assume you mean 'a YANG version 1 module MUST NOT
include a YANG version 1.1 submodule. Perhaps it is clearer to spell
this out explicitly?

> A YANG version 1 module or submodule MUST NOT import a YANG version
> 1.1 module by revision.
> 
> A YANG version 1.1 module or submodule MAY import a YANG version
> 1 module by revision.
> 
> A YANG version 1.1 module or submodule MAY import a YANG version 1
> module without revision, and vice versa.  This rule exists in order to
> allow implementations of existing YANG version 1 modules together with
> YANG version 1.1 modules.  Without this rule, updating a single module
> to YANG version 1.1 would have a cascading effect on modules that
> import it, requiring all of them to also be updated to YANG version
> 1.1, and so on.

Again, perhaps expand 'vice versa' to be very clear.

The interesting case here if I understand things correctly is a YANG
version 1 module or submodule importing from a YANG 1.1 module, which
is legal if the import is without a revision. Hm. So in order to avoid
a cascading effect, I have to avoid import by revision and then I am
golden? What about importing by revision the last revision that is
still YANG 1? I heard that may be troublesome with the YANG library
but then perhaps the problem is there? I mean, if I import something
that only exists in a 1.1 version, should I then not really upgrade to
1.1 as well? Would it not work if an import of ietf-interfaces from a
version 1 module simply resolves to the latest ietf-interfaces
revision that is still version 1?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 14 06:54:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B511B3498 for ; Mon, 14 Sep 2015 06:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2WUKaiEWIes for ; Mon, 14 Sep 2015 06:54:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F18841B504B for ; Mon, 14 Sep 2015 06:54:53 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id DE01A1AE0492; Mon, 14 Sep 2015 15:54:52 +0200 (CEST)
Date: Mon, 14 Sep 2015 15:54:59 +0200 (CEST)
Message-Id: <20150914.155459.2278672283743232721.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20150914134328.GC67363@elstar.local>
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local>
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: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 13:54:55 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Sep 14, 2015 at 03:19:14PM +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > Martin Bjorklund  wrote:
> > > Hi,
> > > 
> > > I think we agreed that is ok for a YANG 1.1 module to import a YANG
> > > 1.0 module.
> > > 
> > > But should it also be ok for a 1.0 module to import a 1.1 module?
> > > 
> > > If we make this illegal, we might run into problems.  For example,
> > > ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
> > > and the new version use YANG 1.1.  Is it ok for a server to implement
> > > the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
> > > answer is no, it means that we either have to update all modules to
> > > 1.1 more or less at the same time (including vendor models!), or we
> > > keep existing modules on 1.0 "forever".
> > 
> > I suggest we add this text:
> > 
> > -------------------
> > 
> > * Coexistence with YANG version 1
> > 
> > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> > and vice versa.
> 
> Vice versa? I assume you mean 'a YANG version 1 module MUST NOT
> include a YANG version 1.1 submodule. Perhaps it is clearer to spell
> this out explicitly?

Ok.

> 
> > A YANG version 1 module or submodule MUST NOT import a YANG version
> > 1.1 module by revision.
> > 
> > A YANG version 1.1 module or submodule MAY import a YANG version
> > 1 module by revision.
> > 
> > A YANG version 1.1 module or submodule MAY import a YANG version 1
> > module without revision, and vice versa.  This rule exists in order to
> > allow implementations of existing YANG version 1 modules together with
> > YANG version 1.1 modules.  Without this rule, updating a single module
> > to YANG version 1.1 would have a cascading effect on modules that
> > import it, requiring all of them to also be updated to YANG version
> > 1.1, and so on.
> 
> Again, perhaps expand 'vice versa' to be very clear.

Ok.

> The interesting case here if I understand things correctly is a YANG
> version 1 module or submodule importing from a YANG 1.1 module, which
> is legal if the import is without a revision. Hm. So in order to avoid
> a cascading effect, I have to avoid import by revision and then I am
> golden?

No you don't have to import by revision, according to the proposed rule.

> What about importing by revision the last revision that is
> still YANG 1?

Sure, this is ok.

> I heard that may be troublesome with the YANG library

No, this works fine w/ YANG library.

> but then perhaps the problem is there? I mean, if I import something
> that only exists in a 1.1 version, should I then not really upgrade to
> 1.1 as well?

Sure.  The use case is for example servers that implement ietf-ip
(which imports ietf-interfaces), and ietf-interfaces.  Suppose we
update ietf-interfaces to 1.1.  It should still be ok for a server to
implement ietf-ip with the new ietf-interfaces.

> Would it not work if an import of ietf-interfaces from a
> version 1 module simply resolves to the latest ietf-interfaces
> revision that is still version 1?

But that would mean either that a server is stuck implementing version
1 modules, or that the server must implement both the version 1 and
version 1.1 module - and we have already said that this isn't
possible.

A set of simpler rules would be:

   A YANG version 1.1 module MUST NOT include a version 1 module.
   A YANG version 1 module MUST NOT include a version 1.1 module.

   A YANG version 1.1 (sub)module MAY import a version 1 module.
   A YANG version 1 (sub)module MAY import a version 1.1 module.




/martin


From nobody Mon Sep 14 07:12:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193A11A1B6A for ; Mon, 14 Sep 2015 07:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpnfcIUYhQKI for ; Mon, 14 Sep 2015 07:12:14 -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 53FD41A1B0E for ; Mon, 14 Sep 2015 07:12:14 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1F6A08A3 for ; Mon, 14 Sep 2015 16:12:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id P56wa6oKYgGE for ; Mon, 14 Sep 2015 16:12:11 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 14 Sep 2015 16:12:11 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8577A20053 for ; Mon, 14 Sep 2015 16:12:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EvWHXzLYrx5G; Mon, 14 Sep 2015 16:12:10 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03C2D20048; Mon, 14 Sep 2015 16:12:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2B643372090A; Mon, 14 Sep 2015 16:12:06 +0200 (CEST)
Date: Mon, 14 Sep 2015 16:12:06 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20150914141206.GD67363@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 14:12:16 -0000

On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
 
> >> Let's look at a slightly more complex hypothetical case to tease
> >> out how folks *want* things to work.  Assume the following have
> >> been defined:
> >>
> >>   - base module M
> >>   - augmentation Q
> >>   - augmentation R
> >>
> >> On a server claiming to supporting the modules containing M, Q,
> >> and R, respectively, which of the following might one encounter
> >> concurrently?
> >>
> >>      - plain M
> >>      - M+Q
> >>      - M+R
> >>      - M+Q+R
> >
> >It depends on what you mean by "encounter" but in terms of datastore
> >validity the only possible answer IMO is M+Q+R.
> 
> By "encounter" I mean if a client asks the server for all of its Ms,
> and the server also supports Q and R, are all of the Ms *guaranteed*
> to be M+Q+R, or is it possible that some of the Ms might lack Q or
> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
> how would one model a system inhabited by a mixture of the four
> kinds of Ms?

Retrieval is easy since a client is going to ignore data it does not
understand and the server is expected to report what makes sense from
the server's perspective. The question is relevant for writing: Is a
client programmed based on M going to work even if a server supports
M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC
6020 wanted to achieve this by forbidding mandatory nodes in
augmentations.

Y26-02 says that a presence container may be used to avoid breaking an
old client. Frankly, it seems not totally clear to me what the
sentence in section 7.15 of RFC 6020 really means:

    If the target node is in another module, then nodes added by the
    augmentation MUST NOT be mandatory nodes (see Section 3.1).

Does this rule only apply to nodes directly added under the target
node or does it apply to the whole hierarchy added? In the later case,
this would still cause a problem with the presence container work
around.

The recent suggestion to replace MUST NOT with SHOULD NOT in this
sentence may be seen as a softer variant of Y26-01. However, I think
we would, in addition, have to describe when it is OK to have
mandatory nodes in augmentations and when not. Simply saying SHOULD
NOT instead of MUST NOT will not help people to understand the issues
around this.

When this issue was discussed in the past, it turned out to be
difficult to find someone to write the necessary text explaining when
augmenting mandatory nodes is safe and when not. Are we doing better
now?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 14 07:17:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1AB1A87BE for ; Mon, 14 Sep 2015 07:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDc9kL62x61r for ; Mon, 14 Sep 2015 07:16:59 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC4F1A87AE for ; Mon, 14 Sep 2015 07:16:58 -0700 (PDT)
Received: from [70.30.123.113] (helo=piccolo.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZbUYg-0005Mh-R7; Mon, 14 Sep 2015 15:16:38 +0100
Date: Mon, 14 Sep 2015 10:16:51 -0400
From: Rob Shakir 
To: "=?utf-8?Q?netmod=40ietf.org?=" , Benoit Claise , Kent Watsen 
Message-ID: 
In-Reply-To: <55F6C0EE.4010404@cisco.com>
References: <20150911213636.11309.79529.idtracker@ietfa.amsl.com>  <55F6C0EE.4010404@cisco.com>
X-Mailer: Airmail Beta (324)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 14:17:01 -0000

On 14 September 2015 at 08:43:53, Benoit Claise (bclaise=40cisco.com) wro=
te:

> Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
> required=3F
> Do we need to make the link between a config node and all the derived
> counters/statistics it influences, which might be in different YANG
> models btw=3F

Yes - we need to deterministically retrieve, for a particular configurati=
on object (e.g., interface, BGP peer) the set set of derived state nodes =
associated with it, such that we do not need to maintain complex mapping =
tables on the client side for this - and can efficiently query the server=
 for them.

=46or instance, knowing that we configured a BGP peer at =24SOMEROOT/bgp/=
neighbors/neighbor=5Bpeer-address=3D=E2=80=98192.0.2.1=E2=80=99=5D/config=
/=7Bleaf-set=7D then we would find the counters at=C2=A0=24SOMEROOT/bgp/n=
eighbors/neighbor=5Bpeer-address=3D=E2=80=98192.0.2.1=E2=80=99=5D/state/ =
- allows us to (based on the fact that we just configured a peer) retriev=
e the state and counters that a client application will likely want to ch=
eck without having to map to some other (set of locations).

Note that in previous discussions, it was expressed that this implied tha=
t the model had knowledge of how the protocol operates such that it was k=
nown that leaf A corresponding to some other derived-state leaf B. Howeve=
r, this isn=E2=80=99t true. As I expressed before, the intention is that =
it is possible for a NMS layer to easily retrieve the set of state object=
s that an interested client may require, without many disparate queries, =
based on the configuration path. The actual meaning may be completely unk=
nown to this layer.

The openconfig-opstate approach allows state and config to be defined in =
separate modules - since the =E2=80=98state=E2=80=99 module in this case =
can simply augment the relevant =E2=80=98state=E2=80=99 containers within=
 the config model.

Regards,
r.


From nobody Mon Sep 14 07:18:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45861A885D for ; Mon, 14 Sep 2015 07:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnvygfgy6zo4 for ; Mon, 14 Sep 2015 07:18:08 -0700 (PDT)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 A626F1A8851 for ; Mon, 14 Sep 2015 07:18:07 -0700 (PDT)
Received: by lbcao8 with SMTP id ao8so68104806lbc.3 for ; Mon, 14 Sep 2015 07:18:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=DxkzFsRg2Ks+EDASz7fhYN6M7fwEfO4C4f4reNzKIRc=; b=aguqyS6ayxGU3P06VsSoZUgPt5WKF9iCfqu7rhXrh7v+88ddLsGexiuQhR20EUxbq8 aFEZqv6O14X9nGZ6qQzJiW+UOVqLAsPnayj1ggULxdc77fIq3TMRaKPNrL1jpIrjrypo 8rVbxZ6gOoywWFMcW7Plh1Ero7iUEb4UYe1pJNygL2k2BMUS8wtG6KVZneabfMQARmmD f7vM47Zgc9frkKLFe/f7lZCusUxqJVNftOzHF5Azyz50r2r07mEiHNHnvSUnCQx9Us5o 6MPa6omFxBhbDN60XmsCmf3n2hWsM+LsPF2gE2saBlyDKELNXYS6HbI1cy9ip8CDGNlz VlPg==
X-Gm-Message-State: ALoCoQnq3P1zfRJYxodhgLGNXzy++34e14h9kax6l/9c5zz0Gy2XC5Rrgreujs23GKAS8IJ3j18h
MIME-Version: 1.0
X-Received: by 10.152.36.200 with SMTP id s8mr14292492laj.119.1442240285811; Mon, 14 Sep 2015 07:18:05 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 14 Sep 2015 07:18:05 -0700 (PDT)
In-Reply-To: <20150914082745.GE46546@elstar.local>
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>  <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>  <20150914082745.GE46546@elstar.local>
Date: Mon, 14 Sep 2015 07:18:05 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  Mahesh Jethanandani , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0160a9caeac029051fb5bb68
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 14:18:10 -0000

--089e0160a9caeac029051fb5bb68
Content-Type: text/plain; charset=UTF-8

Hi,

This raises the issue "how does the client know that a missing applied
value means
there is no applied value vs. the server does not know and does not support
reporting
the applied value for a particular leaf?"

None of the solutions allow a client to know that. The RPC-based solutions
can be fixed, but not the replicated config retrieved with .


Andy


On Mon, Sep 14, 2015 at 1:27 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Sep 11, 2015 at 08:48:55PM -0700, Andy Bierman wrote:
> >
> > All solutions expect the server to be able to determine applied status
> for
> > every leaf
> > in the intended config. All solutions require basically the same internal
> > API support
> > to check the relevant applied config or operational state.
> >
> > In every solution, the server will magically know how to check that the
> IP
> > address is active.
> > That's the point. It is better than forcing the client to know how to do
> > this for every type of server.
> >
> > IMO, this requirement is clear, and each draft has a solution approach
> for
> > this new API.
> >
>
> For resources residing somewhere in an OS kernel (e.g. IP addresses of
> an interface), a proper implementation would require that the kernel
> knows why the resource is there and not just the fact that the
> resource is there. If I take an average resource in the Linux kernel,
> then this information is not kept in the kernel. Daemons and user
> space application simply create and modify resources in the kernel and
> then the kernel does what it does. So how would I implement an applied
> datastore on such a kernel? One obvious option would be that I simply
> grab the operational state and I match it against the intended config
> and everything that matches I report as applied config. Of course,
> this may go wrong in certain cases if there are clashes or the mapping
> is not trivial 1:1. But unless the piece of code that manages the
> underlying resource has a way to maintain and manage meta information,
> this is probably the best an implementation will be able to do. Or am
> I missing something?
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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


Hi,

This raises the issue "how doe=
s the client know that a missing applied value means
there is no =
applied value vs. the server does not know and does not support reporting
the applied value for a particular leaf?"

None of the solutions allow a client to know that. The RPC-based solu=
tions
can be fixed, but not the replicated config retrieved with =
<get>.


Andy


On Mon, S=
ep 14, 2015 at 1:27 AM, Juergen Schoenwaelder <j.schoen=
waelder@jacobs-university.de> wrote:
On Fri, Sep 11, 2015 at 08:48:55PM -0700, Andy Bierman wrote:

>

> All solutions expect the server to be able to determine applied status=
 for

> every leaf

> in the intended config. All solutions require basically the same inter=
nal

> API support

> to check the relevant applied config or operational state.

>

> In every solution, the server will magically know how to check that th=
e IP

> address is active.

> That's the point. It is better than forcing the client to know how=
 to do

> this for every type of server.

>

> IMO, this requirement is clear, and each draft has a solution approach=
 for

> this new API.

>



For resources residing somewhere in an OS kernel (e.g. IP addresses of

an interface), a proper implementation would require that the kernel

knows why the resource is there and not just the fact that the

resource is there. If I take an average resource in the Linux kernel,

then this information is not kept in the kernel. Daemons and user

space application simply create and modify resources in the kernel and

then the kernel does what it does. So how would I implement an applied

datastore on such a kernel? One obvious option would be that I simply

grab the operational state and I match it against the intended config

and everything that matches I report as applied config. Of course,

this may go wrong in certain cases if there are clashes or the mapping

is not trivial 1:1. But unless the piece of code that manages the

underlying resource has a way to maintain and manage meta information,

this is probably the best an implementation will be able to do. Or am

I missing something?



/js



--

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/>





--089e0160a9caeac029051fb5bb68--


From nobody Mon Sep 14 07:55:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649B51B4B08 for ; Mon, 14 Sep 2015 07:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsMYHDWHRXjE for ; Mon, 14 Sep 2015 07:55:43 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 815F51B2E06 for ; Mon, 14 Sep 2015 07:55:43 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 54A2D1CC0181; Mon, 14 Sep 2015 16:55:44 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de
In-Reply-To: <20150914.155459.2278672283743232721.mbj@tail-f.com>
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 14 Sep 2015 16:55:43 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 14:55:46 -0000

Martin Bjorklund  writes:

> Juergen Schoenwaelder  wrote:
>> On Mon, Sep 14, 2015 at 03:19:14PM +0200, Martin Bjorklund wrote:
>> > Hi,
>> > 
>> > Martin Bjorklund  wrote:
>> > > Hi,
>> > > 
>> > > I think we agreed that is ok for a YANG 1.1 module to import a YANG
>> > > 1.0 module.
>> > > 
>> > > But should it also be ok for a 1.0 module to import a 1.1 module?
>> > > 
>> > > If we make this illegal, we might run into problems.  For example,
>> > > ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
>> > > and the new version use YANG 1.1.  Is it ok for a server to implement
>> > > the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
>> > > answer is no, it means that we either have to update all modules to
>> > > 1.1 more or less at the same time (including vendor models!), or we
>> > > keep existing modules on 1.0 "forever".
>> > 
>> > I suggest we add this text:
>> > 
>> > -------------------
>> > 
>> > * Coexistence with YANG version 1
>> > 
>> > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
>> > and vice versa.
>> 
>> Vice versa? I assume you mean 'a YANG version 1 module MUST NOT
>> include a YANG version 1.1 submodule. Perhaps it is clearer to spell
>> this out explicitly?
>
> Ok.
>
>> 
>> > A YANG version 1 module or submodule MUST NOT import a YANG version
>> > 1.1 module by revision.
>> > 
>> > A YANG version 1.1 module or submodule MAY import a YANG version
>> > 1 module by revision.
>> > 
>> > A YANG version 1.1 module or submodule MAY import a YANG version 1
>> > module without revision, and vice versa.  This rule exists in order to
>> > allow implementations of existing YANG version 1 modules together with
>> > YANG version 1.1 modules.  Without this rule, updating a single module
>> > to YANG version 1.1 would have a cascading effect on modules that
>> > import it, requiring all of them to also be updated to YANG version
>> > 1.1, and so on.
>> 
>> Again, perhaps expand 'vice versa' to be very clear.
>
> Ok.
>
>> The interesting case here if I understand things correctly is a YANG
>> version 1 module or submodule importing from a YANG 1.1 module, which
>> is legal if the import is without a revision. Hm. So in order to avoid
>> a cascading effect, I have to avoid import by revision and then I am
>> golden?
>
> No you don't have to import by revision, according to the proposed rule.
>
>> What about importing by revision the last revision that is
>> still YANG 1?
>
> Sure, this is ok.
>
>> I heard that may be troublesome with the YANG library
>
> No, this works fine w/ YANG library.
>
>> but then perhaps the problem is there? I mean, if I import something
>> that only exists in a 1.1 version, should I then not really upgrade to
>> 1.1 as well?
>
> Sure.  The use case is for example servers that implement ietf-ip
> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> update ietf-interfaces to 1.1.  It should still be ok for a server to
> implement ietf-ip with the new ietf-interfaces.
>
>> Would it not work if an import of ietf-interfaces from a
>> version 1 module simply resolves to the latest ietf-interfaces
>> revision that is still version 1?
>
> But that would mean either that a server is stuck implementing version
> 1 modules, or that the server must implement both the version 1 and
> version 1.1 module - and we have already said that this isn't
> possible.
>
> A set of simpler rules would be:
>
>    A YANG version 1.1 module MUST NOT include a version 1 module.
>    A YANG version 1 module MUST NOT include a version 1.1 module.
>
>    A YANG version 1.1 (sub)module MAY import a version 1 module.
>    A YANG version 1 (sub)module MAY import a version 1.1 module.

What about my proposal

https://mailarchive.ietf.org/arch/msg/netmod/_q3YcPR_KobOlFx5HWDA5Oa9oZo

Its advantage is that it doesn't automatically expose 1.0-only server to
1.1 stuff if a module that's imported without revision is upgraded to
1.1.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon Sep 14 07:59:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084251B484F for ; Mon, 14 Sep 2015 07:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDt_N2ebzBd6 for ; Mon, 14 Sep 2015 07:58:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8F1B2BB2 for ; Mon, 14 Sep 2015 07:58:58 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 783CF1AE0492; Mon, 14 Sep 2015 16:58:56 +0200 (CEST)
Date: Mon, 14 Sep 2015 16:59:03 +0200 (CEST)
Message-Id: <20150914.165903.1567404703327521708.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.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: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 14:59:00 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Juergen Schoenwaelder  wrote:
> >> On Mon, Sep 14, 2015 at 03:19:14PM +0200, Martin Bjorklund wrote:
> >> > Hi,
> >> > 
> >> > Martin Bjorklund  wrote:
> >> > > Hi,
> >> > > 
> >> > > I think we agreed that is ok for a YANG 1.1 module to import a YANG
> >> > > 1.0 module.
> >> > > 
> >> > > But should it also be ok for a 1.0 module to import a 1.1 module?
> >> > > 
> >> > > If we make this illegal, we might run into problems.  For example,
> >> > > ietf-ip imports ietf-interfaces.  Suppose we update ietf-interfaces
> >> > > and the new version use YANG 1.1.  Is it ok for a server to implement
> >> > > the 1.0 version of ietf-ip and 1.1 version of ietf-interfaces?  If the
> >> > > answer is no, it means that we either have to update all modules to
> >> > > 1.1 more or less at the same time (including vendor models!), or we
> >> > > keep existing modules on 1.0 "forever".
> >> > 
> >> > I suggest we add this text:
> >> > 
> >> > -------------------
> >> > 
> >> > * Coexistence with YANG version 1
> >> > 
> >> > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> >> > and vice versa.
> >> 
> >> Vice versa? I assume you mean 'a YANG version 1 module MUST NOT
> >> include a YANG version 1.1 submodule. Perhaps it is clearer to spell
> >> this out explicitly?
> >
> > Ok.
> >
> >> 
> >> > A YANG version 1 module or submodule MUST NOT import a YANG version
> >> > 1.1 module by revision.
> >> > 
> >> > A YANG version 1.1 module or submodule MAY import a YANG version
> >> > 1 module by revision.
> >> > 
> >> > A YANG version 1.1 module or submodule MAY import a YANG version 1
> >> > module without revision, and vice versa.  This rule exists in order to
> >> > allow implementations of existing YANG version 1 modules together with
> >> > YANG version 1.1 modules.  Without this rule, updating a single module
> >> > to YANG version 1.1 would have a cascading effect on modules that
> >> > import it, requiring all of them to also be updated to YANG version
> >> > 1.1, and so on.
> >> 
> >> Again, perhaps expand 'vice versa' to be very clear.
> >
> > Ok.
> >
> >> The interesting case here if I understand things correctly is a YANG
> >> version 1 module or submodule importing from a YANG 1.1 module, which
> >> is legal if the import is without a revision. Hm. So in order to avoid
> >> a cascading effect, I have to avoid import by revision and then I am
> >> golden?
> >
> > No you don't have to import by revision, according to the proposed rule.
> >
> >> What about importing by revision the last revision that is
> >> still YANG 1?
> >
> > Sure, this is ok.
> >
> >> I heard that may be troublesome with the YANG library
> >
> > No, this works fine w/ YANG library.
> >
> >> but then perhaps the problem is there? I mean, if I import something
> >> that only exists in a 1.1 version, should I then not really upgrade to
> >> 1.1 as well?
> >
> > Sure.  The use case is for example servers that implement ietf-ip
> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> > implement ietf-ip with the new ietf-interfaces.
> >
> >> Would it not work if an import of ietf-interfaces from a
> >> version 1 module simply resolves to the latest ietf-interfaces
> >> revision that is still version 1?
> >
> > But that would mean either that a server is stuck implementing version
> > 1 modules, or that the server must implement both the version 1 and
> > version 1.1 module - and we have already said that this isn't
> > possible.
> >
> > A set of simpler rules would be:
> >
> >    A YANG version 1.1 module MUST NOT include a version 1 module.
> >    A YANG version 1 module MUST NOT include a version 1.1 module.
> >
> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
> 
> What about my proposal
> 
> https://mailarchive.ietf.org/arch/msg/netmod/_q3YcPR_KobOlFx5HWDA5Oa9oZo
> 
> Its advantage is that it doesn't automatically expose 1.0-only server to
> 1.1 stuff if a module that's imported without revision is upgraded to
> 1.1.

But a 1.0 only server would only implement 1.0 modules so there
wouldn't be any problem there.

The problem with "upgraded to 1.1" is that I don't really understand
what exactly it means, and what does the server do if there are errors
in this process?


/martin


From nobody Mon Sep 14 08:02:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33291ACD02 for ; Mon, 14 Sep 2015 08:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaSChuMceT53 for ; Mon, 14 Sep 2015 08:02:43 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608CE1B3792 for ; Mon, 14 Sep 2015 08:02:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2D70AFE9; Mon, 14 Sep 2015 17:02:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gVkkroXR5gf2; Mon, 14 Sep 2015 17:02:41 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 14 Sep 2015 17:02:41 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22A8F2004E; Mon, 14 Sep 2015 17:02:41 +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 gwxzqIS3s8mI; Mon, 14 Sep 2015 17:02:40 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B14A320048; Mon, 14 Sep 2015 17:02:39 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 4E2003720AE4; Mon, 14 Sep 2015 17:02:35 +0200 (CEST)
Date: Mon, 14 Sep 2015 17:02:34 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20150914150234.GA67696@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150914.155459.2278672283743232721.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 15:02:46 -0000

On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> 
> Sure.  The use case is for example servers that implement ietf-ip
> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> update ietf-interfaces to 1.1.  It should still be ok for a server to
> implement ietf-ip with the new ietf-interfaces.
>

Is the confusion is between implements and imports here? The module
ietf-ip will _import_ an older version 1 ietf-interfaces while the
server _implements_ a newer version 1.1 ietf-interfaces module. Is
this not going to work?

> > Would it not work if an import of ietf-interfaces from a
> > version 1 module simply resolves to the latest ietf-interfaces
> > revision that is still version 1?
> 
> But that would mean either that a server is stuck implementing version
> 1 modules, or that the server must implement both the version 1 and
> version 1.1 module - and we have already said that this isn't
> possible.

But this seems only true if import === implemented.

> A set of simpler rules would be:
> 
>    A YANG version 1.1 module MUST NOT include a version 1 module.
>    A YANG version 1 module MUST NOT include a version 1.1 module.
> 
>    A YANG version 1.1 (sub)module MAY import a version 1 module.
>    A YANG version 1 (sub)module MAY import a version 1.1 module.

It is the last one we are discussing, no? I am trying again: Why is
the MAY needed? Why is it not sufficient for a version 1 module to
work with an import for (the latest) version 1 module?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 14 10:20:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC21B3CD3 for ; Mon, 14 Sep 2015 10:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2eutK3sKeZc for ; Mon, 14 Sep 2015 10:20:33 -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 473E01B2E00 for ; Mon, 14 Sep 2015 10:20:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8982; q=dns/txt; s=iport; t=1442251233; x=1443460833; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bOUo3csjXkc7tVOkoPcRrh+Whyb5K+vnmJP8ThVhZQI=; b=NwuJmQ9kOyvsp3Wls30nUZpvaTf5/vLcWTitoh4+s19HEIp/G0CqOLrs +8PwrGn5TwuB7e8zwnOfURxe0zPPQEwhqo2Nncdl2ByQP4giqE11EJrjZ oI9Zs7ckc+pbIrd1GTdsEgDyFWp1Z/5WtEnollZ101F4PPD9Yc/74yvyp w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CgBAARAfdV/xbLJq1dglaBIWm/PgELhS1KAoIHAQEBAQEBgQuEIwEBAQQBAQFrCRILDgoJJQ8CFicJBgEMBgIBAYgqDcp8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhH2EKhEBWIQsBYx4iF+FDYdxgUxGg22CfpIBY4IRHBaBPz0zAYk9gT8BAQE
X-IronPort-AV: E=Sophos;i="5.17,530,1437436800";  d="scan'208,217";a="605116952"
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; 14 Sep 2015 17:20:29 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8EHKTR6013773; Mon, 14 Sep 2015 17:20:29 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <20150911213636.11309.79529.idtracker@ietfa.amsl.com> 
From: Robert Wilton 
Message-ID: <55F701DF.50402@cisco.com>
Date: Mon, 14 Sep 2015 18:20:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010607000305020904000206"
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 17:20:35 -0000

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

Hi Kent, Tom,

I've added the 3 requirements issues that I raised on Friday.

I also added a further one based on some of the discussion over the weekend:

The definition of "applied configuration" is slightly vague, and there 
seems to be multiple interpretations of it on the WG alias, and hence a 
tighter specification of it would be useful.

In particular:

  * does it include support for templating (as per
    openconfig-netmod-opstate-01 section 7.3.)?
  * is it allowed to represent system created objects that have no
    corresponding configuration?
  * how does it relate to the state of the system after a equivalent
    synchronous config commit (if at all)?


Thanks,
Rob


On 11/09/2015 23:16, Kent Watsen wrote:
> The AD and chairs thought it best to formalize the consensus on the
> requirements a bit more.  So we created the I-D listed below to track and
> capture final consensus.
>
> Additionally, we want to use this GitHub issue tracker to track issues:
>
> 	https://github.com/netmod-wg/opstate-reqs/issues
>
> Consistent with Tom's earlier email, we want to collect any issues with
> these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
> you have an issue, in addition to posting it to the list, please consider
> adding it to the GitHub tracker, and let people know you did so.   Our
> goal is to close the issues as quickly as possible, some will go to DEAD
> while others may remain OPEN, based on WG consensus.
>
> Thanks,
> Kent & Tom
>
>
> On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" 
> wrote:
>
>> A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>> has been successfully submitted by Kent Watsen and posted to the
>> IETF repository.
>>
>> Name:		draft-chairs-netmod-opstate-reqs
>> Revision:	00
>> Title:		NETMOD Operational State Requirements
>> Document date:	2015-09-11
>> Group:		Individual Submission
>> Pages:		5
>> URL:
>> https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>> xt
>> Status:
>> https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>> Htmlized:
>> https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>>
>>
>> Abstract:
>>    This document captures consensus on operational state requirements by
>>    the NETMOD working group.
>>
>>                   
>>         
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


--------------010607000305020904000206
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Kent, Tom,

    

    I've added the 3 requirements issues that I raised on Friday.

    

    I also added a further one based on some of the discussion over the
    weekend:

    

    
The definition of "applied
      configuration" is slightly vague, and there seems to be multiple
      interpretations of it on the WG alias, and hence a tighter
      specification of it would be useful.

    
In particular:

    
    
      
  • does it include support for
        templating (as per openconfig-netmod-opstate-01 section 7.3.)?
    • 
      
  • is it allowed to represent
        system created objects that have no corresponding configuration?
    • 
      
  • how does it relate to the
        state of the system after a equivalent synchronous config commit
        (if at all)?
    • 
    

    

    Thanks,

    Rob

    

    

    
On 11/09/2015 23:16, Kent Watsen wrote:

    

    

      
The AD and chairs thought it best to formalize the consensus on the
requirements a bit more.  So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

	https://github.com/netmod-wg/opstate-reqs/issues

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so.   Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom


On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:



      

        
A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
has been successfully submitted by Kent Watsen and posted to the
IETF repository.

Name:		draft-chairs-netmod-opstate-reqs
Revision:	00
Title:		NETMOD Operational State Requirements
Document date:	2015-09-11
Group:		Individual Submission
Pages:		5
URL:            
https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
xt
Status:         
https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
Htmlized:       
https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00


Abstract:
  This document captures consensus on operational state requirements by
  the NETMOD working group.

                 
       


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.

The IETF Secretariat



      

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



    

    

  


--------------010607000305020904000206--


From nobody Mon Sep 14 10:22:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68FA1B395B for ; Mon, 14 Sep 2015 10:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzvgu4_34AQh for ; Mon, 14 Sep 2015 10:22:51 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF07D1A1BB4 for ; Mon, 14 Sep 2015 10:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2902; q=dns/txt; s=iport; t=1442251371; x=1443460971; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=unRPc3RGJ7nGyiAe4no5Alp04WdTUhXRcRnwSaXTt8c=; b=f+XPGj9wceD4cjx5OQsxtTK4+T1cP373t65GdNo48HcroUEL9SCyY7SS zSPMztWqs98Se2lB+2ZFeMVEWU/cQqr3cNIRWyFnFylqBFaSTpdlQQ3MM bdaatgdSTS/HsC2vZ3g1Sm7zSaBi0bcdc1/oJNq8C0oQtSllKJE2Xfur8 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaBABsAfdV/xbLJq1dwi+FHIJWAoF1EgEBAQEBAQGBCoQkAQEEOEARCxgJFg8JAwIBAgFFEwgBAYgqywwBAQEBBgIghnOEfYRCUheEFQEElVeMfoh9kgEoBzSEAj2LMAEBAQ
X-IronPort-AV: E=Sophos;i="5.17,529,1437436800"; d="scan'208";a="629724164"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Sep 2015 17:22:49 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8EHMmws021486 for ; Mon, 14 Sep 2015 17:22:49 GMT
To: netmod@ietf.org
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local>
From: Robert Wilton 
Message-ID: <55F7026B.5080304@cisco.com>
Date: Mon, 14 Sep 2015 18:22:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150914141206.GD67363@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 17:22:52 -0000

Hi Juergen,

On 14/09/2015 15:12, Juergen Schoenwaelder wrote:
> On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
>   
>>>> Let's look at a slightly more complex hypothetical case to tease
>>>> out how folks *want* things to work.  Assume the following have
>>>> been defined:
>>>>
>>>>    - base module M
>>>>    - augmentation Q
>>>>    - augmentation R
>>>>
>>>> On a server claiming to supporting the modules containing M, Q,
>>>> and R, respectively, which of the following might one encounter
>>>> concurrently?
>>>>
>>>>       - plain M
>>>>       - M+Q
>>>>       - M+R
>>>>       - M+Q+R
>>> It depends on what you mean by "encounter" but in terms of datastore
>>> validity the only possible answer IMO is M+Q+R.
>> By "encounter" I mean if a client asks the server for all of its Ms,
>> and the server also supports Q and R, are all of the Ms *guaranteed*
>> to be M+Q+R, or is it possible that some of the Ms might lack Q or
>> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
>> how would one model a system inhabited by a mixture of the four
>> kinds of Ms?
> Retrieval is easy since a client is going to ignore data it does not
> understand and the server is expected to report what makes sense from
> the server's perspective. The question is relevant for writing: Is a
> client programmed based on M going to work even if a server supports
> M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC
> 6020 wanted to achieve this by forbidding mandatory nodes in
> augmentations.
>
> Y26-02 says that a presence container may be used to avoid breaking an
> old client. Frankly, it seems not totally clear to me what the
> sentence in section 7.15 of RFC 6020 really means:
>
>      If the target node is in another module, then nodes added by the
>      augmentation MUST NOT be mandatory nodes (see Section 3.1).
>
> Does this rule only apply to nodes directly added under the target
> node or does it apply to the whole hierarchy added? In the later case,
> this would still cause a problem with the presence container work
> around.
>
> The recent suggestion to replace MUST NOT with SHOULD NOT in this
> sentence may be seen as a softer variant of Y26-01. However, I think
> we would, in addition, have to describe when it is OK to have
> mandatory nodes in augmentations and when not. Simply saying SHOULD
> NOT instead of MUST NOT will not help people to understand the issues
> around this.
>
> When this issue was discussed in the past, it turned out to be
> difficult to find someone to write the necessary text explaining when
> augmenting mandatory nodes is safe and when not. Are we doing better
> now?
I'm happy to give this a try - I have got a vested interest in relaxing 
this rule for the sub-interface model that I'm putting forward.

Thanks,
Rob

>
> /js
>


From nobody Mon Sep 14 11:14:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1F1B43BD for ; Mon, 14 Sep 2015 11:14:35 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABEaOQA4Tjca for ; Mon, 14 Sep 2015 11:14:33 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799301B40AC for ; Mon, 14 Sep 2015 11:14:33 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 14 Sep 2015 18:14:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Mon, 14 Sep 2015 18:14:29 +0000
From: Kent Watsen 
To: Lou Berger , Nadeau Thomas , Robert Wilton 
Thread-Topic: [netmod] Consensus Call Note for Requirements
Thread-Index: AQHQ7AmBdT4y4mv21E6JWMsKgHQq2543JsKAgAAWngCAABYugIAEw7EA
Date: Mon, 14 Sep 2015 18:14:29 +0000
Message-ID: 
References: <25E74703-B15C-4CE1-8FE3-A35EE875507B@lucidvision.com> <55F2B187.5030604@cisco.com> <6BE85265-0E47-4DED-A92D-B11A6FDDD08B@lucidvision.com> <55F2D71B.4050303@labn.net>
In-Reply-To: <55F2D71B.4050303@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:0RsDl7v8DqHinsAWabV8M0XtqaBMoXFsUHPErNPkLAiSHMuoCt6rpIFTtD+0pgPR0Lfnh9gb2gLmZrEb88Zow1kxqIO49bcJxnsIglFRq527vzDuVtvKsV4WXHYyRiKa5fK6ZQpnxGfA0p+T8H1hQA==; 24:tEivHFaP+PrN7rFEf6NlnbTVIZBQDibk2qNSIJpSf72WPH7swSrHG/A3G5x4jMzuxgNBU2iyayEkLW7hR4S1SMinpxUX9V9WATkr9WrFr/8=; 20:Tcae1vECNEyd/rZVWDKAlFeSsTjE4TpGtg/Q1Qm74h1FbH0FZeTsgIATbYmj8O2tReFJ0JfryGHlVEVtCJ3hLA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0699FCD394
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(377454003)(479174004)(199003)(40100003)(122556002)(99286002)(54356999)(76176999)(50986999)(5001860100001)(101416001)(5001770100001)(81156007)(93886004)(97736004)(36756003)(66066001)(4001540100001)(4001350100001)(5002640100001)(105586002)(106356001)(106116001)(5001960100002)(189998001)(5001830100001)(62966003)(19580405001)(102836002)(10400500002)(15975445007)(68736005)(77156002)(5007970100001)(2950100001)(19580395003)(5004730100002)(64706001)(92566002)(2900100001)(46102003)(86362001)(83506001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2015 18:14:29.2267 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Consensus Call Note for Requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 18:14:35 -0000

These GitHub issues were opened per this thread:

  - https://github.com/netmod-wg/opstate-reqs/issues/1
  - https://github.com/netmod-wg/opstate-reqs/issues/2
  - https://github.com/netmod-wg/opstate-reqs/issues/3

Thank you Rob!

Kent


On 9/11/15, 9:28 AM, "Lou Berger"  wrote:

>
>
>On 9/11/2015 8:09 AM, Nadeau Thomas wrote:
>>>> 3. Support for both transactional, synchronous management
>>>> >>   systems as well as distributed, asynchronous management
>>>> >>   systems
>>>> >>=20
>>>> >>    a. For asynchronous systems, the ability to request a protocol
>>>> >>        operation to not return (i.e. block) until the intended
>>>> >>        configuration has been fully synchronized.
>>> > I'm not sure why 3 (a) is a requirement, or its unclear to me where
>>>this is specified in the openconfig-netmod-opstate draft.
>> 	Anees/Rob, can you guys please add some color to the above
>>descriptions to help clarify things for Robert?
>I see (3) but not (3.a) in
>http://tools.ietf.org/html/draft-openconfig-netmod-opstate-01#section-4.2
>so am unsure how 3.a made it on the list.
>
>also, I don't object to 3.a if *users* say they need it.
>
>Lou
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Sep 14 11:37:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA631B4923 for ; Mon, 14 Sep 2015 11:37:12 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InEZVGUPVWfG for ; Mon, 14 Sep 2015 11:37:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CA41B48CF for ; Mon, 14 Sep 2015 11:37:01 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 14 Sep 2015 18:36:57 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Mon, 14 Sep 2015 18:36:57 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
Thread-Index: AQHQ7xxVsQc/svWyUEyF7cDHm/QsQw==
Date: Mon, 14 Sep 2015 18:36:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:JBXjyrSh2zKNa5L6L9bJHnTmZ4BxDY2mKd3iL8JitDgc9QPYl1g/bxRDZVvFNKUzCDnMDZVXPKgR1IF363Yh+REDx00DWZFXB/FYzCVVQpeTYBp5iTIB1ZJ50MVhL4Gns7eOilgekbUrnPR6dSYoSw==; 24:ERxCXk2/lcVVGahZtM8Eri224cCbyY3JKAvjbGvhtz3aEfgYhjPkvcwyTLUx7oW3mLAuqg3HXvAZfIchEvl1k2zxuUl8wNfjJsVsgnu6JdI=; 20:nonoi0Clzsyvd2B+XTlIKC8mPeJdPMiNoMNjvG0DS27b5qHlCHYMy38R5vuKOMqHidJGXcHhL6bLlRZalprXKA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0699FCD394
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377424004)(199003)(164054003)(377454003)(189002)(2900100001)(2501003)(101416001)(106116001)(97736004)(15975445007)(62966003)(66066001)(105586002)(99286002)(230783001)(87936001)(2351001)(102836002)(64706001)(86362001)(46102003)(36756003)(450100001)(40100003)(107886002)(19580395003)(5002640100001)(5001920100001)(122556002)(92566002)(5001830100001)(68736005)(77156002)(189998001)(19580405001)(4001540100001)(5001860100001)(5007970100001)(50986999)(83506001)(110136002)(81156007)(5001960100002)(106356001)(11100500001)(5004730100002)(4001350100001)(10400500002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2015 18:36:57.1004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 18:37:12 -0000

In case folks missed it, Appendix A (pasted below for convenience) roughly
describes where each requirement came from.  As it says, some liberty was
taken to adjust the text based on what looked liked consensus from on list
discussions; this is why they're not 1-1.  Regardless if our
interpretation is accurate, we will iterate this draft to consensus
(closing GitHub issues).


   Appendix A.  Relation to Requirements in Other Drafts

   The requirements in this document roughly map onto the requirements
   listed in [draft-openconfig-netmod-opstate-01] and
   [draft-openconfig-netmod-model-structure-00] as list below.  Some
   liberty was taken to adjust the requirements based on what looked
   liked consensus from on list discussions:

   1.  draft-openconfig-netmod-opstate-01, Section 3
   2.  draft-openconfig-netmod-opstate-01, Section 4.1
   3.  draft-openconfig-netmod-opstate-01, Section 4.2
   4.  draft-openconfig-netmod-opstate-01, Section 4.3
   5.  draft-openconfig-netmod-opstate-01, Section 4.4
   6.  draft-openconfig-netmod-opstate-01, Section 4.5
   7.  draft-openconfig-netmod-model-structure-00 (no section)


Kent


On 9/11/15, 6:16 PM, "Kent Watsen"  wrote:

>
>The AD and chairs thought it best to formalize the consensus on the
>requirements a bit more.  So we created the I-D listed below to track and
>capture final consensus.
>
>Additionally, we want to use this GitHub issue tracker to track issues:
>
>	https://github.com/netmod-wg/opstate-reqs/issues
>
>Consistent with Tom's earlier email, we want to collect any issues with
>these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
>you have an issue, in addition to posting it to the list, please consider
>adding it to the GitHub tracker, and let people know you did so.   Our
>goal is to close the issues as quickly as possible, some will go to DEAD
>while others may remain OPEN, based on WG consensus.
>
>Thanks,
>Kent & Tom
>
>
>On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" 
>wrote:
>
>>
>>A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>>has been successfully submitted by Kent Watsen and posted to the
>>IETF repository.
>>
>>Name:		draft-chairs-netmod-opstate-reqs
>>Revision:	00
>>Title:		NETMOD Operational State Requirements
>>Document date:	2015-09-11
>>Group:		Individual Submission
>>Pages:		5
>>URL:           =20
>>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.
>>t
>>xt
>>Status:        =20
>>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>>Htmlized:      =20
>>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>>
>>
>>Abstract:
>>   This document captures consensus on operational state requirements by
>>   the NETMOD working group.
>>
>>                =20
>>       =20
>>
>>
>>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.
>>
>>The IETF Secretariat
>>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Sep 14 12:02:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B231B512F for ; Mon, 14 Sep 2015 12:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_Y-BI55ivtQ for ; Mon, 14 Sep 2015 12:02:01 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3761B50EF for ; Mon, 14 Sep 2015 12:01:51 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Mon, 14 Sep 2015 19:01:48 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Mon, 14 Sep 2015 19:01:48 +0000
From: Kent Watsen 
To: Rob Shakir , "netmod@ietf.org" , "Benoit Claise" 
Thread-Topic: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification
Thread-Index: AQHQ7ur1hM45b0q11kqSdKg3Nl+5op48EimAgAAMiwA=
Date: Mon, 14 Sep 2015 19:01:48 +0000
Message-ID: 
References: <20150911213636.11309.79529.idtracker@ietfa.amsl.com>  <55F6C0EE.4010404@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:KuZnWnSZIpipDV2zvOlCSUJglzz8Hm51frRIKvdPu8x/y0ZTEidXPQgVHN2D2l8e33v4RxPXqzyY0JHyLprI9MGKV1CCLYa3vqsUiQY23+XcYma3pUY1/yFFkZTKw6UwzGHseqe6LaxkuAqkdgx40A==; 24:EgSKVhtTkCzWoiM78yRQ/hNqcB0VsZAG2yp7k2j5/XELtF8ch7k5NNgB23GXvjEfIcprresYR+Z7h9dw+gc/nqr9ft9LvduTGr1gRxh+nCU=; 20:4R0AOjswq4BSqcmGOmQNJVj6EaqKC/RK7zLUc9YZgrAW1Nv2UL6aixXjJBHylIrrZKzjslLXyh76MCBOpbjRrQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520058)(8121501046)(520071)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0699FCD394
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(57704003)(24454002)(199003)(479174004)(189002)(377454003)(62966003)(5001830100001)(97736004)(106356001)(46102003)(93886004)(10400500002)(230783001)(4001350100001)(5002640100001)(83506001)(4001540100001)(81156007)(77156002)(5001770100001)(11100500001)(107886002)(50986999)(5007970100001)(101416001)(40100003)(5001960100002)(5001920100001)(5001860100001)(2950100001)(122556002)(87936001)(92566002)(189998001)(66066001)(2501003)(86362001)(105586002)(102836002)(2900100001)(76176999)(54356999)(36756003)(106116001)(5004730100002)(19580395003)(99286002)(68736005)(64706001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8D7139D9BBDA164C9070E3004B60D86F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2015 19:01:48.6752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 19:02:02 -0000

Rob, thanks for clarifying the need for 6B.

No new GitHub issues filed for this thread.

Kent


On 9/14/15, 10:16 AM, "Rob Shakir"  wrote:

>
>On 14 September 2015 at 08:43:53, Benoit Claise (bclaise@cisco.com) wrote:
>
>> Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
>> required?
>> Do we need to make the link between a config node and all the derived
>> counters/statistics it influences, which might be in different YANG
>> models btw?
>
>Yes - we need to deterministically retrieve, for a particular
>configuration object (e.g., interface, BGP peer) the set set of derived
>state nodes associated with it, such that we do not need to maintain
>complex mapping tables on the client side for this - and can efficiently
>query the server for them.
>
>For instance, knowing that we configured a BGP peer at
>$SOMEROOT/bgp/neighbors/neighbor[peer-address=3D=8C192.0.2.1=B9]/config/{l=
eaf-se
>t} then we would find the counters at
>$SOMEROOT/bgp/neighbors/neighbor[peer-address=3D=8C192.0.2.1=B9]/state/ -
>allows us to (based on the fact that we just configured a peer) retrieve
>the state and counters that a client application will likely want to
>check without having to map to some other (set of locations).
>
>Note that in previous discussions, it was expressed that this implied
>that the model had knowledge of how the protocol operates such that it
>was known that leaf A corresponding to some other derived-state leaf B.
>However, this isn=B9t true. As I expressed before, the intention is that i=
t
>is possible for a NMS layer to easily retrieve the set of state objects
>that an interested client may require, without many disparate queries,
>based on the configuration path. The actual meaning may be completely
>unknown to this layer.
>
>The openconfig-opstate approach allows state and config to be defined in
>separate modules - since the =8Cstate=B9 module in this case can simply
>augment the relevant =8Cstate=B9 containers within the config model.
>
>Regards,
>r.


From nobody Mon Sep 14 12:13:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660BD1A882A for ; Mon, 14 Sep 2015 12:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw3Gkmt2eXcO for ; Mon, 14 Sep 2015 12:13:01 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345191A871C for ; Mon, 14 Sep 2015 12:13:01 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 14 Sep 2015 19:13:00 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Mon, 14 Sep 2015 19:12:59 +0000
From: Kent Watsen 
To: Andy Bierman , Juergen Schoenwaelder , Mahesh Jethanandani , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Thread-Index: AQHQ7AEVCg+MZeG0iU+zGTFxaXBXRp42ZLWAgAAmToCAAGbCAIAAl/AAgABWgYCAAGOsgIADcpGAgABh4oCAAA9RAA==
Date: Mon, 14 Sep 2015 19:12:59 +0000
Message-ID: 
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>  <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>  <20150914082745.GE46546@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:TlGt4r7e8W4zWUp9/8iaVX0Ibl/6WbACf31y8zght05eJ1zCgva8lzolb/YO/BVpKqjhVV0akeaAQLxZq4m2DyHBE2FdrJD6Co0ycDv+pIdfyyAnwQdQFdiUd4lk/2oL2525ipurGKcfKuvN9DCrbg==; 24:gfKRsdHMR58v+szqlOuErNk7/sVhzUhGUstEbihrKoimqdewv0qtGE3v3dZFdZ9+JW+WBxK695LxXjb+uRSLmnHwZbpM5q3jg6iKFnuAdtg=; 20:4a2n0mWuGGRPDwFdyz4IrA4HLKPUOz/jV9zkxx287OpRUrs2NtddZkocl/zkU8GqMWxVXeYPPabEplXbGjvzHQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0699FCD394
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(64706001)(2900100001)(92566002)(5007970100001)(10400500002)(68736005)(77156002)(5004730100002)(2950100001)(87936001)(83506001)(86362001)(230783001)(46102003)(54356999)(50986999)(76176999)(101416001)(16236675004)(5001860100001)(5001920100001)(122556002)(40100003)(99286002)(107886002)(105586002)(4001350100001)(102836002)(62966003)(106356001)(189998001)(106116001)(5001830100001)(5001960100002)(5002640100001)(2501003)(93886004)(81156007)(5001770100001)(4001540100001)(97736004)(36756003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D21C9387DA307kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2015 19:12:59.3904 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 19:13:02 -0000

--_000_D21C9387DA307kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[As a contributor]

> This raises the issue "how does the client know that a missing applied
> value means there is no applied value vs. the server does not know
>  and does not support reporting the applied value for a particular leaf?"
>
> None of the solutions allow a client to know that.

draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
Applied Configuration capability so the client to tell, doesn't this count?

> Andy

Kent




--_000_D21C9387DA307kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







[As a contributor]














> This raises the issue "how does the client know that a missi=
ng applied









> value means there is no applied value vs. the server does not kno=
w


>  and does not support reporting the applied value for a part=
icular leaf?"





>


> None of the solutions allow a client to know that.










draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an =
;


Applied Configuration capability so the client to tell, doesn't this c=
ount?










> Andy













Kent
































--_000_D21C9387DA307kwatsenjunipernet_--


From nobody Mon Sep 14 12:18:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB021B2CF8 for ; Mon, 14 Sep 2015 12:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1MgyIKlvuBe for ; Mon, 14 Sep 2015 12:18:03 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EA41B2D77 for ; Mon, 14 Sep 2015 12:18:02 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 14 Sep 2015 19:18:00 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Mon, 14 Sep 2015 19:18:00 +0000
From: Kent Watsen 
To: Kent Watsen , Andy Bierman , Juergen Schoenwaelder , "Mahesh Jethanandani" , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
Thread-Index: AQHQ7AEVCg+MZeG0iU+zGTFxaXBXRp42ZLWAgAAmToCAAGbCAIAAl/AAgABWgYCAAGOsgIADcpGAgABh4oCAAA9RAIAAAWCA
Date: Mon, 14 Sep 2015 19:18:00 +0000
Message-ID: 
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>  <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>  <20150914082745.GE46546@elstar.local>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:y4fZOzK2qj9su5y6IMHfFxPNdErT43z220tZ8iSOYmKNQssKoLJLihGRc3dasUCO16xQEfPs4501SlKolDsK3YpYf0kGN8cGkslq7gKFpzPHXnv7Ipi4WhGBDTdxp8rJmshRRxMjrtJPruv5SGJ1Ig==; 24:v5z/4xhq3+f8dHmHqG+sPCMrxJPEaoARVG5nVKW/qOXNpMB75D7X3on4axJSDyXyTk+OgU3kYUQufbnGdLpd6CxBULdqQqQAHMrl2iP5f/o=; 20:WTGsd7+ZBoxQhZ2xaP11O2o+fkx0n9HbOoXoOorLNb1t4SE0d4Xfoorv0rR9aZBijsFOmPekWAPfgQ6qUEXVsA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0699FCD394
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(43784003)(199003)(40100003)(122556002)(99286002)(54356999)(76176999)(50986999)(5001860100001)(16236675004)(101416001)(5001770100001)(81156007)(2501003)(93886004)(97736004)(36756003)(66066001)(4001540100001)(4001350100001)(19617315012)(105586002)(107886002)(106356001)(189998001)(5001960100002)(5002640100001)(106116001)(5001830100001)(102836002)(62966003)(11100500001)(19580405001)(10400500002)(15975445007)(68736005)(77156002)(5007970100001)(2950100001)(19580395003)(5004730100002)(1941001)(64706001)(92566002)(2900100001)(230783001)(46102003)(86362001)(87936001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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)
Content-Type: multipart/alternative; boundary="_000_D21C94AFDA323kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2015 19:18:00.1079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 19:18:05 -0000

--_000_D21C94AFDA323kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


GitHub issue #4 has been raised to track the predominant concern raised in =
this thread:

https://github.com/netmod-wg/opstate-reqs/issues/4

Thanks again Rob!

Kent

From: Kent Watsen >
Date: Monday, September 14, 2015 at 3:12 PM
To: Andy Bierman >, Juergen S=
choenwaelder >, Mahesh Jethanandani >, "netmod@ietf.org" >
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod=
-opstate-01

[As a contributor]

> This raises the issue "how does the client know that a missing applied
> value means there is no applied value vs. the server does not know
>  and does not support reporting the applied value for a particular leaf?"
>
> None of the solutions allow a client to know that.

draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
Applied Configuration capability so the client to tell, doesn't this count?

> Andy

Kent




--_000_D21C94AFDA323kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <06AF49A6A0132046874CB365B9419F5B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














GitHub issue #4 has been raised to track the predominant concern raised in =
this thread:














Thanks again Rob!







Kent










From: Kent Watsen <kwatsen@juniper.net>

Date: Monday, September 14, 2015 at=
 3:12 PM

To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder &=
lt;j.schoenwaelder@=
jacobs-university.de>, Mahesh Jethanandani
 <mjethanandani@gmail.com=
>, "netmod@ietf.org" &l=
t;netmod@ietf.org>

Subject: Re: [netmod] YANG coordina=
tion feedback on draft-openconfig-netmod-opstate-01













[As a contributor]














> This raises the issue "how does the client know that a missi=
ng applied









> value means there is no applied value vs. the server does not kno=
w


>  and does not support reporting the applied value for a part=
icular leaf?"





>


> None of the solutions allow a client to know that.










draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an =
;


Applied Configuration capability so the client to tell, doesn't this c=
ount?










> Andy













Kent




































--_000_D21C94AFDA323kwatsenjunipernet_--


From nobody Mon Sep 14 12:39:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE48C1B4478 for ; Mon, 14 Sep 2015 12:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPZElAgrc99q for ; Mon, 14 Sep 2015 12:39:22 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 F069E1B3518 for ; Mon, 14 Sep 2015 12:39:21 -0700 (PDT)
Received: by lbbvu2 with SMTP id vu2so977760lbb.0 for ; Mon, 14 Sep 2015 12:39:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CEuWY7u/jeVAr5BQBwgCM2k733gSGroO8BsEQia0XfU=; b=Eg4qJCctiOmzMyiVoIfw5IVnuayaVwttRMro1naBHLGrdAZA/vNTuBotqUhfyGeEES lcmp/3QtMp7mjPWDe2Vyx5vdSS8t3AMzNbXhGu0tqDtScywXt8SRuv+D955Amva2Z/pA aMfa5awADkWB+8yrHaYyQbKXKnpRJ+/X4IV+hLdjh2ZQpLdnX+L6KUawI4WnKFG+28Ks EY/KzUgt1svctVMID09x5dF/a7NRrcS1YXSdeS567W79lT06ZxHViEXr/qDSHoGlqYTp 6SfzSQBzgqQ1sVivF3bIAvl8/+VvQfT99Q5N9WZamChVXxL8kjY1HbgIRV3DSI+juAvY 6fbQ==
X-Gm-Message-State: ALoCoQmCkdW3jfWZ2qy/YkR45qBD+HcdGwP2auG3rcYw+JoDpIObnCB6sguneAVRmhRthmzs8Lna
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr15505875lbc.123.1442259560104;  Mon, 14 Sep 2015 12:39:20 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 14 Sep 2015 12:39:19 -0700 (PDT)
In-Reply-To: 
References: <8EB9E89D-7955-4B00-9910-2DADE4CEFFF4@cisco.com> <50F53BDE-0B2A-4FBB-BA0C-F05A752AFBA1@gmail.com> <15E410A7-B372-4889-B0ED-4613F3C2FA5B@gmail.com> <20150911.093846.709202940600841233.mbj@tail-f.com>  <99731F17-8AE4-455C-8450-EC93729537AB@gmail.com>  <20150914082745.GE46546@elstar.local>  
Date: Mon, 14 Sep 2015 12:39:19 -0700
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=001a11c26650c12172051fba389e
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 19:39:24 -0000

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

On Mon, Sep 14, 2015 at 12:12 PM, Kent Watsen  wrote:

> [As a contributor]
>
> > This raises the issue "how does the client know that a missing applied
> > value means there is no applied value vs. the server does not know
> >  and does not support reporting the applied value for a particular leaf?"
> >
> > None of the solutions allow a client to know that.
>
> draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
> Applied Configuration capability so the client to tell, doesn't this count?
>
>

This is a global flag.
All solutions ignore the possibility that the server is capable of
detecting the
current corresponding active value for a subset of all data nodes.

I think the wilton draft is easiest to fix.
It avoids the problem of "what does a missing applied node mean?"
For each indented config node, attributes can be returned to indicate:

    - status known? yes/no
    - unknown status temporary?  yes/no

The attribute return values can be quite deterministic with this extra info.



> > Andy
>
> Kent
>
>
>
>

Andy

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




On Mon, Sep 14, 2015 at 12:12 PM, Kent Watsen <kwatsen@juniper.net> wrote:







[As a contributor]














> This raises the issue "how does the client know that a missi=
ng applied









> value means there is no applied value vs. the server does not kno=
w


> =C2=A0and does not support reporting the applied value for a part=
icular leaf?"





>


> None of the solutions allow a client to know that.










draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an=C2=
=A0


Applied Configuration capability so the client to tell, doesn't th=
is count?





This i=
s a global flag.
All solutions ignore the possibility that the se=
rver is capable of detecting the
current corresponding active val=
ue for a subset of all data nodes.

I think the wil=
ton draft is easiest to fix.
It avoids the problem of "what =
does a missing applied node mean?"
For each indented config =
node, attributes can be returned to indicate:

=C2=
=A0 =C2=A0 - status known? yes/no
=C2=A0 =C2=A0 - unknown status =
temporary? =C2=A0yes/no

The attribute return value=
s can be quite deterministic with this extra info.

=C2=A0








--001a11c26650c12172051fba389e--


From nobody Mon Sep 14 13:52:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561831B2F29 for ; Mon, 14 Sep 2015 13:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn1XJ7quQNkq for ; Mon, 14 Sep 2015 13:52:31 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F581A1BE9 for ; Mon, 14 Sep 2015 13:51:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108; q=dns/txt; s=iport; t=1442263900; x=1443473500; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NNBqQkkd2UeKmXRxS5NMSQwXfyFpc9S4ydyWkC5AAZE=; b=VuEpSOkbfPphPcuw0pXPInZIsIm5j0oCBC5T1kjWziX1hE+sYfynG9n6 62dQ+oCOqpp1/I+YeYNdbCdNdVPoSgBjU406ku+2Ap+39blzpms26hTwj aS/wprg3PfuDnI4n/AQEeBpNJtHiOL9C8zi/bWguyKuo6aHqDk8UswpMx 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlAgCXMvdV/4cNJK1dgyNUb709AQ2BeYc4OBQBAQEBAQEBgQqEKjpRAT4FPScEiEENpyakCgEBAQEBAQEDAQEBAQEBGASGc4IPgm6ILIEUBZVXAXKEGodxmn4fAQFCgkOBPoppgQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,531,1437436800"; d="scan'208";a="28835268"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 14 Sep 2015 20:51:40 +0000
Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8EKpdiD010567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Sep 2015 20:51:39 GMT
Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Sep 2015 15:51:39 -0500
Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-rcd-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 14 Sep 2015 15:51:38 -0500
Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Mon, 14 Sep 2015 15:51:32 -0500
From: "Carl Moberg (camoberg)" 
To: NETMOD Working Group 
Thread-Topic: New issue #5 "Support for situations when structure of intended configuration is not the same as applied"
Thread-Index: AQHQ7y8iQBlktupzqkWOfba9q4Jccg==
Date: Mon, 14 Sep 2015 20:51:31 +0000
Message-ID: <3AD89B70-92FA-4D2E-9150-5C7FB31C0DCF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.102.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <541AD65E54E64A4F9F69761A66C9EB4E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] New issue #5 "Support for situations when structure of intended configuration is not the same as applied"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 20:52:32 -0000

 I have opened a new issue #5 on the opstate-reqs:
  https://github.com/netmod-wg/opstate-reqs/issues/5


From nobody Mon Sep 14 14:03:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC61B2ABB for ; Mon, 14 Sep 2015 14:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rki9KV_lgFH for ; Mon, 14 Sep 2015 14:03:38 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A371B3AFB for ; Mon, 14 Sep 2015 14:03:37 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Mon, 14 Sep 2015 21:03:35 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.01.0262.022; Mon, 14 Sep 2015 21:03:35 +0000
From: Kent Watsen 
To: Benoit Claise , Jonathan Hansford , "netmod@ietf.org" 
Thread-Topic: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
Thread-Index: AQHQ7NnysQc/svWyUEyF7cDHm/QsQ543okqAgAQpgoCAAC+wAIAASV6A
Date: Mon, 14 Sep 2015 21:03:34 +0000
Message-ID: 
References: <086460742009f24c7cb566cc4652d26bc9dcd52b@webmail.hansfords.net> <55F6C056.5040802@cisco.com>
In-Reply-To: <55F6C056.5040802@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:od8B/qjg+UQIF6TdCQrW/Tp48zM5xdkVCsZ3L6eUWm7k7E+x9EqOiMeiBorns554Jl+Y1teCL/A8ZOBFoJExnR8P0fDal3w8nkwANsxhm6Sh75SL0wSzQPTQg28HepnsxRuScAtTwPtgqqPvbVAY9A==; 24:5zgCfvtBJHJbF9j/umyi4ssvVQPBNuzUG/e4ZHHtRMeVDpyBF1M6kJB3olxqe9LLItdxjO+uVWmBX1Dmp/FdFgF+DmCYrwuargp/RDzSLII=; 20:FZzkyoJPQnzIaREf9Z9XCk4Vh5LzujOivMv0hxMtLFLy8B7wHEbmcgL6tOIFks+/wge24XKwhogG3EbkxKFRNA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520058)(520078)(8121501046)(5005006)(520075)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0699FCD394
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(164054003)(24454002)(199003)(13464003)(479174004)(189002)(377454003)(5007970100001)(62966003)(5001830100001)(106356001)(97736004)(46102003)(10400500002)(230783001)(5002640100001)(4001350100001)(83506001)(4001540100001)(81156007)(77156002)(19617315012)(5001770100001)(50986999)(11100500001)(107886002)(40100003)(5001960100002)(101416001)(5001920100001)(5001860100001)(2950100001)(189998001)(122556002)(87936001)(92566002)(2501003)(86362001)(66066001)(105586002)(102836002)(15975445007)(2900100001)(76176999)(54356999)(36756003)(106116001)(16236675004)(5004730100002)(19580395003)(99286002)(68736005)(64706001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D21C9A38DA393kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2015 21:03:34.6696 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 21:03:41 -0000

--_000_D21C9A38DA393kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I added an issue to track each of Jonathan's points:

https://github.com/netmod-wg/opstate-reqs/issues/6
https://github.com/netmod-wg/opstate-reqs/issues/7

Cheers,
Kent


From: Benoit Claise >
Date: Monday, September 14, 2015 at 8:40 AM
To: Jonathan Hansford >, Kent Watsen >, "netmod@=
ietf.org" >
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-=
opstate-reqs-00.txt

Jonathan,
Looking in from outside the current problem domain I'm not sure I'm suffici=
ently informed to comment, however I have a couple of queries:

  1.  The requirements talk about both synchronous and asynchronous systems=
 (1(D), 3, 3(A)) but really only address the behaviour for asynchronous sys=
tems. Would it not be worth clarifying the relationship between the intende=
d and applied configurations for synchronous systems (i.e. they are the sam=
e), hence there is no need for synchronous requirements equivalent to 1(D) =
and 3(A)?
  2.  Why does 7(A) limit the scope to IETF-defined modules of others are n=
ow defining YANG modules?

Good point. We need to provide guidance for the other SDOs.

Regards, Benoit
Thanks,

Jonathan

----- Original Message -----
From:
"Kent Watsen" 

To:
"netmod@ietf.org"
Cc:

Sent:
Fri, 11 Sep 2015 22:16:40 +0000
Subject:
[netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-=
00.txt



The AD and chairs thought it best to formalize the consensus on the
requirements a bit more. So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

https://github.com/netmod-wg/opstate-reqs/issues

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST. If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so. Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom


On 9/11/15, 5:36 PM, "internet-drafts@ietf.org" 
wrote:

>
>A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>has been successfully submitted by Kent Watsen and posted to the
>IETF repository.
>
>Name: draft-chairs-netmod-opstate-reqs
>Revision: 00
>Title: NETMOD Operational State Requirements
>Document date: 2015-09-11
>Group: Individual Submission
>Pages: 5
>URL:
>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>xt
>Status:
>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>Htmlized:
>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>
>
>Abstract:
> This document captures consensus on operational state requirements by
> the NETMOD working group.
>
>
>
>
>
>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.
>
>The IETF Secretariat
>

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



_______________________________________________
netmod mailing list
netmod@ietf.orghttps://www.ietf.org/mailman/listinf=
o/netmod


--_000_D21C9A38DA393kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable














I added an issue to track each of Jonathan's points:
















Cheers,



Kent
















From: Benoit Claise <bclaise@cisco.com>

Date: Monday, September 14, 2015 at=
 8:40 AM

To: Jonathan Hansford <jonathan@hansfords.net>, Kent Wat=
sen <kwatsen@juniper.net>,=
 "netmod@ietf.org"
 <netmod@ietf.org>

Subject: Re: [netmod] FW: New Versi=
on Notification for draft-chairs-netmod-opstate-reqs-00.txt













Jonathan,





Looking in from outside the current problem domain I'm not sure I'm suffici=
ently informed to comment, however I have a couple of queries:



    

  1. The requirements talk about both synchronous and asynchronous systems (=
1(D), 3, 3(A)) but really only address the behaviour for asynchronous syste=
ms. Would it not be worth clarifying the relationship between the intended =
and applied configurations for synchronous
 systems (i.e. they are the same), hence there is no need for synchronous r=
equirements equivalent to 1(D) and 3(A)?

  2. Why does 7(A) limit the scope to IETF-defined modules of others ar=
e now defining YANG modules?






Good point. We need to provide guidance for the other SDOs.



Regards, Benoit




Thanks,







Jonathan




----- Original Message -----




From:

"Kent Watsen" 
<kwatsen@juniper.net>




To:

"ne=
tmod@ietf.org"<netmod@ietf.org>


Cc:




Sent:

Fri, 11 Sep 2015 22:16:40 +0000


Subject:

[netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-=
00.txt







The AD and chairs thought it best to formalize the consensus on the

requirements a bit more. So we created the I-D listed below to track and
capture final consensus.



Additionally, we want to use this GitHub issue tracker to track issues:



https://github.com/netmod-wg/opstate-reqs/issues



Consistent with Tom's earlier email, we want to collect any issues with

these requirements before EOB Monday, September 14, 2015 at 5PM EST. If

you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so. Our

goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.



Thanks,

Kent & Tom





On 9/11/15, 5:36 PM, 
"internet-drafts@ietf.org" 
<internet-drafts@ietf.org>

wrote:



>

>A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt

>has been successfully submitted by Kent Watsen and posted to the

>IETF repository.

>

>Name: draft-chairs-netmod-opstate-reqs

>Revision: 00

>Title: NETMOD Operational State Requirements

>Document date: 2015-09-11

>Group: Individual Submission

>Pages: 5

>URL: 

>https://www.ietf.org/intern=
et-drafts/draft-chairs-netmod-opstate-reqs-00.t

>xt

>Status: 

>https://datatracker.ietf.org/doc/dr=
aft-chairs-netmod-opstate-reqs/

>Htmlized: 

>https://tools.ietf.org/html/draft-chai=
rs-netmod-opstate-reqs-00

>

>

>Abstract:

> This document captures consensus on operational state requirements by<=
br>
> the NETMOD working group.

>

> 

> 

>

>

>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.
>

>The IETF Secretariat

>



_______________________________________________

netmod mailing list

netmo=
d@ietf.org

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








 


_______________________________________________
netmod mailing list
netmo=
d@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod













--_000_D21C9A38DA393kwatsenjunipernet_--


From nobody Mon Sep 14 14:12:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91E1A21A6 for ; Mon, 14 Sep 2015 14:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JMZ548DrqEH for ; Mon, 14 Sep 2015 14:12:28 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 096E71A6FEC for ; Mon, 14 Sep 2015 14:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1442265070; bh=FrTgexFFJ5ssSNiHfEQuwkX0X2EAgyV5J9qtmdmzjzU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tx6KUUaYSBOynkjY4BUhe4EfzOxPiptu1U7ileVeeAxyFyfBh3o8oBIOfGMNZNg/u e0oj8k9d40Nl1iEMYcFtIdsL1VSwmxQxQerKRuHZ/ZF/+KCPMAVmtdAtAx3aD7dWLf SF68Ww7t07JsZYCiUXVBM4LeCiy/DfvKbkeiHCrY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_21352B79-EDEB-4834-9661-F4A554747C8B"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <55F6CBA3.2010203@cisco.com>
Date: Mon, 14 Sep 2015 17:12:24 -0400
Message-Id: <7344B38E-7703-4096-9903-A760EED1CD04@lucidvision.com>
References: <80DE07EF-5EE5-4615-8AEE-E488E8D13209@lucidvision.com> <55F6CBA3.2010203@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=26 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 122, in=1632, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Preliminary Meeting Minutes from Interim Meeting 9/10/2015
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Sep 2015 21:12:31 -0000

--Apple-Mail=_21352B79-EDEB-4834-9661-F4A554747C8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


	We agreed to set it up for Thursday, October 1 from 10AM-12 EST. =
 I setup the WebEx which was sent to the list. I=92ll make sure the =
announcement goes out via the normal channels too.  The purpose will be =
to continue down the agenda we did not finish on the last meeting.  =
Please don=92t wait for the next meeting however, to =
discuss/compare/contrast the solution options.

	=97Tom



> On Sep 14, 2015:9:29 AM, at 9:29 AM, Robert Wilton  =
wrote:
>=20
> Hi Tom,
>=20
> Do you know when the follow up meeting will be scheduled for please?
>=20
> Thanks,
> Rob
>=20
>=20
> On 10/09/2015 21:57, Nadeau Thomas wrote:
>>=20
>> 	These are the preliminary/draft meeting minutes from today=92s =
meeting.=20
>> They will be neatened up once we are sure what they contain is =
accurate. Please=20
>> comment ASAP if you feel there are any inaccuracies contained =
therein.
>>=20
>> 	Thanks to Mahesh Jethanandani (mjethanandani@gmail.com =
) for taking notes!
>>=20
>> 	If you were in attendance, and are not listed in the screen =
capture from WebEx
>> below, please contact me privately so I make sure you are added. =
There were others that
>> came/went that did not make it on my initial screen capture nor were =
listed on the etherpad.
>>=20
>> 	=97Tom
>>=20
>>=20
>>>> Requirements Discussion have been captured in the e-mail send to =
the mailing list.
>>>> Tom: Question - do you agree/disagree with requirements posted on =
list
>>>>=20
>>>> Discussing the following requirements:=20
>>>> 	=95    =20
>>>> 	=95 1. Ability to interact with both intended and applied =
configuration
>>>>=20
>>>> 	=95    a. The ability to ask the operational components of a =
system
>>>> 	=95        (e.g., line cards) for the configuration that they =
are currently
>>>> 	=95        using. This is the "applied configuration".
>>>>=20
>>>> 	=95    b. applied configuration is read-only
>>>>=20
>>>> 	=95    c. The data model for the applied configuration is the =
same as
>>>> 	=95        the data model for the intended configuration (same =
leaves)
>>>>=20
>>>> 	=95    d. For asynchronous systems, when fully synchronized, the =
data
>>>> 	=95        in the applied configuration is the same as the data =
for the
>>>> 	=95        intended configuration.
>>>>=20
>>>> Tom: who disagrees with #1
>>>> Lada: Who is requirement 1.b. for. NETCONF client ? The example of =
being able to change the /proc entry in the Linux kernel.
>>>> Rob: That is not a good example. Take the example of a flash light. =
Asking to turn on the light through some other means is not changing =
applied configuration.
>>>>=20
>>>>    =20
>>>>    =20
>>>> Carl: we need a concrete example
>>>> Lou: applied config =3D show on the CLI
>>>> Carl: Lou's example is not the correct interpretation of applied =
configuration.
>>>> Carl: A concrete example would help here.
>>>> Kent: 1.d Is the applied configuraiton =3D intended configuration. =
On a sysnchronous system, if during transiition from applied to =
intended, the system simplified the configuration, would that be =
acceptable, or does it have to be a carbon copy? Rob confirms - yes.
>>>> Martin: In the draft, for 1.d, the applied configuration may not be =
the same as intended configuration.=20
>>>> Rob: For hardware that is synchronized. If the hardware is not =
present then it is not synchronous.
>>>> Martin: Will interfaces show up in applied configuration that have =
not been intended?
>>>> Call-in User 13: It will show up in applied configuration. Not =
everything that is applied is intended.
>>>> Martin: Maybe it is the schema that is the same between intended =
and applied configuration.
>>>> Rob: We are at the same point we were in June.=20
>>>> Tom: Do we agree with the requirements or are they minor edits?
>>>> Lada: The requirements are related to definitions. If the =
definitions are not clear, the requirements are not clear.
>>>> Tom: What have we been doing for the last three months? Can we move =
forward on agreeing on the requirements.
>>>> Kent: We have consensus on 1 a, b, and c. But not on d.
>>>> Rob: How can we say we do not have agreement on d.
>>>> Tom: Is the general sense that d is a requirement is clear. Are the =
requirements 1 a, b, c, d clear. No negative responses. No disagreement =
on the requirements.
>>>>=20
>>>> Tom: Moving to 2. Does anyone disagree with the requirement?=20
>>>> Alex: Will the applied data indistinguishable from dervied state?
>>>> Rob: In the draft we say that applied data would be retrieved from =
derived state.
>>>> Lada: IP address on a interface can be both applied or dervied =
state.=20
>>>> Rob: The BGP example of hold time has both intended and applied =
configuration.
>>>> Christian: The draft says that we can get both in a single =
operation.=20
>>>> ??: Need more examples for each of the requirements.
>>>> Tom: No objections. But do need examples.
>>>>=20
>>>> Tom: Moving to 3. No objections
>>>> Tom: 3a no objections
>>>> Tom: 3b no objections
>>>>=20
>>>> Tom: Moving to 4. No objections to 4, 4a and 4b.
>>>> Kent: Will add the word state to derived.
>>>>=20
>>>> Tom: Does anyone disagree that 5 is a duplicate of 3a. No =
objections.
>>>>=20
>>>> Tom: Disagree on 6a, b or c. No objections
>>>>=20
>>>> Tom: Disagree on 7 a, b, c. No objections
>>>>=20
>>>> Tom: Will be taken to the list where comments will be welcomed =
within 48 hours.
>>>> Christian: Can we make a call.
>>>> Tom: Not here. On the mailing list.
>>>>=20
>>>> Tom: Moving to solution discussion.
>>>> Lou: Can the chairs share the slides they have prepared.
>>>> Kent: Is that there are no questions?
>>>> Tom: No. It would help to see the comparisons.
>>>> Kent: Sharing slides.
>>>>=20
>>>> [Kent to paste his comparison e-mail here]
>>>>=20
>>>> Christian: Are both the kwatsen and wilton implemented using RPC.
>>>> Kent: Yes.
>>>> Christian: Would like to hear from OpenConfig folks on the two =
suggested solutions.
>>>> Rob: Would be interested in implementations that do not support a =
particular datastore=20
>>>> Andy: Instead of changing the schema, add attributes. Client asks =
for particular attributes. Would be happy with tha solution.
>>>> Aneesh: In the extreme case, the reply could carry all the extra =
attributes?
>>>> Andy: But the schema would have to maintain the extra leaves.
>>>> Aneesh: Do not want to debate the solution.
>>>> Andy: Most platforms do not need this. So keeing it as attributes =
makes it part of the protocol instead of the schema.
>>>> Aneesh: So is the solution is for the server returning attributes?
>>>> Aneesh: Like the idea.
>>>> Benoit: The two suggested solutions. They are based on =
NETCONF/RESTCONF. Are they using it for other protocols?
>>>> Aneesh: We are using other protocols. Will share primitives.
>>>> Benoit: If the solution is for NETCONF/RESTCONF, will it work for =
other protocols.
>>>> Rob: If the solution is mappable for NETCONF/RESTCONF, would it be =
mappable for another protocol.
>>>> Benoit: YANG is currently not protocol agnostic. Currently, it is =
tied to NETCONF/RESTCONF.
>>>> Benoit: If the solution is for NETCONF/RESTCONF, is that =
acceptable?
>>>> Rob: No. The solution has to be more general.
>>>> Christian: Is the intersection of NETCONF/RESTCONF good enough for =
the other protocols.
>>>> Andy: YANG cannot be decoupled from NETCONF/RESTCONF without making =
it Information Modelling Language.
>>>>=20
>>>> Tom: Need another meeting. Call for consensus on the mailing list.
>>=20
>>=20
>>=20
>> 
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

>=20


--Apple-Mail=_21352B79-EDEB-4834-9661-F4A554747C8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



	We agreed =
to set it up for Thursday, October 1 from 10AM-12 EST.  I setup the =
WebEx which was sent to the list. I=92ll make sure the announcement goes =
out via the normal channels too.  The purpose will be to continue =
down the agenda we did not finish on the last meeting.  Please =
don=92t wait for the next meeting however, to discuss/compare/contrast =
the solution options.

	=
=97Tom



On =
Sep 14, 2015:9:29 AM, at 9:29 AM, Robert Wilton <rwilton@cisco.com> =
wrote:


 =20
    
 =20
  

    Hi Tom,

    

    Do you know when the follow up meeting will be scheduled for =
please?

    

    Thanks,

    Rob

    

    

    
On 10/09/2015 21:57, Nadeau Thomas
      wrote:

    

    

      
      


      

      
	These
        are the preliminary/draft meeting minutes from today=92s =
meeting. 

      
They will be neatened up once we are sure what =
they
        contain is accurate. Please 

      
comment ASAP if you feel there are any =
inaccuracies
        contained therein.

      


      

      
	Thanks
        to Mahesh Jethanandani (mjethanandani@gmail.com)
        for taking notes!

      


      

      
	If
        you were in attendance, and are not listed in the screen capture
        from WebEx

      
below, please contact me privately so I make sure
        you are added. There were others that

      
came/went that did not make it on my initial =
screen
        capture nor were listed on the etherpad.

      


      

      
	=97Tom

      


      

      


      

      

        

          
Requirements Discussion =
have
            been captured in the e-mail send to the mailing =
list.

        

        

          
Tom: Question - do you
            agree/disagree with requirements posted on list
=

            

            Discussing the following requirements: 

            
	=95
                  

            

            
	=95
              1. Ability to interact with both intended and applied
              configuration

            

            

            
	=95
                 a. The ability to ask the operational =
components of a
              system

            

            
	=95
                     (e.g., line cards) for the =
configuration that they
              are currently

            

            
	=95
                     using. This is the "applied =
configuration".

            

            

            
	=95
                 b. applied configuration is read-only

            

            

            
	=95
                 c. The data model for the applied =
configuration is the
              same as

            

            
	=95
                     the data model for the intended =
configuration (same
              leaves)

            

            

            
	=95
                 d. For asynchronous systems, when fully =
synchronized,
              the data

            

            
	=95
                     in the applied configuration is =
the same as the
              data for the

            

            
	=95
                     intended configuration.

            

            

            Tom: who disagrees with #1

            Lada: Who is requirement 1.b. for. NETCONF client =
? The
            example of being able to change the /proc entry in the Linux
            kernel.

            Rob: That is not a good example. Take the example of a flash
            light. Asking to turn on the light through some other means
            is not changing applied configuration.

            

                

                

            Carl: we need a concrete example

            Lou: applied config =3D show on the CLI

            Carl: Lou's example is not the correct interpretation of
            applied configuration.

            Carl: A concrete example would help here.

            Kent: 1.d Is the applied configuraiton =3D intended
            configuration. On a sysnchronous system, if during
            transiition from applied to intended, the =
system simplified
            the configuration, would that be acceptable, or does it have
            to be a carbon copy? Rob confirms - yes.

            Martin: In the draft, for 1.d, the applied configuration may
            not be the same as intended configuration. 

            Rob: For hardware that is synchronized. If the hardware is
            not present then it is not synchronous.

            Martin: Will interfaces show up in applied configuration
            that have not been intended?

            Call-in User 13: It will show up in applied configuration.
            Not everything that is applied is intended.

            Martin: Maybe it is the schema that is the same between
            intended and applied configuration.

            Rob: We are at the same point we were in June. 

            Tom: Do we agree with the requirements or are they minor
            edits?

            Lada: The requirements are related to definitions. If the
            definitions are not clear, the requirements are not =
clear.

            Tom: What have we been doing for the last three months? Can
            we move forward on agreeing on the requirements.

            Kent: We have consensus on 1 a, b, and c. But not on d.

            Rob: How can we say we do not have agreement on d.

            Tom: Is the general sense that d is a requirement is clear.
            Are the requirements 1 a, b, c, d clear. No negative
            responses. No disagreement on the requirements.

            

            Tom: Moving to 2. Does anyone disagree with the
            requirement? 

            Alex: Will the applied data indistinguishable from dervied
            state?

            Rob: In the draft we say that applied data would be
            retrieved from derived state.

            Lada: IP address on a interface can be both applied or
            dervied state. 

            Rob: The BGP example of hold time has both intended and
            applied configuration.

            Christian: The draft says that we can get both in a single
            operation. 

            ??: Need more examples for each of the requirements.

            Tom: No objections. But do need examples.

            

            Tom: Moving to 3. No objections

            Tom: 3a no objections

            Tom: 3b no objections

            

            Tom: Moving to 4. No objections to 4, 4a and 4b.

            Kent: Will add the word state to derived.

            

            Tom: Does anyone disagree that 5 is a duplicate of 3a. No
            objections.

            

            Tom: Disagree on 6a, b or c. No objections

            

            Tom: Disagree on 7 a, b, c. No objections

            

            Tom: Will be taken to the list where comments will be
            welcomed within 48 hours.

            Christian: Can we make a call.

            Tom: Not here. On the mailing list.

            

            Tom: Moving to solution discussion.

            Lou: Can the chairs share the slides they have prepared.

            Kent: Is that there are no questions?

            Tom: No. It would help to see the comparisons.

            Kent: Sharing slides.

            

            [Kent to paste his comparison e-mail here]

            

            Christian: Are both the kwatsen and wilton implemented using
            RPC.

            Kent: Yes.

            Christian: Would like to hear from OpenConfig folks on the
            two suggested solutions.

            Rob: Would be interested in implementations that do not
            support a particular datastore 

            Andy: Instead of changing the schema, add attributes. Client
            asks for particular attributes. Would be happy with tha
            solution.

            Aneesh: In the extreme case, the reply could carry all the
            extra attributes?

            Andy: But the schema would have to maintain the extra
            leaves.

            Aneesh: Do not want to debate the solution.

            Andy: Most platforms do not need this. So keeing it as
            attributes makes it part of the protocol instead of the
            schema.

            Aneesh: So is the solution is for the server returning
            attributes?

            Aneesh: Like the idea.

            Benoit: The two suggested solutions. They are based on
            NETCONF/RESTCONF. Are they using it for other protocols?

            Aneesh: We are using other protocols. Will share =
primitives.

            Benoit: If the solution is for NETCONF/RESTCONF, will it
            work for other protocols.

            Rob: If the solution is mappable for NETCONF/RESTCONF, would
            it be mappable for another protocol.

            Benoit: YANG is currently not protocol agnostic. Currently,
            it is tied to NETCONF/RESTCONF.

            Benoit: If the solution is for NETCONF/RESTCONF, is that
            acceptable?

            Rob: No. The solution has to be more general.

            Christian: Is the intersection of NETCONF/RESTCONF good
            enough for the other protocols.

            Andy: YANG cannot be decoupled from NETCONF/RESTCONF without
            making it Information Modelling Language.

            

            Tom: Need another meeting. Call for consensus on the mailing
            list.

          

        

        


        

        


        

        

      

      
<Mail =
Attachment.png>

      

      

      

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


    

    

  




=

--Apple-Mail=_21352B79-EDEB-4834-9661-F4A554747C8B--


From nobody Mon Sep 14 19:47:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C443C1B3AE6 for ; Mon, 14 Sep 2015 19:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGOuzl0obYiG for ; Mon, 14 Sep 2015 19:47:01 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 EA5331B3AA9 for ; Mon, 14 Sep 2015 19:47:00 -0700 (PDT)
Received: by lbbmp1 with SMTP id mp1so77193387lbb.1 for ; Mon, 14 Sep 2015 19:46:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=we14kUWeXlyOLihnMSnIJlJeyarX1BBb2mCO1ToRI+k=; b=Dhy+HO6y/uCW/d8p+5EptAwC5O1JMxiz7YeQjP1Xuv6Rx2uFOQVvGZ3BEEQojv07+/ xZYc5rF6RxORWrwDiORxJWqufNzWEyO++9tTF5/DS501pbQxEJUP1LTZuC7FYAdGdod2 qa/n3mN+3zAT8up2iel/dGDMnKL7CwKYc1lBlBIPBGTCBQICSIUjqTe5nhVPISlWSLwH k/otNs0EtfY0fay0VTl4KrplIz6elhym95EaRXtKWx7V6ssgLxlCTtfns5y4X6MBm2JF 7NbqhSBokJ+hvmJx2r5UwpXzC9IwQBR7WTTyC/WaGd8jkEabpjKAI149h4zH+gNWmDKp dUkQ==
X-Gm-Message-State: ALoCoQmqWYUuE8zTpCIxz217Xsvo7UA0aBI6fD+HJluSkEc0u39ruFWSEZxqcDl0uBhvmD1Ll32m
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr16989674lbc.123.1442285219031;  Mon, 14 Sep 2015 19:46:59 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 14 Sep 2015 19:46:58 -0700 (PDT)
In-Reply-To: <20150914150234.GA67696@elstar.local>
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local>
Date: Mon, 14 Sep 2015 19:46:58 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c26650254ca7051fc032fd
Archived-At: 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 02:47:03 -0000

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

On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> >
> > Sure.  The use case is for example servers that implement ietf-ip
> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> > implement ietf-ip with the new ietf-interfaces.
> >
>
> Is the confusion is between implements and imports here? The module
> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> this not going to work?
>


Here is the guidance put in RFC 6020 for this occasion:

   Handling of the "yang-version" statement for versions other than "1"
   (the version defined here) is out of scope for this specification.
   Any document that defines a higher version will need to define the
   backward compatibility of such a higher version.


All current Yuma based tools see the yang-version 1.1; and exit:

    ietf-entity.yang:54.16: error(314): wrong version

    Error: cannot continue with unknown YANG language version



The solution outlined this morning should mostly work.
A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
even if the server has upgrades some of those modules to YANG 1.1.
Note that a server has total control when it introduces modules
written in YANG 1.1. Not the client.

If module 'foo' is upgraded to a new module revision,
and the new module revision uses YANG 1.1, then
the server will advertise the last YANG 1.0
revision for module 'foo' in the YANG 1.0 .
The YANG 1.1 library will contain both module revisions,
and the server will set conformance to 'implement' for the 1.1 version.

If the data that existed in the last revision written in YANG 1.0
has changed in the implemented revision written in YANG 1.1,
then the server should not (or must not?) advertise the 'phantom'
YANG 1.0 revision anymore.


 Andy



> > > Would it not work if an import of ietf-interfaces from a
> > > version 1 module simply resolves to the latest ietf-interfaces
> > > revision that is still version 1?
> >
> > But that would mean either that a server is stuck implementing version
> > 1 modules, or that the server must implement both the version 1 and
> > version 1.1 module - and we have already said that this isn't
> > possible.
>
> But this seems only true if import === implemented.
>
> > A set of simpler rules would be:
> >
> >    A YANG version 1.1 module MUST NOT include a version 1 module.
> >    A YANG version 1 module MUST NOT include a version 1.1 module.
> >
> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
>
> It is the last one we are discussing, no? I am trying again: Why is
> the MAY needed? Why is it not sufficient for a version 1 module to
> work with an import for (the latest) version 1 module?
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:<=
br>
>

> Sure.=C2=A0 The use case is for example servers that implement ietf-ip=


> (which imports ietf-interfaces), and ietf-interfaces.=C2=A0 Suppose we=


> update ietf-interfaces to 1.1.=C2=A0 It should still be ok for a serve=
r to

> implement ietf-ip with the new ietf-interfaces.

>



Is the confusion is between implements and imports here? The module

ietf-ip will _import_ an older version 1 ietf-interfaces while the

server _implements_ a newer version 1.1 ietf-interfaces module. Is

this not going to work?


=
Here is the guidance put in RFC 6020 for this occasion:

=
   Handling of the "yang-version" statement for versions other th=
an "1"
   (the version defined here) is out of scope for this specification.
   Any document that defines a higher version will need to define the
   backward compatibility of such a higher version.


All current Yuma based tools see the yang-version 1.1; and exit:=


=C2=A0 =C2=A0 ietf-entity.yang:54.16: error(=
314): wrong version

=C2=A0 =C2=A0 Error: cannot co=
ntinue with unknown YANG language version


The solution outlined this morning should mostl=
y work.
A YANG 1.0 client may be able to use only revisions writt=
en in YANG 1.0,
even if the server has upgrades some of those mod=
ules to YANG 1.1.
Note that a server has total control when it in=
troduces modules
written in YANG 1.1. Not the client.
<=
br>
If module 'foo' is upgraded to a new module revision,=

and the new module revision uses YANG 1.1, then
the se=
rver will advertise the last YANG 1.0
revision for module 'fo=
o' in the YANG 1.0 <hello>.
The YANG 1.1 library will c=
ontain both module revisions,
and the server will set conformance=
 to 'implement' for the 1.1 version.

If th=
e data that existed in the last revision written in YANG 1.0
has =
changed in the implemented revision written in YANG 1.1,
then the=
 server should not (or must not?) advertise the 'phantom'
YANG 1.0 revision anymore.


=C2=A0A=
ndy





> > Would it not work if an import of ietf-interfaces from a

> > version 1 module simply resolves to the latest ietf-interfaces
> > revision that is still version 1?

>

> But that would mean either that a server is stuck implementing version=


> 1 modules, or that the server must implement both the version 1 and
> version 1.1 module - and we have already said that this isn't

> possible.



But this seems only true if import =3D=3D=3D implemented.



> A set of simpler rules would be:

>

>=C2=A0 =C2=A0 A YANG version 1.1 module MUST NOT include a version 1 mo=
dule.

>=C2=A0 =C2=A0 A YANG version 1 module MUST NOT include a version 1.1 mo=
dule.

>

>=C2=A0 =C2=A0 A YANG version 1.1 (sub)module MAY import a version 1 mod=
ule.

>=C2=A0 =C2=A0 A YANG version 1 (sub)module MAY import a version 1.1 mod=
ule.



It is the last one we are discussing, no? I am trying again: Why is

the MAY needed? Why is it not sufficient for a version 1 module to

work with an import for (the latest) version 1 module?



/js



--

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/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c26650254ca7051fc032fd--


From nobody Mon Sep 14 23:42:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27781B4339 for ; Mon, 14 Sep 2015 23:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOY7r7wp0cuz for ; Mon, 14 Sep 2015 23:41:58 -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 6DFD21B430A for ; Mon, 14 Sep 2015 23:41:58 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0E39129F; Tue, 15 Sep 2015 08:41:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id d6PgkQAxS5m7; Tue, 15 Sep 2015 08:41: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; Tue, 15 Sep 2015 08:41:56 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 028F720048; Tue, 15 Sep 2015 08:41:56 +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 VJG6Un4Z-otW; Tue, 15 Sep 2015 08:41:54 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFE0E2004E; Tue, 15 Sep 2015 08:41:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 19BF93720FCB; Tue, 15 Sep 2015 08:41:49 +0200 (CEST)
Date: Tue, 15 Sep 2015 08:41:48 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150915064147.GB69146@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group 
References: <20150910084021.8677.6592.idtracker@ietfa.amsl.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.4.2.3i
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 06:42:01 -0000

On Thu, Sep 10, 2015 at 10:46:10AM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> this revision introduces no changes to the encoding rules. The text was modified, and hopefully improved, in quite a few places, mainly due to Juergen’s review of -04, thanks Juergen.
>

Lada, a suggestion and a question concerning anydata. The text
currently says:

   Anydata data node is a new feature in YANG 1.1.  It serves as a
   container for an unknown set of nodes that however appear as normal
   YANG-modeled data.  A data model for anydata content may or may not
   exist at run time.  In the latter case, no universal mapping between
   JSON- and XML-encoded instances is available.

The suggestion is to rewrite the text to be more inline with the YANG
1.1 definition of anydata (and I do not think it matters to highlight
that anydata is a YANG 1.1 thing, the document also mentions actions
without saying this is a YANG 1.1 feature).

   An anydata data node can contain an unknown set of nodes that
   can be modelled by YANG. A data model for anydata content may or may not
   exist at run time.  In the latter case, no universal mapping between
   JSON- and XML-encoded instances is available.

My question is why the text is silent about the case where the data
model is present. Should it not say that if the data model is present,
the data encoded inside the anydata node must follow the rules of this
document? Perhaps this is the implicit assumption but I think it will
be useful to say this explicitly (if we agree on this).

If the data model is not present, then I think an implementation is
still expected to produce an encoding that follows the rules of this
document as much as possible except that things that requires data
model knowledge may be encoded differently (e.g., numbers appearing as
strings or namespace names being different). I am thinking along the
lines of this proposed new text:

   An anydata data node can contain an unknown set of nodes that can
   be modelled by YANG. A data model for anydata content may or may
   not exist at run time.  If the data model for anydata content is
   available, then the anydata content MUST be encoded according to
   the rules of this specification. If the data model for anydata
   content is not available, the encoding MUST follow the rules of
   this specification except for rules that require data model
   knowledge (and as a consequence, numbers may appear as strings or
   namespace qualifiers may not match module names).

/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 Sep 15 00:31:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A711E1B476E for ; Tue, 15 Sep 2015 00:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCIsw2Bzecsf for ; Tue, 15 Sep 2015 00:31:55 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBA1B476A for ; Tue, 15 Sep 2015 00:31:54 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DFC7A1CC00B1; Tue, 15 Sep 2015 09:31:57 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
In-Reply-To: <20150915064147.GB69146@elstar.local>
References: <20150910084021.8677.6592.idtracker@ietfa.amsl.com>  <20150915064147.GB69146@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 15 Sep 2015 09:31:58 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 07:31:58 -0000

Juergen Schoenwaelder  writes:

> On Thu, Sep 10, 2015 at 10:46:10AM +0200, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> this revision introduces no changes to the encoding rules. The text was =
modified, and hopefully improved, in quite a few places, mainly due to Juer=
gen=E2=80=99s review of -04, thanks Juergen.
>>
>
> Lada, a suggestion and a question concerning anydata. The text
> currently says:
>
>    Anydata data node is a new feature in YANG 1.1.  It serves as a
>    container for an unknown set of nodes that however appear as normal
>    YANG-modeled data.  A data model for anydata content may or may not
>    exist at run time.  In the latter case, no universal mapping between
>    JSON- and XML-encoded instances is available.
>
> The suggestion is to rewrite the text to be more inline with the YANG
> 1.1 definition of anydata (and I do not think it matters to highlight
> that anydata is a YANG 1.1 thing, the document also mentions actions
> without saying this is a YANG 1.1 feature).
>
>    An anydata data node can contain an unknown set of nodes that
>    can be modelled by YANG. A data model for anydata content may or may n=
ot
>    exist at run time.  In the latter case, no universal mapping between
>    JSON- and XML-encoded instances is available.
>
> My question is why the text is silent about the case where the data
> model is present. Should it not say that if the data model is present,
> the data encoded inside the anydata node must follow the rules of this
> document? Perhaps this is the implicit assumption but I think it will
> be useful to say this explicitly (if we agree on this).

If we do agree on this, then IMO 6020bis is the right place to state it
because this rule should hold for any encoding.=20

>
> If the data model is not present, then I think an implementation is
> still expected to produce an encoding that follows the rules of this
> document as much as possible except that things that requires data

I tried to specify these rules in the four bullets in sec. 5.5. Do you
think something else is needed?

Lada

> model knowledge may be encoded differently (e.g., numbers appearing as
> strings or namespace names being different). I am thinking along the
> lines of this proposed new text:
>
>    An anydata data node can contain an unknown set of nodes that can
>    be modelled by YANG. A data model for anydata content may or may
>    not exist at run time.  If the data model for anydata content is
>    available, then the anydata content MUST be encoded according to
>    the rules of this specification. If the data model for anydata
>    content is not available, the encoding MUST follow the rules of
>    this specification except for rules that require data model
>    knowledge (and as a consequence, numbers may appear as strings or
>    namespace qualifiers may not match module names).
>
> /js
>
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 15 01:00:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6991B390A for ; Tue, 15 Sep 2015 01:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW9ZFQnRFTLu for ; Tue, 15 Sep 2015 01:00:43 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C479F1B33F1 for ; Tue, 15 Sep 2015 01:00:42 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 814C51CC00B1; Tue, 15 Sep 2015 10:00:45 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: <20150914141206.GD67363@elstar.local>
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 15 Sep 2015 10:00:46 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 08:00:47 -0000

Juergen Schoenwaelder  writes:

> On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
>  
>> >> Let's look at a slightly more complex hypothetical case to tease
>> >> out how folks *want* things to work.  Assume the following have
>> >> been defined:
>> >>
>> >>   - base module M
>> >>   - augmentation Q
>> >>   - augmentation R
>> >>
>> >> On a server claiming to supporting the modules containing M, Q,
>> >> and R, respectively, which of the following might one encounter
>> >> concurrently?
>> >>
>> >>      - plain M
>> >>      - M+Q
>> >>      - M+R
>> >>      - M+Q+R
>> >
>> >It depends on what you mean by "encounter" but in terms of datastore
>> >validity the only possible answer IMO is M+Q+R.
>> 
>> By "encounter" I mean if a client asks the server for all of its Ms,
>> and the server also supports Q and R, are all of the Ms *guaranteed*
>> to be M+Q+R, or is it possible that some of the Ms might lack Q or
>> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
>> how would one model a system inhabited by a mixture of the four
>> kinds of Ms?
>
> Retrieval is easy since a client is going to ignore data it does not
> understand and the server is expected to report what makes sense from
> the server's perspective. The question is relevant for writing: Is a
> client programmed based on M going to work even if a server supports
> M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC
> 6020 wanted to achieve this by forbidding mandatory nodes in
> augmentations.
>
> Y26-02 says that a presence container may be used to avoid breaking an
> old client. Frankly, it seems not totally clear to me what the
> sentence in section 7.15 of RFC 6020 really means:
>
>     If the target node is in another module, then nodes added by the
>     augmentation MUST NOT be mandatory nodes (see Section 3.1).
>
> Does this rule only apply to nodes directly added under the target
> node or does it apply to the whole hierarchy added? In the later case,
> this would still cause a problem with the presence container work
> around.

Yes, it's unclear but IMO it is about mandatory nodes directly below the
target node - a similar rule for module updates is in sec. 11.

>
> The recent suggestion to replace MUST NOT with SHOULD NOT in this
> sentence may be seen as a softer variant of Y26-01. However, I think
> we would, in addition, have to describe when it is OK to have
> mandatory nodes in augmentations and when not. Simply saying SHOULD
> NOT instead of MUST NOT will not help people to understand the issues
> around this.

The definition in RFC 2119 is:

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

I think it should suffice if data model designers are aware of the
fact that certain augments may break old clients, and give some
reasoning if they use them anyway. 

>
> When this issue was discussed in the past, it turned out to be
> difficult to find someone to write the necessary text explaining when
> augmenting mandatory nodes is safe and when not. Are we doing better
> now?

I don't think we can enumerate all cases where it is allowed because
YANG doesn't follow any rigid structure and there may be a variety of
different designs.

I'd prefer to explain the ramifications of defining mandatory nodes in
augments (and also in module updates) and leave it to the model designer
to judge whether there are valid reasons to override the "SHOULD NOT" -
and YANG doctors should verify it in IETF models.

I think the point is that parameters are mandatory not because a
spiteful module author defines them so but rather because the system
cannot work without them.

Lada


>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 15 01:09:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFE81AD35D for ; Tue, 15 Sep 2015 01:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-VNy19Xr7Ob for ; Tue, 15 Sep 2015 01:09:03 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C554B1ACD4B for ; Tue, 15 Sep 2015 01:09:02 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 453A81CC00B1; Tue, 15 Sep 2015 10:09:06 +0200 (CEST)
From: Ladislav Lhotka 
To: Jernej Tuljak 
In-Reply-To: <55F6A7F0.2010400@mg-soft.si>
References: <20150706171427.3438.31431.idtracker@ietfa.amsl.com> <55F6A7F0.2010400@mg-soft.si>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 15 Sep 2015 10:09:07 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 08:09:05 -0000

Jernej Tuljak  writes:

> Hi,
>
> current text in 6087bis-04 (Section 5.6.4):
>
>     XPath expressions for 'when' statements SHOULD NOT reference the
>     context node or any descendant nodes of the context node.  They MAY
>     reference descendant nodes if the 'when' statement is contained
>     within an 'augment' statement, and the referenced nodes are not
>     defined within the 'augment' statement.
>
> This is OK. But the text never mentions an analogous case, which is when 
> a when-stmt is defined for a uses-stmt. I think this should be 
> corrected. Note that finding the initial context node for the expression 
> uses an algorithm that is virtually equal to the 'augment' case (first 
> data node ancestor), therefore the first sentence in the above text 
> discourages use of 'when' statements within a 'uses' statement, which I 
> don't think was the intention.
>
>    grouping special-params {
>      leaf param1 {
>        type string;
>      }
>      leaf param2 {
>        type string;
>      }
>    }
>
>    container foo {
>      leaf enable-special {
>        type boolean;
>      }
>      uses special-params {
>        when "enable-special = 'true'";
>      }
>    }
>
> In my example the expression references a descendant of the initial 
> context node, which should be OK. What would be problematic is 
> referencing descendants that are defined in the grouping.
>
> OLD:
>
>     XPath expressions for 'when' statements SHOULD NOT reference the
>     context node or any descendant nodes of the context node.  They MAY
>     reference descendant nodes if the 'when' statement is contained
>     within an 'augment' statement, and the referenced nodes are not
>     defined within the 'augment' statement.
>
> NEW:
>
>     XPath expressions for 'when' statements SHOULD NOT reference the
>     context node or any descendant nodes of the context node.  They MAY
>     reference descendant nodes if the 'when' statement is contained
>     within an 'augment' statement, and the referenced nodes are not
>     defined within the 'augment' statement. They MAY also reference
>     descendant nodes if the 'when' statement is contained within a
>     'uses' statement, and the referenced nodes are not defined within
>     the 'grouping' statement being referred to by the 'uses' statement.
>

+1

Lada

> Or something similar.
>
> Jernej
>
>
> internet-drafts@ietf.org je 6.7.2015 ob 19:14 napisal:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>   This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>>
>>          Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
>>          Author          : Andy Bierman
>> 	Filename        : draft-ietf-netmod-rfc6087bis-04.txt
>> 	Pages           : 52
>> 	Date            : 2015-07-06
>>
>> Abstract:
>>     This memo provides guidelines for authors and reviewers of Standards
>>     Track specifications containing YANG data model modules.  Applicable
>>     portions may be used as a basis for reviews of other YANG data model
>>     documents.  Recommendations and procedures are defined, which are
>>     intended to increase interoperability and usability of Network
>>     Configuration Protocol (NETCONF) implementations that utilize YANG
>>     data model modules.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-04
>>
>>
>> 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/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 15 02:31:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2DE1B476B for ; Tue, 15 Sep 2015 02:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW_CLrBTFHSY for ; Tue, 15 Sep 2015 02:31:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AC31B1B473C for ; Tue, 15 Sep 2015 02:31:45 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3BB721CC0157; Tue, 15 Sep 2015 11:31:48 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod\@ietf.org" 
In-Reply-To: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local> 
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 15 Sep 2015 11:31:49 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 09:31:48 -0000

Andy Bierman  writes:

> On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
>> >
>> > Sure.  The use case is for example servers that implement ietf-ip
>> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
>> > update ietf-interfaces to 1.1.  It should still be ok for a server to
>> > implement ietf-ip with the new ietf-interfaces.
>> >
>>
>> Is the confusion is between implements and imports here? The module
>> ietf-ip will _import_ an older version 1 ietf-interfaces while the
>> server _implements_ a newer version 1.1 ietf-interfaces module. Is
>> this not going to work?
>>
>
>
> Here is the guidance put in RFC 6020 for this occasion:
>
>    Handling of the "yang-version" statement for versions other than "1"
>    (the version defined here) is out of scope for this specification.
>    Any document that defines a higher version will need to define the
>    backward compatibility of such a higher version.
>
>
> All current Yuma based tools see the yang-version 1.1; and exit:
>
>     ietf-entity.yang:54.16: error(314): wrong version
>
>     Error: cannot continue with unknown YANG language version

I don't think this has to be a strict rule for clients. After all, a
client can send any request and it is up to the server to decide whether
the request is valid and send a reply or error message.

>
>
>
> The solution outlined this morning should mostly work.
> A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
> even if the server has upgrades some of those modules to YANG 1.1.
> Note that a server has total control when it introduces modules
> written in YANG 1.1. Not the client.
>
> If module 'foo' is upgraded to a new module revision,
> and the new module revision uses YANG 1.1, then
> the server will advertise the last YANG 1.0
> revision for module 'foo' in the YANG 1.0 .
> The YANG 1.1 library will contain both module revisions,
> and the server will set conformance to 'implement' for the 1.1
> version.

Does this apply only to the case when the old and new revisions of "foo" are
identical except for yang-version? 

>
> If the data that existed in the last revision written in YANG 1.0
> has changed in the implemented revision written in YANG 1.1,
> then the server should not (or must not?) advertise the 'phantom'
> YANG 1.0 revision anymore.

But then an old 1.0-only client is stuck, right?

Lada

>
>
>  Andy
>
>
>
>> > > Would it not work if an import of ietf-interfaces from a
>> > > version 1 module simply resolves to the latest ietf-interfaces
>> > > revision that is still version 1?
>> >
>> > But that would mean either that a server is stuck implementing version
>> > 1 modules, or that the server must implement both the version 1 and
>> > version 1.1 module - and we have already said that this isn't
>> > possible.
>>
>> But this seems only true if import === implemented.
>>
>> > A set of simpler rules would be:
>> >
>> >    A YANG version 1.1 module MUST NOT include a version 1 module.
>> >    A YANG version 1 module MUST NOT include a version 1.1 module.
>> >
>> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
>> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
>>
>> It is the last one we are discussing, no? I am trying again: Why is
>> the MAY needed? Why is it not sufficient for a version 1 module to
>> work with an import for (the latest) version 1 module?
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 15 06:22:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C1D1ACD33 for ; Tue, 15 Sep 2015 06:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMlORu9g91if for ; Tue, 15 Sep 2015 06:22:32 -0700 (PDT)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654541B313B for ; Tue, 15 Sep 2015 06:22:31 -0700 (PDT)
Received: by lamp12 with SMTP id p12so106178384lam.0 for ; Tue, 15 Sep 2015 06:22:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CG8ZVMIcPw/WWkuAYp51bAe07jXATkKG7fHQ1vkyJZQ=; b=k0l5OEgz9hQcWf1/lBKjH4vhsjlrOm7P6YDxBzMyTBK1gDyQK1Mc0cKsmyshTjWzWj iSLeYsxQlGdfBvxU+JxpV205W5T/5eCLvDdz73WWl8TdnCTx4OGXRbxJnhuy6rplsvUR z3FQGm3U5CfIwIG1VsWLZpV1XMBCdXjDxipZmAtR/eCch9ueLUO1mzYXFjdSRbUSUBBB FLV5Rpj4IM1yxPccDXPMFo5yFSWMR8HlnEFdzSOhYeE/thmUhOOwYUe3ZpTPvQdCpNOP HV2o6ITaD0gntcWfOyRUnkT9pEdt36QAOLGp4NWYgUHckvS1+w2FrtqIrbAmYjJV/Ff2 FJaQ==
X-Gm-Message-State: ALoCoQnn2QmTXl1YuGUU41i9qLTZN/ucgstZ/03qvhUNuJBfCnmYehORkZU+1gBsv+MWrl9Ek2Dr
MIME-Version: 1.0
X-Received: by 10.152.1.9 with SMTP id 9mr19791772lai.38.1442323349533; Tue, 15 Sep 2015 06:22:29 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 15 Sep 2015 06:22:29 -0700 (PDT)
In-Reply-To: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local>  
Date: Tue, 15 Sep 2015 06:22:29 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e013c6656e692ed051fc91242
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 13:22:35 -0000

--089e013c6656e692ed051fc91242
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> >> >
> >> > Sure.  The use case is for example servers that implement ietf-ip
> >> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> >> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> >> > implement ietf-ip with the new ietf-interfaces.
> >> >
> >>
> >> Is the confusion is between implements and imports here? The module
> >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> >> this not going to work?
> >>
> >
> >
> > Here is the guidance put in RFC 6020 for this occasion:
> >
> >    Handling of the "yang-version" statement for versions other than "1"
> >    (the version defined here) is out of scope for this specification.
> >    Any document that defines a higher version will need to define the
> >    backward compatibility of such a higher version.
> >
> >
> > All current Yuma based tools see the yang-version 1.1; and exit:
> >
> >     ietf-entity.yang:54.16: error(314): wrong version
> >
> >     Error: cannot continue with unknown YANG language version
>
> I don't think this has to be a strict rule for clients. After all, a
> client can send any request and it is up to the server to decide whether
> the request is valid and send a reply or error message.
>
>
Not sure what you mean.
A tool that does not claim conformance because it does not recognize the
YANG language does not have any rules to follow.

We cannot make any rules whatsoever that a YANG 1.0 tool
must follow wrt/ other YANG language versions.  That much is rather clear.

>
> >
> >
> > The solution outlined this morning should mostly work.
> > A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
> > even if the server has upgrades some of those modules to YANG 1.1.
> > Note that a server has total control when it introduces modules
> > written in YANG 1.1. Not the client.
> >
> > If module 'foo' is upgraded to a new module revision,
> > and the new module revision uses YANG 1.1, then
> > the server will advertise the last YANG 1.0
> > revision for module 'foo' in the YANG 1.0 .
> > The YANG 1.1 library will contain both module revisions,
> > and the server will set conformance to 'implement' for the 1.1
> > version.
>
> Does this apply only to the case when the old and new revisions of "foo"
> are
> identical except for yang-version?
>


It is up to the server vendor, as Martin said.


>
> >
> > If the data that existed in the last revision written in YANG 1.0
> > has changed in the implemented revision written in YANG 1.1,
> > then the server should not (or must not?) advertise the 'phantom'
> > YANG 1.0 revision anymore.
>
> But then an old 1.0-only client is stuck, right?
>
>
Yep -- the version written in YANG 1.1 might diverge from the last revision
written in YANG 1.0.  Then forklift upgrades are needed.  And since YANG is
far
from stable, one might expect to go through churn every year until YANG is
stable.


Lada
>


Andy


>
> >
> >
> >  Andy
> >
> >
> >
> >> > > Would it not work if an import of ietf-interfaces from a
> >> > > version 1 module simply resolves to the latest ietf-interfaces
> >> > > revision that is still version 1?
> >> >
> >> > But that would mean either that a server is stuck implementing version
> >> > 1 modules, or that the server must implement both the version 1 and
> >> > version 1.1 module - and we have already said that this isn't
> >> > possible.
> >>
> >> But this seems only true if import === implemented.
> >>
> >> > A set of simpler rules would be:
> >> >
> >> >    A YANG version 1.1 module MUST NOT include a version 1 module.
> >> >    A YANG version 1 module MUST NOT include a version 1.1 module.
> >> >
> >> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
> >> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
> >>
> >> It is the last one we are discussing, no? I am trying again: Why is
> >> the MAY needed? Why is it not sufficient for a version 1 module to
> >> work with an import for (the latest) version 1 module?
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103         
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

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




On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:



> On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <

> j.schoenwaelde=
r@jacobs-university.de> wrote:

>

>> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:<=
br>
>> >

>> > Sure.=C2=A0 The use case is for example servers that implemen=
t ietf-ip

>> > (which imports ietf-interfaces), and ietf-interfaces.=C2=A0 S=
uppose we

>> > update ietf-interfaces to 1.1.=C2=A0 It should still be ok fo=
r a server to

>> > implement ietf-ip with the new ietf-interfaces.

>> >

>>

>> Is the confusion is between implements and imports here? The modul=
e

>> ietf-ip will _import_ an older version 1 ietf-interfaces while the=


>> server _implements_ a newer version 1.1 ietf-interfaces module. Is=


>> this not going to work?

>>

>

>

> Here is the guidance put in RFC 6020 for this occasion:

>

>=C2=A0 =C2=A0 Handling of the "yang-version" statement for ve=
rsions other than "1"

>=C2=A0 =C2=A0 (the version defined here) is out of scope for this speci=
fication.

>=C2=A0 =C2=A0 Any document that defines a higher version will need to d=
efine the

>=C2=A0 =C2=A0 backward compatibility of such a higher version.

>

>

> All current Yuma based tools see the yang-version 1.1; and exit:

>

>=C2=A0 =C2=A0 =C2=A0ietf-entity.yang:54.16: error(314): wrong version
>

>=C2=A0 =C2=A0 =C2=A0Error: cannot continue with unknown YANG language v=
ersion



I don't think this has to be a strict rule for clients. After all, a
client can send any request and it is up to the server to decide whether
the request is valid and send a reply or error message.



Not sure what you mean.
A to=
ol that does not claim conformance because it does not recognize the
<=
div>YANG language does not have any rules to follow.

We cannot make any rules whatsoever that a YANG 1.0 tool
must =
follow wrt/ other YANG language versions.=C2=A0 That much is rather clear.<=
/div>


>

>

>

> The solution outlined this morning should mostly work.

> A YANG 1.0 client may be able to use only revisions written in YANG 1.=
0,

> even if the server has upgrades some of those modules to YANG 1.1.

> Note that a server has total control when it introduces modules

> written in YANG 1.1. Not the client.

>

> If module 'foo' is upgraded to a new module revision,

> and the new module revision uses YANG 1.1, then

> the server will advertise the last YANG 1.0

> revision for module 'foo' in the YANG 1.0 <hello>.

> The YANG 1.1 library will contain both module revisions,

> and the server will set conformance to 'implement' for the 1.1=


> version.



Does this apply only to the case when the old and new revisions of "fo=
o" are

identical except for yang-version?


=

It is up to the server vendor, as Martin said.
=C2=A0<=
/div>



>

> If the data that existed in the last revision written in YANG 1.0

> has changed in the implemented revision written in YANG 1.1,

> then the server should not (or must not?) advertise the 'phantom&#=
39;

> YANG 1.0 revision anymore.



But then an old 1.0-only client is stuck, right?



Yep -- the version written in YANG 1.1=
 might diverge from the last revision
written in YANG 1.0.=C2=A0 =
Then forklift upgrades are needed.=C2=A0 And since YANG is far
fr=
om stable, one might expect to go through churn every year until YANG is st=
able.



Lada


Andy
=C2=
=A0



>

>

>=C2=A0 Andy

>

>

>

>> > > Would it not work if an import of ietf-interfaces from a=


>> > > version 1 module simply resolves to the latest ietf-inte=
rfaces

>> > > revision that is still version 1?

>> >

>> > But that would mean either that a server is stuck implementin=
g version

>> > 1 modules, or that the server must implement both the version=
 1 and

>> > version 1.1 module - and we have already said that this isn&#=
39;t

>> > possible.

>>

>> But this seems only true if import =3D=3D=3D implemented.

>>

>> > A set of simpler rules would be:

>> >

>> >=C2=A0 =C2=A0 A YANG version 1.1 module MUST NOT include a ver=
sion 1 module.

>> >=C2=A0 =C2=A0 A YANG version 1 module MUST NOT include a versi=
on 1.1 module.

>> >

>> >=C2=A0 =C2=A0 A YANG version 1.1 (sub)module MAY import a vers=
ion 1 module.

>> >=C2=A0 =C2=A0 A YANG version 1 (sub)module MAY import a versio=
n 1.1 module.

>>

>> It is the last one we are discussing, no? I am trying again: Why i=
s

>> the MAY needed? Why is it not sufficient for a version 1 module to=


>> work with an import for (the latest) version 1 module?

>>

>> /js

>>

>> --

>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco=
bs University Bremen gGmbH

>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri=
ng 1 | 28759 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/>

>>

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

>> https://www.ietf.org/mailman/listinfo/netmod

>>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C





--089e013c6656e692ed051fc91242--


From nobody Tue Sep 15 06:47:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79A1B4633 for ; Tue, 15 Sep 2015 06:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqs0IhFpsMZ0 for ; Tue, 15 Sep 2015 06:47:11 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293C21B4541 for ; Tue, 15 Sep 2015 06:47:03 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id AF0761813F8; Tue, 15 Sep 2015 15:47:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442324821; bh=WFcjgty5ZjAVp1m+l5BweZi0dR5e5JvSGDy+Q7obGzQ=; h=From:Date:To; b=Ub4hlEOZQoE/iqfCaEqXrJx6nDK1rOb5hoEMflS6MyJndBnrTwQaeFcD+HUiTY/gw Va877mPQembLX60ElL/QHFnL7a7efvqNiXa7W/tpWeq1v2sEywCbb+8KXQlNo2s2ZH OPkaxjRXFQXCoxDc7gBeQDhemu/zKmz/xJBqbkMM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 15 Sep 2015 15:47:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 13:47:14 -0000

> On 15 Sep 2015, at 15:22, Andy Bierman  wrote:
>=20
>=20
>=20
> On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka  =
wrote:
> Andy Bierman  writes:
>=20
> > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> >> >
> >> > Sure.  The use case is for example servers that implement ietf-ip
> >> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> >> > update ietf-interfaces to 1.1.  It should still be ok for a =
server to
> >> > implement ietf-ip with the new ietf-interfaces.
> >> >
> >>
> >> Is the confusion is between implements and imports here? The module
> >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> >> this not going to work?
> >>
> >
> >
> > Here is the guidance put in RFC 6020 for this occasion:
> >
> >    Handling of the "yang-version" statement for versions other than =
"1"
> >    (the version defined here) is out of scope for this =
specification.
> >    Any document that defines a higher version will need to define =
the
> >    backward compatibility of such a higher version.
> >
> >
> > All current Yuma based tools see the yang-version 1.1; and exit:
> >
> >     ietf-entity.yang:54.16: error(314): wrong version
> >
> >     Error: cannot continue with unknown YANG language version
>=20
> I don't think this has to be a strict rule for clients. After all, a
> client can send any request and it is up to the server to decide =
whether
> the request is valid and send a reply or error message.
>=20
>=20
> Not sure what you mean.
> A tool that does not claim conformance because it does not recognize =
the
> YANG language does not have any rules to follow.
>=20
> We cannot make any rules whatsoever that a YANG 1.0 tool
> must follow wrt/ other YANG language versions.  That much is rather =
clear.

I don=E2=80=99t want to enforce classification of clients and then =
require that a 1.0 client MUST exit when seeing yang-version 1.1.

Lada

>=20
> >
> >
> >
> > The solution outlined this morning should mostly work.
> > A YANG 1.0 client may be able to use only revisions written in YANG =
1.0,
> > even if the server has upgrades some of those modules to YANG 1.1.
> > Note that a server has total control when it introduces modules
> > written in YANG 1.1. Not the client.
> >
> > If module 'foo' is upgraded to a new module revision,
> > and the new module revision uses YANG 1.1, then
> > the server will advertise the last YANG 1.0
> > revision for module 'foo' in the YANG 1.0 .
> > The YANG 1.1 library will contain both module revisions,
> > and the server will set conformance to 'implement' for the 1.1
> > version.
>=20
> Does this apply only to the case when the old and new revisions of =
"foo" are
> identical except for yang-version?
>=20
>=20
> It is up to the server vendor, as Martin said.
> =20
>=20
> >
> > If the data that existed in the last revision written in YANG 1.0
> > has changed in the implemented revision written in YANG 1.1,
> > then the server should not (or must not?) advertise the 'phantom'
> > YANG 1.0 revision anymore.
>=20
> But then an old 1.0-only client is stuck, right?
>=20
>=20
> Yep -- the version written in YANG 1.1 might diverge from the last =
revision
> written in YANG 1.0.  Then forklift upgrades are needed.  And since =
YANG is far
> from stable, one might expect to go through churn every year until =
YANG is stable.
>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
>=20
> >
> >
> >  Andy
> >
> >
> >
> >> > > Would it not work if an import of ietf-interfaces from a
> >> > > version 1 module simply resolves to the latest ietf-interfaces
> >> > > revision that is still version 1?
> >> >
> >> > But that would mean either that a server is stuck implementing =
version
> >> > 1 modules, or that the server must implement both the version 1 =
and
> >> > version 1.1 module - and we have already said that this isn't
> >> > possible.
> >>
> >> But this seems only true if import =3D=3D=3D implemented.
> >>
> >> > A set of simpler rules would be:
> >> >
> >> >    A YANG version 1.1 module MUST NOT include a version 1 module.
> >> >    A YANG version 1 module MUST NOT include a version 1.1 module.
> >> >
> >> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
> >> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
> >>
> >> It is the last one we are discussing, no? I am trying again: Why is
> >> the MAY needed? Why is it not sufficient for a version 1 module to
> >> work with an import for (the latest) version 1 module?
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
> >> Fax:   +49 421 200 3103         
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Sep 15 06:55:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FAE1B4CF3 for ; Tue, 15 Sep 2015 06:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw9n3MrNqb9A for ; Tue, 15 Sep 2015 06:55:01 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D42B21B4CED for ; Tue, 15 Sep 2015 06:55:00 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A60F1AE0620; Tue, 15 Sep 2015 15:54:58 +0200 (CEST)
Date: Tue, 15 Sep 2015 15:54:58 +0200 (CEST)
Message-Id: <20150915.155458.124799884157219010.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20150914150234.GA67696@elstar.local>
References: <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 13:55:02 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > 
> > Sure.  The use case is for example servers that implement ietf-ip
> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> > implement ietf-ip with the new ietf-interfaces.
> >
> 
> Is the confusion is between implements and imports here? The module
> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> this not going to work?
> 
> > > Would it not work if an import of ietf-interfaces from a
> > > version 1 module simply resolves to the latest ietf-interfaces
> > > revision that is still version 1?
> > 
> > But that would mean either that a server is stuck implementing version
> > 1 modules, or that the server must implement both the version 1 and
> > version 1.1 module - and we have already said that this isn't
> > possible.
> 
> But this seems only true if import === implemented.
> 
> > A set of simpler rules would be:
> > 
> >    A YANG version 1.1 module MUST NOT include a version 1 module.
> >    A YANG version 1 module MUST NOT include a version 1.1 module.
> > 
> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
> 
> It is the last one we are discussing, no? I am trying again: Why is
> the MAY needed? Why is it not sufficient for a version 1 module to
> work with an import for (the latest) version 1 module?

How about this:

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

* Coexistence with YANG version 1 @coexistence@

A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
and a YANG version 1 module MUST NOT include a YANG version 1.1
submodule.

A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision.

A YANG version 1.1 module or submodule MAY import a YANG version
1 module by revision.

If a YANG version 1 module A imports module B without revision, and
module B is updated to YANG version 1.1, a server MAY implement both
these modules at the same time.  In such cases, a NETCONF server MUST
advertise both modules using the rules defined in ^announce^, and
SHOULD advertise module A and the latest revision of module B that is
specified with YANG version 1 according	to the rules defined in
^RFC6020^.

This rule exists in order to allow implementations of existing YANG
version 1 modules together with YANG version 1.1 modules.  Without
this rule, updating a single module to YANG version 1.1 would have a
cascading effect on modules that import it, requiring all of them to
also be updated to YANG version 1.1, and so on.

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

Note that this text again talks about NETCONF in the main text...


/martin


From nobody Tue Sep 15 08:00:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3B81B33B2 for ; Tue, 15 Sep 2015 08:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6gTLIdrr6UY for ; Tue, 15 Sep 2015 08:00:40 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD24D1ACDFD for ; Tue, 15 Sep 2015 08:00:39 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:5505:a3db:7013:6903] (unknown [IPv6:2001:718:1a02:1:5505:a3db:7013:6903]) by mail.nic.cz (Postfix) with ESMTPSA id 1BC9F181752; Tue, 15 Sep 2015 17:00:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442329238; bh=Gb3wLDjFhUier0v87PFCx4sobqWm/fix8tVrvNXTRmY=; h=From:Date:To; b=daC1Cq7bSj4Mw6EVZvGwqeHVk9EaO2p6301wDB+WcKtWSNMdUdRlpUZFuhLIM6Y9+ j930ovq9XxYEB3d25LCXvdO3zeIAyd97E79Kbm1s+h/eFr2cgUUiGf8UNKleJQWV+u ++gxQxGIR3BR2Aly7GMlQvevBsy63jVyWQwHQSPM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150915.155458.124799884157219010.mbj@tail-f.com>
Date: Tue, 15 Sep 2015 17:00:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local> <20150915.155458.124799884157219010.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 15:00:42 -0000

> On 15 Sep 2015, at 15:54, Martin Bjorklund  wrote:
>=20
> Juergen Schoenwaelder  wrote:
>> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
>>>=20
>>> Sure.  The use case is for example servers that implement ietf-ip
>>> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
>>> update ietf-interfaces to 1.1.  It should still be ok for a server =
to
>>> implement ietf-ip with the new ietf-interfaces.
>>>=20
>>=20
>> Is the confusion is between implements and imports here? The module
>> ietf-ip will _import_ an older version 1 ietf-interfaces while the
>> server _implements_ a newer version 1.1 ietf-interfaces module. Is
>> this not going to work?
>>=20
>>>> Would it not work if an import of ietf-interfaces from a
>>>> version 1 module simply resolves to the latest ietf-interfaces
>>>> revision that is still version 1?
>>>=20
>>> But that would mean either that a server is stuck implementing =
version
>>> 1 modules, or that the server must implement both the version 1 and
>>> version 1.1 module - and we have already said that this isn't
>>> possible.
>>=20
>> But this seems only true if import =3D=3D=3D implemented.
>>=20
>>> A set of simpler rules would be:
>>>=20
>>>   A YANG version 1.1 module MUST NOT include a version 1 module.
>>>   A YANG version 1 module MUST NOT include a version 1.1 module.
>>>=20
>>>   A YANG version 1.1 (sub)module MAY import a version 1 module.
>>>   A YANG version 1 (sub)module MAY import a version 1.1 module.
>>=20
>> It is the last one we are discussing, no? I am trying again: Why is
>> the MAY needed? Why is it not sufficient for a version 1 module to
>> work with an import for (the latest) version 1 module?
>=20
> How about this:
>=20
> -------------------
>=20
> * Coexistence with YANG version 1 @coexistence@
>=20
> A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> and a YANG version 1 module MUST NOT include a YANG version 1.1
> submodule.

Does this apply only to include-by-revision? Because otherwise how can =
we tell?

>=20
> A YANG version 1 module or submodule MUST NOT import a YANG version
> 1.1 module by revision.
>=20
> A YANG version 1.1 module or submodule MAY import a YANG version
> 1 module by revision.
>=20
> If a YANG version 1 module A imports module B without revision, and
> module B is updated to YANG version 1.1, a server MAY implement both

What about imports that are only for groupings/typedefs? =E2=80=9CImplemen=
t=E2=80=9D doesn=E2=80=99t cover this case, and such imported modules =
don=E2=80=99t appear in hello.

Lada

> these modules at the same time.  In such cases, a NETCONF server MUST
> advertise both modules using the rules defined in ^announce^, and
> SHOULD advertise module A and the latest revision of module B that is
> specified with YANG version 1 according	to the rules defined in
> ^RFC6020^.
>=20
> This rule exists in order to allow implementations of existing YANG
> version 1 modules together with YANG version 1.1 modules.  Without
> this rule, updating a single module to YANG version 1.1 would have a
> cascading effect on modules that import it, requiring all of them to
> also be updated to YANG version 1.1, and so on.
>=20
> ----------------
>=20
> Note that this text again talks about NETCONF in the main text...
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Sep 15 08:02:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47DC1B4FB9 for ; Tue, 15 Sep 2015 08:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj5Fx-8XEYsD for ; Tue, 15 Sep 2015 08:02:02 -0700 (PDT)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 85D5C1B4FB8 for ; Tue, 15 Sep 2015 08:02:01 -0700 (PDT)
Received: by lbbmp1 with SMTP id mp1so86860006lbb.1 for ; Tue, 15 Sep 2015 08:01:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G+RhpIqMgP6M0SC6wAAhHO6csIcJXdlgMfxY9mTkzw4=; b=gLRtAvpXZHeEWGDlQl2pblqZQOBUei4s8eetlh/Yr5oMJ85H6m5uKAadpqp1fls/vb oBBTZuYnKk8hIS9AH9hMJc/U1j3qZYNxtd7Yt/LGBZU9lgpLtkDU+AIZ71X+lS3N+83f fyBZfM2KhYDGQ9MN+NlKKi1VIwUzyKLFUN2dVpMcOjSp0QzJ4icmzhB3s0hK0sD5Vj0u /I8kK7j96H+43PWiseoXnoa4FP788jexPYJUVu0vSmQ6gZ+PY1BownyOmEqFEuoU92KU lAAB6NMZpME8pdlWYb+CEttUgIVBmtCTnBXtZA4ruEkJPxCA5Jaq75kSJZKhWJl65KQP cUhw==
X-Gm-Message-State: ALoCoQkAvZqu7/97U2XQN6+tjQ1EjSQ0YxNWYPxz5fxpe4OQcoJ7EULfnFWnnTg1aX55s3p8pryt
MIME-Version: 1.0
X-Received: by 10.152.21.99 with SMTP id u3mr19481465lae.123.1442329319679; Tue, 15 Sep 2015 08:01:59 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 15 Sep 2015 08:01:59 -0700 (PDT)
In-Reply-To: 
References: <20150910.125522.373110083925215588.mbj@tail-f.com> <20150914.151914.2175290465760083078.mbj@tail-f.com> <20150914134328.GC67363@elstar.local> <20150914.155459.2278672283743232721.mbj@tail-f.com> <20150914150234.GA67696@elstar.local>    
Date: Tue, 15 Sep 2015 08:01:59 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0149397abfc7d7051fca76ca
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 15:02:05 -0000

--089e0149397abfc7d7051fca76ca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 15, 2015 at 6:47 AM, Ladislav Lhotka  wrote:

>
> > On 15 Sep 2015, at 15:22, Andy Bierman  wrote:
> >
> >
> >
> > On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> >
> > > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > >> >
> > >> > Sure.  The use case is for example servers that implement ietf-ip
> > >> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > >> > update ietf-interfaces to 1.1.  It should still be ok for a server
> to
> > >> > implement ietf-ip with the new ietf-interfaces.
> > >> >
> > >>
> > >> Is the confusion is between implements and imports here? The module
> > >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> > >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> > >> this not going to work?
> > >>
> > >
> > >
> > > Here is the guidance put in RFC 6020 for this occasion:
> > >
> > >    Handling of the "yang-version" statement for versions other than "=
1"
> > >    (the version defined here) is out of scope for this specification.
> > >    Any document that defines a higher version will need to define the
> > >    backward compatibility of such a higher version.
> > >
> > >
> > > All current Yuma based tools see the yang-version 1.1; and exit:
> > >
> > >     ietf-entity.yang:54.16: error(314): wrong version
> > >
> > >     Error: cannot continue with unknown YANG language version
> >
> > I don't think this has to be a strict rule for clients. After all, a
> > client can send any request and it is up to the server to decide whethe=
r
> > the request is valid and send a reply or error message.
> >
> >
> > Not sure what you mean.
> > A tool that does not claim conformance because it does not recognize th=
e
> > YANG language does not have any rules to follow.
> >
> > We cannot make any rules whatsoever that a YANG 1.0 tool
> > must follow wrt/ other YANG language versions.  That much is rather
> clear.
>
> I don=E2=80=99t want to enforce classification of clients and then requir=
e that a
> 1.0 client MUST exit when seeing yang-version 1.1.
>
>

The YANG 1.0 spec was already published.

For a YANG 1.0 implementation there are no rules for how it must deal
with a yang-version value other than '1'.

The behavior is out of scope.
Anything a YANG 1.0 tool does with 1.1, including exit right away, is
compliant.


> Lada
>
>

Andy


> >
> > >
> > >
> > >
> > > The solution outlined this morning should mostly work.
> > > A YANG 1.0 client may be able to use only revisions written in YANG
> 1.0,
> > > even if the server has upgrades some of those modules to YANG 1.1.
> > > Note that a server has total control when it introduces modules
> > > written in YANG 1.1. Not the client.
> > >
> > > If module 'foo' is upgraded to a new module revision,
> > > and the new module revision uses YANG 1.1, then
> > > the server will advertise the last YANG 1.0
> > > revision for module 'foo' in the YANG 1.0 .
> > > The YANG 1.1 library will contain both module revisions,
> > > and the server will set conformance to 'implement' for the 1.1
> > > version.
> >
> > Does this apply only to the case when the old and new revisions of "foo=
"
> are
> > identical except for yang-version?
> >
> >
> > It is up to the server vendor, as Martin said.
> >
> >
> > >
> > > If the data that existed in the last revision written in YANG 1.0
> > > has changed in the implemented revision written in YANG 1.1,
> > > then the server should not (or must not?) advertise the 'phantom'
> > > YANG 1.0 revision anymore.
> >
> > But then an old 1.0-only client is stuck, right?
> >
> >
> > Yep -- the version written in YANG 1.1 might diverge from the last
> revision
> > written in YANG 1.0.  Then forklift upgrades are needed.  And since YAN=
G
> is far
> > from stable, one might expect to go through churn every year until YANG
> is stable.
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > >
> > >  Andy
> > >
> > >
> > >
> > >> > > Would it not work if an import of ietf-interfaces from a
> > >> > > version 1 module simply resolves to the latest ietf-interfaces
> > >> > > revision that is still version 1?
> > >> >
> > >> > But that would mean either that a server is stuck implementing
> version
> > >> > 1 modules, or that the server must implement both the version 1 an=
d
> > >> > version 1.1 module - and we have already said that this isn't
> > >> > possible.
> > >>
> > >> But this seems only true if import =3D=3D=3D implemented.
> > >>
> > >> > A set of simpler rules would be:
> > >> >
> > >> >    A YANG version 1.1 module MUST NOT include a version 1 module.
> > >> >    A YANG version 1 module MUST NOT include a version 1.1 module.
> > >> >
> > >> >    A YANG version 1.1 (sub)module MAY import a version 1 module.
> > >> >    A YANG version 1 (sub)module MAY import a version 1.1 module.
> > >>
> > >> It is the last one we are discussing, no? I am trying again: Why is
> > >> the MAY needed? Why is it not sufficient for a version 1 module to
> > >> work with an import for (the latest) version 1 module?
> > >>
> > >> /js
> > >>
> > >> --
> > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germa=
ny
> > >> Fax:   +49 421 200 3103         
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Tue, Sep 15, 2015 at 6:47 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 15 Sep 2015, at 15:22, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Andy Bierman <andy@yumaworks.=
com> writes:

>

> > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <

> > j.schoenw=
aelder@jacobs-university.de> wrote:

> >

> >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wr=
ote:

> >> >

> >> > Sure.=C2=A0 The use case is for example servers that imp=
lement ietf-ip

> >> > (which imports ietf-interfaces), and ietf-interfaces.=C2=
=A0 Suppose we

> >> > update ietf-interfaces to 1.1.=C2=A0 It should still be =
ok for a server to

> >> > implement ietf-ip with the new ietf-interfaces.

> >> >

> >>

> >> Is the confusion is between implements and imports here? The =
module

> >> ietf-ip will _import_ an older version 1 ietf-interfaces whil=
e the

> >> server _implements_ a newer version 1.1 ietf-interfaces modul=
e. Is

> >> this not going to work?

> >>

> >

> >

> > Here is the guidance put in RFC 6020 for this occasion:

> >

> >=C2=A0 =C2=A0 Handling of the "yang-version" statement f=
or versions other than "1"

> >=C2=A0 =C2=A0 (the version defined here) is out of scope for this =
specification.

> >=C2=A0 =C2=A0 Any document that defines a higher version will need=
 to define the

> >=C2=A0 =C2=A0 backward compatibility of such a higher version.

> >

> >

> > All current Yuma based tools see the yang-version 1.1; and exit:<=
br>
> >

> >=C2=A0 =C2=A0 =C2=A0ietf-entity.yang:54.16: error(314): wrong vers=
ion

> >

> >=C2=A0 =C2=A0 =C2=A0Error: cannot continue with unknown YANG langu=
age version

>

> I don't think this has to be a strict rule for clients. After all,=
 a

> client can send any request and it is up to the server to decide wheth=
er

> the request is valid and send a reply or error message.

>

>

> Not sure what you mean.

> A tool that does not claim conformance because it does not recognize t=
he

> YANG language does not have any rules to follow.

>

> We cannot make any rules whatsoever that a YANG 1.0 tool

> must follow wrt/ other YANG language versions.=C2=A0 That much is rath=
er clear.



I don=E2=80=99t want to enforce classification of clients and then require =
that a 1.0 client MUST exit when seeing yang-version 1.1.




The YANG 1.0 spec was a=
lready published.

For a YANG 1.0 implementation th=
ere are no rules for how it must deal
with a yang-version value o=
ther than '1'.

The behavior is out of scop=
e.
Anything a YANG 1.0 tool does with 1.1, including exit right a=
way, is compliant.
=C2=A0

Lada




Andy
=C2=A0

>

> >

> >

> >

> > The solution outlined this morning should mostly work.

> > A YANG 1.0 client may be able to use only revisions written in YA=
NG 1.0,

> > even if the server has upgrades some of those modules to YANG 1.1=
.

> > Note that a server has total control when it introduces modules
> > written in YANG 1.1. Not the client.

> >

> > If module 'foo' is upgraded to a new module revision,

> > and the new module revision uses YANG 1.1, then

> > the server will advertise the last YANG 1.0

> > revision for module 'foo' in the YANG 1.0 <hello>.<=
br>
> > The YANG 1.1 library will contain both module revisions,

> > and the server will set conformance to 'implement' for th=
e 1.1

> > version.

>

> Does this apply only to the case when the old and new revisions of &qu=
ot;foo" are

> identical except for yang-version?

>

>

> It is up to the server vendor, as Martin said.

>

>

> >

> > If the data that existed in the last revision written in YANG 1.0=


> > has changed in the implemented revision written in YANG 1.1,

> > then the server should not (or must not?) advertise the 'phan=
tom'

> > YANG 1.0 revision anymore.

>

> But then an old 1.0-only client is stuck, right?

>

>

> Yep -- the version written in YANG 1.1 might diverge from the last rev=
ision

> written in YANG 1.0.=C2=A0 Then forklift upgrades are needed.=C2=A0 An=
d since YANG is far

> from stable, one might expect to go through churn every year until YAN=
G is stable.

>

>

> Lada

>

>

> Andy

>

>

> >

> >

> >=C2=A0 Andy

> >

> >

> >

> >> > > Would it not work if an import of ietf-interfaces f=
rom a

> >> > > version 1 module simply resolves to the latest ietf=
-interfaces

> >> > > revision that is still version 1?

> >> >

> >> > But that would mean either that a server is stuck implem=
enting version

> >> > 1 modules, or that the server must implement both the ve=
rsion 1 and

> >> > version 1.1 module - and we have already said that this =
isn't

> >> > possible.

> >>

> >> But this seems only true if import =3D=3D=3D implemented.

> >>

> >> > A set of simpler rules would be:

> >> >

> >> >=C2=A0 =C2=A0 A YANG version 1.1 module MUST NOT include =
a version 1 module.

> >> >=C2=A0 =C2=A0 A YANG version 1 module MUST NOT include a =
version 1.1 module.

> >> >

> >> >=C2=A0 =C2=A0 A YANG version 1.1 (sub)module MAY import a=
 version 1 module.

> >> >=C2=A0 =C2=A0 A YANG version 1 (sub)module MAY import a v=
ersion 1.1 module.

> >>

> >> It is the last one we are discussing, no? I am trying again: =
Why is

> >> the MAY needed? Why is it not sufficient for a version 1 modu=
le to

> >> work with an import for (the latest) version 1 module?

> >>

> >> /js

> >>

> >> --

> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen gGmbH

> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp=
us Ring 1 | 28759 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/>

> >>

> >> _______________________________________________

> >> netmod mailing list

> >> netmod@ietf.org

> >> https://www.ietf.org/mailman/listinfo/net=
mod

> >>

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/netmod

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--089e0149397abfc7d7051fca76ca--


From nobody Tue Sep 15 08:21:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA551A00C1 for ; Tue, 15 Sep 2015 08:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9pZGtFQ_8BG for ; Tue, 15 Sep 2015 08:21:23 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A1A1A00BE for ; Tue, 15 Sep 2015 08:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3509; q=dns/txt; s=iport; t=1442330483; x=1443540083; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=5qkMMlHNlyYVJGpyAt6Zk/xBK6JLTbaHfqAG0ykfAsc=; b=nBskZAkNnpMYW4aYPK24QkLKD19Q7S1lpz8x361GJI1Af21GuyYLDMto DncHnX6y65dRQjq7GoKnZ2SMfgJTvOzLbd20xYX9yNRmlWtAa/Cw9KrsJ Us2DTeoEC1koGyznrzcjDQ8wvDDEnFWxpDbRU0ixRmwYg7YdxKMhG3viz Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D0AQD2NvhV/4QNJK1VCIMjVGkGvUcBDYFvDIUtSoFAOBQBAQEBAQEBgQqEIwEBAQMBAQEBNzQLBQcGAR0hNwsmAQQBDQUIEQKICwgNymABAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOJMwxLhDMFjHcBiGQBhQ+JQEaVB4NrAR8BAUKCERwWgT5xiSWBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,536,1437436800"; d="scan'208";a="29085713"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 15 Sep 2015 15:21:11 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t8FFLBv1006399 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Sep 2015 15:21:11 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Sep 2015 10:21:10 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Tue, 15 Sep 2015 10:21:10 -0500
From: "Eric Voit (evoit)" 
To: Ladislav Lhotka , Randy Presuhn , "netmod@ietf.org" , "Rob Shakir" 
Thread-Topic: YANG Mount = Alias Mount + Peer Mount    (was RE: [netmod] Motivations for Structuring Models)
Thread-Index: AdDvyhrI2wLjsCf6TN+s18UjF8BE5Q==
Date: Tue, 15 Sep 2015 15:21:10 +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.118.56.229]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Sander Mertens 
Subject: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 15:21:24 -0000

There was a recent thread on structuring YANG models so that application de=
velopers might be able to reference alternative local hierarchies/tree stru=
ctures for certain objects.  This thread motivated Alex, Sander, and I to r=
ework the YANG Mount requirements draft.  v03 is posted at:
http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/

This draft has been retitled to "Requirements for mounting of local and rem=
ote YANG subtrees".  This retitling was done because we have separated the =
thinking on what it takes to Mount objects from remote devices (Peer Mount)=
 from what it takes to Mount within the same device (Alias Mount).

We would be interested in your thoughts.  =20

Eric

-----Original Message-----
From: Ladislav Lhotka, August 31, 2015 11:05 AM

Randy Presuhn  writes:

> Hi -
>
> It is with no little amusement that I watch this thread struggling=20
> with questions that were solved fairly neatly a quarter century ago in=20
> GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like=20
> to offer an observation about modeling that might help.
>
> The organization of instance data in SNMP is a direct mirror of the=20
> "object" definitions.  Simple at first, but quickly becoming baroque=20
> as various minds of "multiplexing" are added to compensate for post=20
> hoc deficiencies in the index structures.
>
> Life is such that once a resource has been modeled, it will be=20
> used/re-used/embedded in systems in ways in which its designers=20
> couldn't be expected to imagine.  A consequence of this is that if=20
> instance naming is completely locked down when the management=20
> interface for a resource is first defined (as it is in SNMP) then all=20
> sorts of peculiar hacks will be needed to deal with, for example,=20
> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so=20
> pervasive that folks seem to overlook that there are other ways to=20
> deal with this situation.
>
> What GDMO did was to use a separate "NAME BINDING" construct to=20
> specify contexts in which instances might show up, allowing instances=20
> to be put in places that weren't even imagined when the original class=20
> definition was written.  Name bindings could be standardized, or be=20
> vendor or even product-specific, allowing the simplicity or complexity=20
> of a given system's instance tree to reflect the actual simplicity or=20
> complexity of that system, rather than requiring all systems to be=20
> structured for the worst case.

How could this be expressed in YANG terms? (I tried to figure it out myself=
 but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommend=
ation X.722).

Thanks, Lada

>
> Yes, separating the specification of instance naming in large part=20
> from class definition does have implications for how one does access=20
> control, and how clients figure out how to ask a server to create=20
> something, but it's not a huge deal - it's just not like VACM, and a=20
> whole slew of hacky solutions and "wierd plumbing adapters" (to borrow=20
> from Jeff Case) just go away.  Strangely, it makes the job of the=20
> initial modeler and of the eventual user much easier.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 15 12:02:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8A1AC3EC for ; Tue, 15 Sep 2015 12:02: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMSeIcKREIWI for ; Tue, 15 Sep 2015 12:02:00 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 258DC1AC401 for ; Tue, 15 Sep 2015 12:01:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=i0oyMlwH0EgRT5zQFTvXfddNqYGFdgoAb5fWqUR/WmN+l8pfF2rIXee7+Zu8VKEh; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZbvTn-0006dz-Lt for netmod@ietf.org; Tue, 15 Sep 2015 15:01:23 -0400
Received: from 76.254.52.109 by webmail.earthlink.net with HTTP; Tue, 15 Sep 2015 15:01:23 -0400
Message-ID: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
Date: Tue, 15 Sep 2015 12:01:23 -0700 (GMT-07:00)
From: Randy Presuhn 
To: NETMOD Working Group 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed10fc002c327962da51ca18f113355dd1350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.42
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 19:02:06 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Sep 14, 2015 11:41 PM
>To: Ladislav Lhotka 
>Cc: NETMOD Working Group 
>Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
...
>My question is why the text is silent about the case where the data
>model is present. Should it not say that if the data model is present,
>the data encoded inside the anydata node must follow the rules of this
>document? Perhaps this is the implicit assumption but I think it will
>be useful to say this explicitly (if we agree on this).
>
>If the data model is not present, then I think an implementation is
>still expected to produce an encoding that follows the rules of this
>document as much as possible except that things that requires data
>model knowledge may be encoded differently (e.g., numbers appearing as
>strings or namespace names being different). I am thinking along the
>lines of this proposed new text:
>
>   An anydata data node can contain an unknown set of nodes that can
>   be modelled by YANG. A data model for anydata content may or may
>   not exist at run time.  If the data model for anydata content is
>   available, then the anydata content MUST be encoded according to
>   the rules of this specification. If the data model for anydata
>   content is not available, the encoding MUST follow the rules of
>   this specification except for rules that require data model
>   knowledge (and as a consequence, numbers may appear as strings or
>   namespace qualifiers may not match module names).

This leaves me wondering what it means for the data model for
anydata content to be "available".  In the case of ASN.1's
"ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
unambiguously identify the grammar (and associated semantics)
to be used to understand the content, so tools can, if needed,
scurry off to obtain the parsing instructions for those
particular bits.  How does an implementation know in the case
of "anydata" which datamodel to use?

Randy


From nobody Tue Sep 15 12:21:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF221AC445 for ; Tue, 15 Sep 2015 12:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ2rC-liLBDk for ; Tue, 15 Sep 2015 12:21:47 -0700 (PDT)
Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 E73C81AC435 for ; Tue, 15 Sep 2015 12:21:46 -0700 (PDT)
Received: by lamp12 with SMTP id p12so113259685lam.0 for ; Tue, 15 Sep 2015 12:21:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Wmott1WF4WU4y7dmjKnQu54lvtTrxNEPxf1xppB59Mg=; b=TFoMv6f9owya1U9l4B30Fw1dq5I/CZQcFtAt8O54ZY3BGwZhbztpd9SqrMG9HfwBFr S1r9dGjKWNKGnvD6c34NmhF4YQBAMKpPvkWMGFchm7v0XobAWTu7UWF7Ertcvdk1FaT8 Y40mROuqtNmE+MzL3NE5Lv52BRsir31E1Eb27jRNroSHFqSR/mvGBKH9XzLPKb8YSxMe kVmDgKJRp2Nxq2UbSeZ8C9oeCIBrbxaK086hfCRjxjLULXUzu4x/YINtxx2up+xRTv4I +QTS5/kvMKtI2vowMmEYkE6j7kvgTWRotZZwHBTrL8X+29Z0/gCRF0twfjmhRM4LHZVN 85kg==
X-Gm-Message-State: ALoCoQlvNQyKauCph1FeMq+JssUocUHV79vaS/3vR9GkVAeF/sDCpBNYinuIMGO2hdjnU3ZtDNmg
MIME-Version: 1.0
X-Received: by 10.152.21.99 with SMTP id u3mr21686104lae.123.1442344904951; Tue, 15 Sep 2015 12:21:44 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 15 Sep 2015 12:21:44 -0700 (PDT)
In-Reply-To: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
Date: Tue, 15 Sep 2015 12:21:44 -0700
Message-ID: 
From: Andy Bierman 
To: Randy Presuhn 
Content-Type: multipart/alternative; boundary=089e0149397ab424bc051fce170d
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 19:21:49 -0000

--089e0149397ab424bc051fce170d
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
randy_presuhn@mindspring.com> wrote:

> Hi -
>
> >From: Juergen Schoenwaelder 
> >Sent: Sep 14, 2015 11:41 PM
> >To: Ladislav Lhotka 
> >Cc: NETMOD Working Group 
> >Subject: Re: [netmod] Fwd: New Version Notification for
> draft-ietf-netmod-yang-json-05.txt
> ...
> >My question is why the text is silent about the case where the data
> >model is present. Should it not say that if the data model is present,
> >the data encoded inside the anydata node must follow the rules of this
> >document? Perhaps this is the implicit assumption but I think it will
> >be useful to say this explicitly (if we agree on this).
> >
> >If the data model is not present, then I think an implementation is
> >still expected to produce an encoding that follows the rules of this
> >document as much as possible except that things that requires data
> >model knowledge may be encoded differently (e.g., numbers appearing as
> >strings or namespace names being different). I am thinking along the
> >lines of this proposed new text:
> >
> >   An anydata data node can contain an unknown set of nodes that can
> >   be modelled by YANG. A data model for anydata content may or may
> >   not exist at run time.  If the data model for anydata content is
> >   available, then the anydata content MUST be encoded according to
> >   the rules of this specification. If the data model for anydata
> >   content is not available, the encoding MUST follow the rules of
> >   this specification except for rules that require data model
> >   knowledge (and as a consequence, numbers may appear as strings or
> >   namespace qualifiers may not match module names).
>
> This leaves me wondering what it means for the data model for
> anydata content to be "available".  In the case of ASN.1's
> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> unambiguously identify the grammar (and associated semantics)
> to be used to understand the content, so tools can, if needed,
> scurry off to obtain the parsing instructions for those
> particular bits.  How does an implementation know in the case
> of "anydata" which datamodel to use?
>
>
Good questions....
The text "If the data model for anydata content is available" gives a hint
of just
what a hack anydata is in YANG.  The definition of anydata is that there is
no data model for the specified subtree.  The mere mention of an out-of-band
data mode is inappropriate and confusing.

I understand this is intended to support usage like in YANG Patch, where the
description-stmt of 'value' says that the child node must follow the schema
for the node in the target leaf.  More hacks to get YANG to work.

Once again we confuse conformance to YANG with conformance to
a module written in YANG.  The YANG Patch text can make additional
requirements for conformance to YANG Patch.  This is quite different
than generic conformance to RFC6020bis.




Randy
>


Andy


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

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




On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <<=
a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres=
uhn@mindspring.com> wrote:
Hi -



>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

>Sent: Sep 14, 2015 11:41 PM

>To: Ladislav Lhotka <lhotka@nic.cz<=
/a>>

>Cc: NETMOD Working Group <netmod@=
ietf.org>

>Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netm=
od-yang-json-05.txt

...

>My question is why the text is silent about the case where the data

>model is present. Should it not say that if the data model is present,<=
br>
>the data encoded inside the anydata node must follow the rules of this<=
br>
>document? Perhaps this is the implicit assumption but I think it will
>be useful to say this explicitly (if we agree on this).

>

>If the data model is not present, then I think an implementation is

>still expected to produce an encoding that follows the rules of this
>document as much as possible except that things that requires data

>model knowledge may be encoded differently (e.g., numbers appearing as<=
br>
>strings or namespace names being different). I am thinking along the
>lines of this proposed new text:

>

>=C2=A0 =C2=A0An anydata data node can contain an unknown set of nodes t=
hat can

>=C2=A0 =C2=A0be modelled by YANG. A data model for anydata content may =
or may

>=C2=A0 =C2=A0not exist at run time.=C2=A0 If the data model for anydata=
 content is

>=C2=A0 =C2=A0available, then the anydata content MUST be encoded accord=
ing to

>=C2=A0 =C2=A0the rules of this specification. If the data model for any=
data

>=C2=A0 =C2=A0content is not available, the encoding MUST follow the rul=
es of

>=C2=A0 =C2=A0this specification except for rules that require data mode=
l

>=C2=A0 =C2=A0knowledge (and as a consequence, numbers may appear as str=
ings or

>=C2=A0 =C2=A0namespace qualifiers may not match module names).



This leaves me wondering what it means for the data model for

anydata content to be "available".=C2=A0 In the case of ASN.1'=
;s

"ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
unambiguously identify the grammar (and associated semantics)

to be used to understand the content, so tools can, if needed,

scurry off to obtain the parsing instructions for those

particular bits.=C2=A0 How does an implementation know in the case

of "anydata" which datamodel to use?



Good questions....
The text =
"If the data model for anydata content is available" gives a hint=
 of just
what a hack anydata is in YANG.=C2=A0 The definition of =
anydata is that there is
no data model for the specified subtree.=
=C2=A0 The mere mention of an out-of-band
data mode is inappropri=
ate and confusing.

I understand this is intended t=
o support usage like in YANG Patch, where the
description-stmt of=
 'value' says that the child node must follow the schema
=
for the node in the target leaf.=C2=A0 More hacks to get YANG to work.

Once again we confuse conformance to YANG with conform=
ance to
a module written in YANG.=C2=A0 The YANG Patch text can m=
ake additional
requirements for conformance to YANG Patch.=C2=A0 =
This is quite different
than generic conformance to RFC6020bis.





Randy


Andy
=C2=
=A0



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--089e0149397ab424bc051fce170d--


From nobody Tue Sep 15 14:21:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFCC1B2A58 for ; Tue, 15 Sep 2015 14:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8dZtasqNnpi for ; Tue, 15 Sep 2015 14:21:39 -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 9CB0B1B2A54 for ; Tue, 15 Sep 2015 14:21:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 23E091364 for ; Tue, 15 Sep 2015 23:21:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pZmmjQEvuMDT for ; Tue, 15 Sep 2015 23:21: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 for ; Tue, 15 Sep 2015 23:21:34 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 844EF2004E for ; Tue, 15 Sep 2015 23:21:34 +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 smOJ9uCILms2; Tue, 15 Sep 2015 23:21:32 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75D1320048; Tue, 15 Sep 2015 23:21:32 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9A0183722851; Tue, 15 Sep 2015 23:21:29 +0200 (CEST)
Date: Tue, 15 Sep 2015 23:21:29 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20150915212129.GB74650@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] minutes of the NETMOD 2015-09-14 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 21:21:41 -0000

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached are the minutes of the 2015-09-14 virtual interim meeting.
Please let me know if something needs fixing.

You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="netmod-2015-09-14-minutes.txt"
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit

=============================================================
NETCONF Data Modeling Language WG (netmod)
21st YANG 1.1 Virtual Interim
Monday, September 14th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  AB = Andy Bierman
  BC = Benoit Claise
  JS = Juergen Schoenwaelder
  KW = Kent Watsen
  LL = Ladislav Lhotka
  MB = Martin Bjrklund
  TC = Tim Carey

* Coexistence Discussion

  There was some mailing list discussion around this topic since the
  last virtual interim meeting. Have we arrived at a resolution?

  LL: I think there can be issues even with a version 1 only server.
  MB: Why is there a problem with a version 1 only server?
  LL: What if client knows a 1.1 module and picks it instead?
  MB: The client must respect the modules announced by the server.
  MB: The latest revision is the latest revision advertised by the
      server, not the latest locally known revision.
	
  JS: We seem to have three options:

      1. If there is a 1.1 revision somewhere in the imports, the
         version 1 module is parsed as a 1.1 module.
      2. Version 1 modules are not allowed to import 1.1 modules, this
         means a server may need to announce the version of a module
         implemented and the version that may be used to resolve
         version 1 imports without revision.
      3. We allow version 1 modules to import from version 1.1
         modules.
	
  AB: The goal is not to break old clients. If adding 1.1 modules
      breaks clients, this is a problem for deployment.
  KW: Perhaps the problem is not big enough to worry about? This is
      just a one time software version upgrade.
  AB: What if we next do 1.2 etc? A massive upgrade without a real
      benefit may not be useful.
  AB: This problem would not exist if there would have been import by
      revision everywhere.
 
  AB: The version 1 client only knows about the hello module
      advertisements. So what about allowing an old client to continue
      with its view of world even if the server implements a 1.1
      version?
  LL: Does this not break with default statements that have changed a
      bit in YANG 1.1?
  MB: The old client will not see the default statement, I do not
      think this is a problem.
  KW: But it impacts things, e.g., when the client uses with-defaults.
	
  AB: It is important that the version upgrade to YANG 1.1 is a cheap
      and gradual process.
  MB: I agree.
	
  MB: If we upgrade ietf-interfaces to YANG 1.1, we still want to be
      able to use the YANG version 1 version of ietf-ip, which has not
      changed at all. We do not want to force a revision of ietf-ip
      just because ietf-interfaces a server implements got upgraded to
      1.1.
  
  TC: Why would a 1.0 client not utilize 1.0 data models?
  MB: Does this mean to implement multiple revisions? It depends on the
      changes whether this is expensive.
   
  TC: Does the minor version not imply nodes should be backwards
      compatible?
  JS: Lets not confuse data model version number and the version of
      the language data models are written in.
	
  JS: Announce YANG 1 modules via  messages and YANG 1.1
      modules via the YANG the library as long as they are
      semantically consistent, that is the YANG version 1 module
      remains a proper valid subset of the module written in YANG 1.1.
	
  KW: Is there an issue with get-schema?
  MB: No, there is a version input parameter that makes this clear.
	
  Action: Add text and examples to the guidelines document explaining
          how servers implementing YANG 1.1 modules can support
          modules written in YANG version 1 and when in which
          situations servers might need to stop supporting modules
          written in YANG version 1.

* Constraints Discussion

  LL and MB discuss something internally, they will summarize the
  proposal to the list once they conclude the discussion.

--3MwIy2ne0vdjdPXF--


From nobody Tue Sep 15 15:15:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673B21B2BFE for ; Tue, 15 Sep 2015 15:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQjTzZ9sCX6O for ; Tue, 15 Sep 2015 15:15:22 -0700 (PDT)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 CF1131B2BF8 for ; Tue, 15 Sep 2015 15:15:21 -0700 (PDT)
Received: by lbbvu2 with SMTP id vu2so21341254lbb.0 for ; Tue, 15 Sep 2015 15:15:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=r0YNkp0oXpkS5YfsSzPK8qFOgWPoGenxFC+tf+U1YmQ=; b=R/Afy7r+7qUO4O3gujVgNLlewDGwYBtTmCpk4fDyuTcYs7QgVegI8HjeA5MuPiaHJV Tbhtjwz9bM2u2sgtX3HMBRgH3g8eg7atXJav5Vf5UXmF4utmxv5ePeOnL9RQjZsBduqa Kmk9phos/RzFAvnmWHiZSXmJNi8Mrfn2Y3ebzDMFdSKGoLCi+/pwmqjUNo4yhlGkLyK7 9g4w0rbOqNkfe/c2CmbPBa/W8qHRWe/p+NkLOyOm1xB4NInTWsWt7AGOvzaEemTl9dqi krkWiEnHBhvHyZtppw7Y3GsADiZLBJeOAQjnLZR2AdJtOUp55mWnDqOgQFpzJqOuqI8C PaTA==
X-Gm-Message-State: ALoCoQlLo8Kge20XfjWkK+nBZdNBDO4+c1c1wPzqAmbhQYFUGMlhpNHox/nJc8pUjfvouXaEdBOY
MIME-Version: 1.0
X-Received: by 10.112.156.167 with SMTP id wf7mr25077826lbb.88.1442355320077;  Tue, 15 Sep 2015 15:15:20 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 15 Sep 2015 15:15:20 -0700 (PDT)
Date: Tue, 15 Sep 2015 15:15:20 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c27b267e57e7051fd084ad
Archived-At: 
Subject: [netmod] YANG 1.0 behavior for leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 22:15:23 -0000

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

Hi,

The leafref text was changed to allow the require-instance-stmt in YANG 1.1

RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.

9.9.1.  Restrictions

   A leafref cannot be restricted.

9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance"
   statement (Section 9.13.2).


However, the ABNF on page 149 clearly contradicts the text in 9.9.1:

  leafref-specification =
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

   path-stmt           = path-keyword sep path-arg-str stmtend

   require-instance-stmt = require-instance-keyword sep
                            require-instance-arg-str stmtend



So which normative text is correct?
Is instance-required-stmt allowing in YANG 1.0?


Andy

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


Hi,

The leafref text was changed to all=
ow the require-instance-stmt in YANG 1.1

RFC 6020,=
 sec. 9.9. is quite clear that this sub-statement is not allowed.

9.9.1.  Restrictions

   A leafref cannot be restricted.
9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance=
"
   statement (Section 9.13.2).


However, the ABNF on page 149 clearly contr=
adicts the text in 9.9.1:

  leafref-specification =
=3D
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

   path-stmt           =3D path-keyword sep path-arg-str stmtend

   require-instance-stmt =3D require-instance-keyword sep
                            require-instance-arg-str stmtend



So which normative text is c=
orrect?
Is instance-required-stmt allowing in YANG 1.0?


Andy



--001a11c27b267e57e7051fd084ad--


From nobody Tue Sep 15 16:28:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670C41B2E3B for ; Tue, 15 Sep 2015 16:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyDAKOWZWlzU for ; Tue, 15 Sep 2015 16:28:39 -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 E9ACA1B2E34 for ; Tue, 15 Sep 2015 16:28:38 -0700 (PDT)
Received: by vkhf67 with SMTP id f67so90588067vkh.1 for ; Tue, 15 Sep 2015 16:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oETbMDjgP88zYkhXgmPpvoL8RIcUihSK36zXpO/oj44=; b=VKTpEfL3DOc51Qlryw3bist3rL7HF4sIXJVYhIorTclX5KDPdz4vA8IufAaAJtSmMW 2hg7PrBUvUsnTtrrPIbMBQ0+ZIBvHfO97SiyH49khawnFvRTeGz1KmRLY0sNLqIaiMSV h/crKZN6+YP9CZEyIewSL/IKEXrtNXq/d8q8gxy6HdRf40YRA2KvhqNlixTbJF3nvuaP YsU1NMoRX08/M/p2JVtDF/2LwyQVg86qAcEZIE4Rpj9peBpjBTmxKIXQTeAiQ0LATrcW CPswoyxy6rF31Ap5AWySBlmx4Xf4/FNEOU2+Iv5rHsiXYcEfcCxsBl9cO/pYFOO+7g5t zTqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oETbMDjgP88zYkhXgmPpvoL8RIcUihSK36zXpO/oj44=; b=GEh3vCHen22ZZZpVfKyZp1RnnicVkWkefyaK2Hu0SLtXGeRYfNn46j1Ux2eoYTLN3M qbsAcatD7g+6O2hqEMK+WQqHrACzMyzTuGTnS6TQVJvSE3ZcNvxMyq5YCsvAYxD0HP4n Aj7T8VjFtBsy+ELipjgZZh9v1If97/0T6DcLg7PXhcuHB4HUIyXxTIq8FGWJ9Nbw+unV Mas+CPIm70RfkXUN61w2ieBQNp4Mq+BHrql5WwRH8XdYvGjEMNer6i1mV4WxF3xkWEg0 ze4PMmlISrjt8BgGBV2309lkK2eWfrtPbDE7bRR7+yFr++b8DtDqJeOqKRIXzEAUIsaz rXFQ==
X-Gm-Message-State: ALoCoQk4Spat9N8Bsw/UKWqb/TzmAlO0xunIhXFTg1P+G4tXu8oAfRMbBpwwCGBW/I4AS+YG1k4R
MIME-Version: 1.0
X-Received: by 10.31.52.70 with SMTP id b67mr25681623vka.132.1442359717997; Tue, 15 Sep 2015 16:28:37 -0700 (PDT)
Received: by 10.31.189.12 with HTTP; Tue, 15 Sep 2015 16:28:37 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 15 Sep 2015 16:28:37 -0700
Message-ID: 
From: Anees Shaikh 
To: Andy Bierman 
Content-Type: multipart/alternative; boundary=001a1143f7c6a17685051fd18a9c
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG 1.0 behavior for leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Sep 2015 23:28:40 -0000

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

Isn't there already a verified errata for this same issue with the same
recommendation (Errata ID: 2949) ?

-- Anees

On Tue, Sep 15, 2015 at 3:15 PM, Andy Bierman  wrote:

> Hi,
>
> The leafref text was changed to allow the require-instance-stmt in YANG 1.1
>
> RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.
>
> 9.9.1.  Restrictions
>
>    A leafref cannot be restricted.
>
> 9.13.1.  Restrictions
>
>    An instance-identifier can be restricted with the "require-instance"
>    statement (Section 9.13.2).
>
>
> However, the ABNF on page 149 clearly contradicts the text in 9.9.1:
>
>   leafref-specification =
>                          ;; these stmts can appear in any order
>                          path-stmt stmtsep
>                          [require-instance-stmt stmtsep]
>
>    path-stmt           = path-keyword sep path-arg-str stmtend
>
>    require-instance-stmt = require-instance-keyword sep
>                             require-instance-arg-str stmtend
>
>
>
> So which normative text is correct?
> Is instance-required-stmt allowing in YANG 1.0?
>
>
> Andy
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Isn't there already a verified errata for this same is=
sue with the same recommendation (Errata ID: 2949) ?

-- =
Anees

=
On Tue, Sep 15, 2015 at 3:15 PM, Andy Bierman <andy@yumaworks.com>=
 wrote:
Hi,
<=
br>
The leafref text was changed to allow the require-instance-st=
mt in YANG 1.1

RFC 6020, sec. 9.9. is quite clear =
that this sub-statement is not allowed.

9.9.1.  Res=
trictions

   A leafref cannot be restricted.
9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance=
"
   statement (Section 9.13.2).


However, the ABNF on page 149 clearly contr=
adicts the text in 9.9.1:

  leafref-specification =
=3D
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

   path-stmt           =3D path-keyword sep path-arg-str stmtend

   require-instance-stmt =3D require-instance-keyword sep
                            require-instance-arg-str stmtend



So which normative text is c=
orrect?
Is instance-required-stmt allowing in YANG 1.0?


Andy



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1143f7c6a17685051fd18a9c--


From nobody Tue Sep 15 19:44:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262C41B31D6 for ; Tue, 15 Sep 2015 19:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUbBwKROs00G for ; Tue, 15 Sep 2015 19:44:09 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651A21B31C7 for ; Tue, 15 Sep 2015 19:44:09 -0700 (PDT)
Received: by lbcao8 with SMTP id ao8so95672812lbc.3 for ; Tue, 15 Sep 2015 19:44:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CaZCq1vqhJDweQY1doSHLnTG9y6BUgEFtXAbwmDn80c=; b=XH715z8249ZUXEJR0apTRIGlTkzjkd9gkVX2xLt/EvmAiHUnsnOK7njDXpHtEpg/Vq FHCXRwG2FhwpnWW9yUSGiwXRzchargBbaKTqQX0UT1R3fV/jbNr90aNu9DUEhj8o6huU Q7Omm3cCld021qdV2+Q6uiV6iwvqgiU/B6XPIweb0wCkRJo7OUaVHdvGt99jdEnhiSzj K1osBXIBACU8x6B4PURCFTVVKFv5pafe0Iq9cibtJOM1moX5PNsDdQlx4dwkh4CiPUYI GycLdKUYFKMzAe0vOk0abw9C0vLBCdd+BV7reXrgYX+hBABVOnktfwe/VEe/Z/oV26Ko NtcA==
X-Gm-Message-State: ALoCoQkHs/RSzibVAIkY1EaUkP2vWNI+GNLa1xvFoRwHlS0zlTX46IujdLlgHu0Y0PwpJrE8+6ZX
MIME-Version: 1.0
X-Received: by 10.152.179.40 with SMTP id dd8mr545282lac.119.1442371447290; Tue, 15 Sep 2015 19:44:07 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 15 Sep 2015 19:44:07 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 15 Sep 2015 19:44:07 -0700
Message-ID: 
From: Andy Bierman 
To: Anees Shaikh 
Content-Type: multipart/alternative; boundary=001a113433eec01bd6051fd445c2
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG 1.0 behavior for leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 02:44:11 -0000

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

On Tue, Sep 15, 2015 at 4:28 PM, Anees Shaikh  wrote:

> Isn't there already a verified errata for this same issue with the same
> recommendation (Errata ID: 2949) ?
>
>
yes -- sorry for bringing it up.
I should have checked there first.

-- Anees
>

Andy


>
> On Tue, Sep 15, 2015 at 3:15 PM, Andy Bierman  wrote:
>
>> Hi,
>>
>> The leafref text was changed to allow the require-instance-stmt in YANG
>> 1.1
>>
>> RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.
>>
>> 9.9.1.  Restrictions
>>
>>    A leafref cannot be restricted.
>>
>> 9.13.1.  Restrictions
>>
>>    An instance-identifier can be restricted with the "require-instance"
>>    statement (Section 9.13.2).
>>
>>
>> However, the ABNF on page 149 clearly contradicts the text in 9.9.1:
>>
>>   leafref-specification =
>>                          ;; these stmts can appear in any order
>>                          path-stmt stmtsep
>>                          [require-instance-stmt stmtsep]
>>
>>    path-stmt           = path-keyword sep path-arg-str stmtend
>>
>>    require-instance-stmt = require-instance-keyword sep
>>                             require-instance-arg-str stmtend
>>
>>
>>
>> So which normative text is correct?
>> Is instance-required-stmt allowing in YANG 1.0?
>>
>>
>> Andy
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>

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




On Tue, Sep 15, 2015 at 4:28 PM, Anees Shaikh <aashaikh@google.com> wrote:
Isn=
't there already a verified errata for this same issue with the same re=
commendation (Errata ID: 2949) ?


=

yes -- sorry for bringing it up.
I should have checked=
 there first.

-- Anees

Andy

On Tue, Sep 15, 2015 at 3:15 PM=
, Andy Bierman <andy@yumaworks.com> wrote:
Hi,

The leafref text =
was changed to allow the require-instance-stmt in YANG 1.1

RFC 6020, sec. 9.9. is quite clear that this sub-statement is not =
allowed.

9.9.1.  Restrictions

   A leafref cannot be restricted.
9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance=
"
   statement (Section 9.13.2).


However, the ABNF on page 149 clearly contr=
adicts the text in 9.9.1:

  leafref-specification =
=3D
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]

   path-stmt           =3D path-keyword sep path-arg-str stmtend

   require-instance-stmt =3D require-instance-keyword sep
                            require-instance-arg-str stmtend



So which normative text is c=
orrect?
Is instance-required-stmt allowing in YANG 1.0?


Andy



_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod








--001a113433eec01bd6051fd445c2--


From nobody Tue Sep 15 23:03:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71F51B359A for ; Tue, 15 Sep 2015 23:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSW8MMQBhlkS for ; Tue, 15 Sep 2015 23:03:06 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 648661B3590 for ; Tue, 15 Sep 2015 23:03:05 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8FACF1CC008C; Wed, 16 Sep 2015 08:03:08 +0200 (CEST)
From: Ladislav Lhotka 
To: Randy Presuhn , NETMOD Working Group 
In-Reply-To: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 16 Sep 2015 08:03:10 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 06:03:09 -0000

Randy Presuhn  writes:

> Hi -
>
>>From: Juergen Schoenwaelder 
>>Sent: Sep 14, 2015 11:41 PM
>>To: Ladislav Lhotka 
>>Cc: NETMOD Working Group 
>>Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
> ...
>>My question is why the text is silent about the case where the data
>>model is present. Should it not say that if the data model is present,
>>the data encoded inside the anydata node must follow the rules of this
>>document? Perhaps this is the implicit assumption but I think it will
>>be useful to say this explicitly (if we agree on this).
>>
>>If the data model is not present, then I think an implementation is
>>still expected to produce an encoding that follows the rules of this
>>document as much as possible except that things that requires data
>>model knowledge may be encoded differently (e.g., numbers appearing as
>>strings or namespace names being different). I am thinking along the
>>lines of this proposed new text:
>>
>>   An anydata data node can contain an unknown set of nodes that can
>>   be modelled by YANG. A data model for anydata content may or may
>>   not exist at run time.  If the data model for anydata content is
>>   available, then the anydata content MUST be encoded according to
>>   the rules of this specification. If the data model for anydata
>>   content is not available, the encoding MUST follow the rules of
>>   this specification except for rules that require data model
>>   knowledge (and as a consequence, numbers may appear as strings or
>>   namespace qualifiers may not match module names).
>
> This leaves me wondering what it means for the data model for
> anydata content to be "available".  In the case of ASN.1's
> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> unambiguously identify the grammar (and associated semantics)
> to be used to understand the content, so tools can, if needed,
> scurry off to obtain the parsing instructions for those
> particular bits.  How does an implementation know in the case
> of "anydata" which datamodel to use?

It can be stated in the description of the anydata statement. One can
then ask though why we need two constructs - anyxml and anydata -
because a data model can be specified in the description of an anyxml
statement as well.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Sep 16 08:14:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90F61A8AD0 for ; Wed, 16 Sep 2015 08:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJgJAmiH5UxW for ; Wed, 16 Sep 2015 08:14:41 -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 27D351A8A7B for ; Wed, 16 Sep 2015 08:14:41 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E5F3E12E7; Wed, 16 Sep 2015 17:14:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CJ1FSfacSgDn; Wed, 16 Sep 2015 17:14:38 +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, 16 Sep 2015 17:14:38 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2BD120054; Wed, 16 Sep 2015 17:14:38 +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 k5PUzOD9HWGW; Wed, 16 Sep 2015 17:14:37 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 435E620048; Wed, 16 Sep 2015 17:14:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D03BA3723143; Wed, 16 Sep 2015 17:14:33 +0200 (CEST)
Date: Wed, 16 Sep 2015 17:14:33 +0200
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20150916151433.GA76960@elstar.local>
Mail-Followup-To: Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 15:14:43 -0000

On Tue, Sep 15, 2015 at 12:01:23PM -0700, Randy Presuhn wrote:
> Hi -
> 
> >From: Juergen Schoenwaelder 
> >Sent: Sep 14, 2015 11:41 PM
> >To: Ladislav Lhotka 
> >Cc: NETMOD Working Group 
> >Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
> ...
> >My question is why the text is silent about the case where the data
> >model is present. Should it not say that if the data model is present,
> >the data encoded inside the anydata node must follow the rules of this
> >document? Perhaps this is the implicit assumption but I think it will
> >be useful to say this explicitly (if we agree on this).
> >
> >If the data model is not present, then I think an implementation is
> >still expected to produce an encoding that follows the rules of this
> >document as much as possible except that things that requires data
> >model knowledge may be encoded differently (e.g., numbers appearing as
> >strings or namespace names being different). I am thinking along the
> >lines of this proposed new text:
> >
> >   An anydata data node can contain an unknown set of nodes that can
> >   be modelled by YANG. A data model for anydata content may or may
> >   not exist at run time.  If the data model for anydata content is
> >   available, then the anydata content MUST be encoded according to
> >   the rules of this specification. If the data model for anydata
> >   content is not available, the encoding MUST follow the rules of
> >   this specification except for rules that require data model
> >   knowledge (and as a consequence, numbers may appear as strings or
> >   namespace qualifiers may not match module names).
> 
> This leaves me wondering what it means for the data model for
> anydata content to be "available".  In the case of ASN.1's
> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> unambiguously identify the grammar (and associated semantics)
> to be used to understand the content, so tools can, if needed,
> scurry off to obtain the parsing instructions for those
> particular bits.  How does an implementation know in the case
> of "anydata" which datamodel to use?

There are situations where we need ANY and not ANY DEFINED BY. Generic
RPCs sometimes work on arbitrary data models. I think ASN.1 allows
ANY as well.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 16 08:18:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20581A905F for ; Wed, 16 Sep 2015 08:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKfDaquXwPrz for ; Wed, 16 Sep 2015 08:18: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 0301A1A903F for ; Wed, 16 Sep 2015 08:18:07 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C237514BD; Wed, 16 Sep 2015 17:18:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gSrsy0n133oo; Wed, 16 Sep 2015 17:18:04 +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, 16 Sep 2015 17:18:04 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFB842004E; Wed, 16 Sep 2015 17:18:03 +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 wA3yCV-zXAnL; Wed, 16 Sep 2015 17:18:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E996820048; Wed, 16 Sep 2015 17:18:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 49B1D372316F; Wed, 16 Sep 2015 17:17:59 +0200 (CEST)
Date: Wed, 16 Sep 2015 17:17:59 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20150916151759.GB76960@elstar.local>
Mail-Followup-To: Andy Bierman , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 15:18:09 -0000

On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
> On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
> randy_presuhn@mindspring.com> wrote:
> 
> > Hi -
> >
> > >From: Juergen Schoenwaelder 
> > >Sent: Sep 14, 2015 11:41 PM
> > >To: Ladislav Lhotka 
> > >Cc: NETMOD Working Group 
> > >Subject: Re: [netmod] Fwd: New Version Notification for
> > draft-ietf-netmod-yang-json-05.txt
> > ...
> > >My question is why the text is silent about the case where the data
> > >model is present. Should it not say that if the data model is present,
> > >the data encoded inside the anydata node must follow the rules of this
> > >document? Perhaps this is the implicit assumption but I think it will
> > >be useful to say this explicitly (if we agree on this).
> > >
> > >If the data model is not present, then I think an implementation is
> > >still expected to produce an encoding that follows the rules of this
> > >document as much as possible except that things that requires data
> > >model knowledge may be encoded differently (e.g., numbers appearing as
> > >strings or namespace names being different). I am thinking along the
> > >lines of this proposed new text:
> > >
> > >   An anydata data node can contain an unknown set of nodes that can
> > >   be modelled by YANG. A data model for anydata content may or may
> > >   not exist at run time.  If the data model for anydata content is
> > >   available, then the anydata content MUST be encoded according to
> > >   the rules of this specification. If the data model for anydata
> > >   content is not available, the encoding MUST follow the rules of
> > >   this specification except for rules that require data model
> > >   knowledge (and as a consequence, numbers may appear as strings or
> > >   namespace qualifiers may not match module names).
> >
> > This leaves me wondering what it means for the data model for
> > anydata content to be "available".  In the case of ASN.1's
> > "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> > unambiguously identify the grammar (and associated semantics)
> > to be used to understand the content, so tools can, if needed,
> > scurry off to obtain the parsing instructions for those
> > particular bits.  How does an implementation know in the case
> > of "anydata" which datamodel to use?
> >
> >
> Good questions....
> The text "If the data model for anydata content is available" gives a hint
> of just
> what a hack anydata is in YANG.  The definition of anydata is that there is
> no data model for the specified subtree.  The mere mention of an out-of-band
> data mode is inappropriate and confusing.
> 
> I understand this is intended to support usage like in YANG Patch, where the
> description-stmt of 'value' says that the child node must follow the schema
> for the node in the target leaf.  More hacks to get YANG to work.

You are welcome to provide fixes.
 
> Once again we confuse conformance to YANG with conformance to
> a module written in YANG.  The YANG Patch text can make additional
> requirements for conformance to YANG Patch.  This is quite different
> than generic conformance to RFC6020bis.

I do not think that we confuse conformance to YANG with conformance to
a module written in YANG.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 16 08:19:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DA01A8A89 for ; Wed, 16 Sep 2015 08:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrC0lco0k_s2 for ; Wed, 16 Sep 2015 08:19:48 -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 593991A90B9 for ; Wed, 16 Sep 2015 08:19:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2427412E0; Wed, 16 Sep 2015 17:19:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IpdaoV7bzeC9; Wed, 16 Sep 2015 17:19:46 +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, 16 Sep 2015 17:19:46 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 516B920054; Wed, 16 Sep 2015 17:19:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id a4QTUZp_zEM9; Wed, 16 Sep 2015 17:19:45 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE4F020048; Wed, 16 Sep 2015 17:19:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 16F4337231A1; Wed, 16 Sep 2015 17:19:42 +0200 (CEST)
Date: Wed, 16 Sep 2015 17:19:42 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150916151942.GC76960@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 15:19:49 -0000

On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
> 
> It can be stated in the description of the anydata statement. One can
> then ask though why we need two constructs - anyxml and anydata -
> because a data model can be specified in the description of an anyxml
> statement as well.
>

The data model used by anydata content is clearly identified. The
difference between anyxml and anydata has been discussed at length and
we should not go there again.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 16 08:26:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34F1A914A for ; Wed, 16 Sep 2015 08:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqYkaDOjZFcD for ; Wed, 16 Sep 2015 08:26:12 -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 83F0A1A910B for ; Wed, 16 Sep 2015 08:26:12 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4EFF8174E; Wed, 16 Sep 2015 17:26:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1diH8Cm7l5oW; Wed, 16 Sep 2015 17:26:09 +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, 16 Sep 2015 17:26:09 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F50F2004E; Wed, 16 Sep 2015 17:26:09 +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 qB79f_dwb0pp; Wed, 16 Sep 2015 17:26:08 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72F2B20048; Wed, 16 Sep 2015 17:26:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CFABD37231CE; Wed, 16 Sep 2015 17:26:04 +0200 (CEST)
Date: Wed, 16 Sep 2015 17:26:04 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150916152604.GD76960@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group 
References: <20150910084021.8677.6592.idtracker@ietfa.amsl.com>  <20150915064147.GB69146@elstar.local> 
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.4.2.3i
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 15:26:14 -0000

On Tue, Sep 15, 2015 at 09:31:58AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Thu, Sep 10, 2015 at 10:46:10AM +0200, Ladislav Lhotka wrote:
> >> Hi,
> >> 
> >> this revision introduces no changes to the encoding rules. The text was modified, and hopefully improved, in quite a few places, mainly due to Juergen’s review of -04, thanks Juergen.
> >>
> >
> > Lada, a suggestion and a question concerning anydata. The text
> > currently says:
> >
> >    Anydata data node is a new feature in YANG 1.1.  It serves as a
> >    container for an unknown set of nodes that however appear as normal
> >    YANG-modeled data.  A data model for anydata content may or may not
> >    exist at run time.  In the latter case, no universal mapping between
> >    JSON- and XML-encoded instances is available.
> >
> > The suggestion is to rewrite the text to be more inline with the YANG
> > 1.1 definition of anydata (and I do not think it matters to highlight
> > that anydata is a YANG 1.1 thing, the document also mentions actions
> > without saying this is a YANG 1.1 feature).
> >
> >    An anydata data node can contain an unknown set of nodes that
> >    can be modelled by YANG. A data model for anydata content may or may not
> >    exist at run time.  In the latter case, no universal mapping between
> >    JSON- and XML-encoded instances is available.
> >
> > My question is why the text is silent about the case where the data
> > model is present. Should it not say that if the data model is present,
> > the data encoded inside the anydata node must follow the rules of this
> > document? Perhaps this is the implicit assumption but I think it will
> > be useful to say this explicitly (if we agree on this).
> 
> If we do agree on this, then IMO 6020bis is the right place to state it
> because this rule should hold for any encoding. 

Perhaps 6020bis should state this but for the sake of completeness I
think it is desirable that encoding specifications are clear about
this as well.

> > If the data model is not present, then I think an implementation is
> > still expected to produce an encoding that follows the rules of this
> > document as much as possible except that things that requires data
> 
> I tried to specify these rules in the four bullets in sec. 5.5. Do you
> think something else is needed?

I think the text in 5.5 allows more than the rest of the YANG encoding
in JSON specification. I think content should carry modules names etc.
and not just be I-JSON with some additional rules. For example, the
bullets do not require me to encode module names. I think this is not
good.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 16 09:00:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ADF1A008F for ; Wed, 16 Sep 2015 09:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bud-MOsmpN8l for ; Wed, 16 Sep 2015 09:00:53 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 BD8301A0060 for ; Wed, 16 Sep 2015 09:00:50 -0700 (PDT)
Received: by lbbmp1 with SMTP id mp1so106332067lbb.1 for ; Wed, 16 Sep 2015 09:00:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=J4cr7wwTyVYT7DHcrM6v4PdFB31vZLRDiGAAgzXnTng=; b=SEG0FFSTzqhiRxsMk5MK6V8ivijsJg5LJtuhWmvXvh0pBsX9ICGOGzPYDkRfAB+7p6 mnq/g0bu2XCs3xyVZmxwG2vrcSit7pRLWWmO7X/fxedt4RV4W7f4kOJ2ON9mkAdObyIc CgBK/NE8NtNJRsHguouYFVR77KJQfL5tbJfqVDojRQFFpNCOLSmelByBDsv1+tqTf2eJ 7piDGTdpm2a1prqTpjIT2QEKKsOgkTO1gEIK5agpYrpvlMDW57G+4td8aZLlWcbTsW76 yypn03yK/jnMgkbN9lBFlbFxlY01hjJ4pVO+2EgSjHqIiRI0YWhlPYcc0bWqD1goqunN aTRw==
X-Gm-Message-State: ALoCoQmZnTokxKF6EWWBVbBYCOhyFy//QEuPluH5C4eiy5USuMa3ujzv84oLl5c/qMr9jgklqQIq
MIME-Version: 1.0
X-Received: by 10.152.21.99 with SMTP id u3mr27990846lae.123.1442419248720; Wed, 16 Sep 2015 09:00:48 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 16 Sep 2015 09:00:48 -0700 (PDT)
In-Reply-To: <20150916151759.GB76960@elstar.local>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>
Date: Wed, 16 Sep 2015 09:00:48 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  Randy Presuhn , NETMOD Working Group 
Content-Type: multipart/alternative; boundary=089e0149397af00c07051fdf66b6
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 16:00:56 -0000

--089e0149397af00c07051fdf66b6
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
> > On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
> > randy_presuhn@mindspring.com> wrote:
> >
> > > Hi -
> > >
> > > >From: Juergen Schoenwaelder 
> > > >Sent: Sep 14, 2015 11:41 PM
> > > >To: Ladislav Lhotka 
> > > >Cc: NETMOD Working Group 
> > > >Subject: Re: [netmod] Fwd: New Version Notification for
> > > draft-ietf-netmod-yang-json-05.txt
> > > ...
> > > >My question is why the text is silent about the case where the data
> > > >model is present. Should it not say that if the data model is present,
> > > >the data encoded inside the anydata node must follow the rules of this
> > > >document? Perhaps this is the implicit assumption but I think it will
> > > >be useful to say this explicitly (if we agree on this).
> > > >
> > > >If the data model is not present, then I think an implementation is
> > > >still expected to produce an encoding that follows the rules of this
> > > >document as much as possible except that things that requires data
> > > >model knowledge may be encoded differently (e.g., numbers appearing as
> > > >strings or namespace names being different). I am thinking along the
> > > >lines of this proposed new text:
> > > >
> > > >   An anydata data node can contain an unknown set of nodes that can
> > > >   be modelled by YANG. A data model for anydata content may or may
> > > >   not exist at run time.  If the data model for anydata content is
> > > >   available, then the anydata content MUST be encoded according to
> > > >   the rules of this specification. If the data model for anydata
> > > >   content is not available, the encoding MUST follow the rules of
> > > >   this specification except for rules that require data model
> > > >   knowledge (and as a consequence, numbers may appear as strings or
> > > >   namespace qualifiers may not match module names).
> > >
> > > This leaves me wondering what it means for the data model for
> > > anydata content to be "available".  In the case of ASN.1's
> > > "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> > > unambiguously identify the grammar (and associated semantics)
> > > to be used to understand the content, so tools can, if needed,
> > > scurry off to obtain the parsing instructions for those
> > > particular bits.  How does an implementation know in the case
> > > of "anydata" which datamodel to use?
> > >
> > >
> > Good questions....
> > The text "If the data model for anydata content is available" gives a
> hint
> > of just
> > what a hack anydata is in YANG.  The definition of anydata is that there
> is
> > no data model for the specified subtree.  The mere mention of an
> out-of-band
> > data mode is inappropriate and confusing.
> >
> > I understand this is intended to support usage like in YANG Patch, where
> the
> > description-stmt of 'value' says that the child node must follow the
> schema
> > for the node in the target leaf.  More hacks to get YANG to work.
>
> You are welcome to provide fixes.
>


OLD:


  An anydata data node can contain an unknown set of nodes that can
  be modelled by YANG. A data model for anydata content may or may
   not exist at run time.  If the data model for anydata content is
   available, then the anydata content MUST be encoded according to
  the rules of this specification. If the data model for anydata
  content is not available, the encoding MUST follow the rules of
  this specification except for rules that require data model
   knowledge (and as a consequence, numbers may appear as strings or
  namespace qualifiers may not match module names).


NEW:

  An anydata data node can contain an unknown set of nodes that can
  be modelled by YANG.

 The YANG RFC itself should be silent about data-model specific
semantics that are added to an anydata subtree.  The text "if available"
is especially non-enforceable and therefore pointless.



> > Once again we confuse conformance to YANG with conformance to
> > a module written in YANG.  The YANG Patch text can make additional
> > requirements for conformance to YANG Patch.  This is quite different
> > than generic conformance to RFC6020bis.
>
> I do not think that we confuse conformance to YANG with conformance to
> a module written in YANG.
>
> /js
>
>
Andy



> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:

> On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <

> randy_presuhn@mindspri=
ng.com> wrote:

>

> > Hi -

> >

> > >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

> > >Sent: Sep 14, 2015 11:41 PM

> > >To: Ladislav Lhotka <lhot=
ka@nic.cz>

> > >Cc: NETMOD Working Group <netmod@ietf.org>

> > >Subject: Re: [netmod] Fwd: New Version Notification for

> > draft-ietf-netmod-yang-json-05.txt

> > ...

> > >My question is why the text is silent about the case where th=
e data

> > >model is present. Should it not say that if the data model is=
 present,

> > >the data encoded inside the anydata node must follow the rule=
s of this

> > >document? Perhaps this is the implicit assumption but I think=
 it will

> > >be useful to say this explicitly (if we agree on this).

> > >

> > >If the data model is not present, then I think an implementat=
ion is

> > >still expected to produce an encoding that follows the rules =
of this

> > >document as much as possible except that things that requires=
 data

> > >model knowledge may be encoded differently (e.g., numbers app=
earing as

> > >strings or namespace names being different). I am thinking al=
ong the

> > >lines of this proposed new text:

> > >

> > >=C2=A0 =C2=A0An anydata data node can contain an unknown set =
of nodes that can

> > >=C2=A0 =C2=A0be modelled by YANG. A data model for anydata co=
ntent may or may

> > >=C2=A0 =C2=A0not exist at run time.=C2=A0 If the data model f=
or anydata content is

> > >=C2=A0 =C2=A0available, then the anydata content MUST be enco=
ded according to

> > >=C2=A0 =C2=A0the rules of this specification. If the data mod=
el for anydata

> > >=C2=A0 =C2=A0content is not available, the encoding MUST foll=
ow the rules of

> > >=C2=A0 =C2=A0this specification except for rules that require=
 data model

> > >=C2=A0 =C2=A0knowledge (and as a consequence, numbers may app=
ear as strings or

> > >=C2=A0 =C2=A0namespace qualifiers may not match module names)=
.

> >

> > This leaves me wondering what it means for the data model for

> > anydata content to be "available".=C2=A0 In the case of=
 ASN.1's

> > "ANY DEFINED BY" construct, there's an OBJECT IDENT=
IFIER to

> > unambiguously identify the grammar (and associated semantics)

> > to be used to understand the content, so tools can, if needed,
> > scurry off to obtain the parsing instructions for those

> > particular bits.=C2=A0 How does an implementation know in the cas=
e

> > of "anydata" which datamodel to use?

> >

> >

> Good questions....

> The text "If the data model for anydata content is available"=
; gives a hint

> of just

> what a hack anydata is in YANG.=C2=A0 The definition of anydata is tha=
t there is

> no data model for the specified subtree.=C2=A0 The mere mention of an =
out-of-band

> data mode is inappropriate and confusing.

>

> I understand this is intended to support usage like in YANG Patch, whe=
re the

> description-stmt of 'value' says that the child node must foll=
ow the schema

> for the node in the target leaf.=C2=A0 More hacks to get YANG to work.=




You are welcome to provide fixes.


<=
/div>
OLD:


=C2=A0 An anydata data node can=
 contain an unknown set of nodes that can
=C2=A0 be modelled by YANG. A =
data model for anydata content may or may
=C2=A0 =C2=A0not exist at run =
time.=C2=A0 If the data model for anydata content is
=C2=A0 =C2=A0availa=
ble, then the anydata content MUST be encoded according to
=C2=A0 the ru=
les of this specification. If the data model for anydata
=C2=A0 content =
is not available, the encoding MUST follow the rules of
=C2=A0 this spec=
ification except for rules that require data model
=C2=A0 =C2=A0knowledg=
e (and as a consequence, numbers may appear as strings or
=C2=A0 namespa=
ce qualifiers may not match module names).


NEW:

=C2=A0 An anydata data node can conta=
in an unknown set of nodes that can
=C2=A0 be modelled by YANG.=C2=A0
=C2=A0The YANG RFC itself should be silent about data-model=
 specific
semantics that are added to an anydata subtree.=C2=A0 T=
he text "if available"
is especially non-enforceable an=
d therefore pointless.





> Once again we confuse conformance to YANG with conformance to

> a module written in YANG.=C2=A0 The YANG Patch text can make additiona=
l

> requirements for conformance to YANG Patch.=C2=A0 This is quite differ=
ent

> than generic conformance to RFC6020bis.



I do not think that we confuse conformance to YANG with conformance to

a module written in YANG.



/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/>





--089e0149397af00c07051fdf66b6--


From nobody Wed Sep 16 10:50:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124821B40DB for ; Wed, 16 Sep 2015 10:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Tu0t7SdJu8 for ; Wed, 16 Sep 2015 10:50:16 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0007E1B40D7 for ; Wed, 16 Sep 2015 10:50:15 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 53E9F1807D2; Wed, 16 Sep 2015 19:50:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442425814; bh=lwCbkz2mEsv+D3C6lwhkBBEZkqyrie8+r9R3+pDQ86w=; h=From:Date:To; b=w9BCcsuAb4b87jU/c2stugjxyY9naNuy/nYcLuKocFr5ldF33Q4dt7IxeUVpqPtuA hPg9yRDCr1lQihcUlwKO3f96VphKz1mkWqxb7SjFbN3Qr3BmfVONK7+e1h6YSGl65j DAfmQPiwPQfDjz7Vym0POeBQsx6m4j+DWhhVTZ4Q=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150916151942.GC76960@elstar.local>
Date: Wed, 16 Sep 2015 19:50:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 17:50:18 -0000

> On 16 Sep 2015, at 17:19, Juergen Schoenwaelder =
 wrote:
>=20
> On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
>>=20
>> It can be stated in the description of the anydata statement. One can
>> then ask though why we need two constructs - anyxml and anydata -
>> because a data model can be specified in the description of an anyxml
>> statement as well.
>>=20
>=20
> The data model used by anydata content is clearly identified. The

Hmm, how is it clearly identified? There needn=E2=80=99t be any data =
model at all.

> difference between anyxml and anydata has been discussed at length and
> we should not go there again.

Then the 6020bis doesn=E2=80=99t make this difference clear, to me at =
least.

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 16 10:55:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BDA1ACF19 for ; Wed, 16 Sep 2015 10:55:54 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj3XIXM9xCPx for ; Wed, 16 Sep 2015 10:55:52 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 871AF1A888B for ; Wed, 16 Sep 2015 10:55:52 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tneP0mNlUIUgd+8X21m+xtOdMMRHJ/lHBRsrQwUG6TjDYc+Fo11lK/W+Cobe2XqT; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZcGvm-0003cF-Av for netmod@ietf.org; Wed, 16 Sep 2015 13:55:42 -0400
Received: from 76.254.49.226 by webmail.earthlink.net with HTTP; Wed, 16 Sep 2015 13:55:41 -0400
Message-ID: <21153243.1442426142133.JavaMail.root@mswamui-backed.atl.sa.earthlink.net>
Date: Wed, 16 Sep 2015 10:55:41 -0700 (GMT-07:00)
From: Randy Presuhn 
To: NETMOD Working Group 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3eddb7925720ec8fab9f9df73e5dbc3fa8f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.25
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 17:55:54 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Sep 15, 2015 11:03 PM
>To: Randy Presuhn , NETMOD Working Group 
>Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
...
>> This leaves me wondering what it means for the data model for
>> anydata content to be "available".  In the case of ASN.1's
>> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
>> unambiguously identify the grammar (and associated semantics)
>> to be used to understand the content, so tools can, if needed,
>> scurry off to obtain the parsing instructions for those
>> particular bits.  How does an implementation know in the case
>> of "anydata" which datamodel to use?
>
>It can be stated in the description of the anydata statement. One can
>then ask though why we need two constructs - anyxml and anydata -
>because a data model can be specified in the description of an anyxml
>statement as well.

How does a client (or a server, for that matter) extract that
information from the description of the anydata statement?

Randy


From nobody Wed Sep 16 11:25:32 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71F41A884D for ; Wed, 16 Sep 2015 11:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20-BVajVEvkU for ; Wed, 16 Sep 2015 11:25:28 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 B3D281A8837 for ; Wed, 16 Sep 2015 11:25:27 -0700 (PDT)
Received: by lbcao8 with SMTP id ao8so108464033lbc.3 for ; Wed, 16 Sep 2015 11:25:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IyXriOWjVEODfPMIucLqachkBy0T3idwpZ348Pr0Xf8=; b=AMEf6KDtQcF7v3vuZtJrY5E5Hgn9MyOnndnEdpTS/80dHylGnHhPZ8Fviw6dwo+9dm rwT+Lm1wdmSXGfdfmQ+OSW3Mws5CLSBFvnWhykxUOnTI1pdNd/9BGRmbSKTO1epn4y7o 6ZtVVzSR/fHYNEOo0HmKZkVXgdI7BPXgMr6+FHBLG7VZwRhZPSYg+6ZoLk78We35KA1G jXteUS6p4G8T/Zdze2UyFTGdQNfMI5u5zDKe3+wx1moSfqKfbXWswrT32QecCu+Ux3lM HIqHL16GHYFlOiWeAx+rHsxU7l/OMNeeHnNxNy8NMiFHjdWbAHtrQ48isf9meLWqyWIi g2Tg==
X-Gm-Message-State: ALoCoQm6opH4lTfix/3xJAmVNGYm/5wAkRZzMM4A/F8bEX8adg1wwoB3Dry7nXCOQIn7ZUfIaWE3
MIME-Version: 1.0
X-Received: by 10.152.6.230 with SMTP id e6mr11056719laa.82.1442427925913; Wed, 16 Sep 2015 11:25:25 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 16 Sep 2015 11:25:25 -0700 (PDT)
In-Reply-To: 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local> 
Date: Wed, 16 Sep 2015 11:25:25 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e013d170e237c51051fe16cc1
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 18:25:30 -0000

--089e013d170e237c51051fe16cc1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka  wrote:

>
> > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >
> > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
> >>
> >> It can be stated in the description of the anydata statement. One can
> >> then ask though why we need two constructs - anyxml and anydata -
> >> because a data model can be specified in the description of an anyxml
> >> statement as well.
> >>
> >
> > The data model used by anydata content is clearly identified. The
>
> Hmm, how is it clearly identified? There needn=E2=80=99t be any data mode=
l at all.
>
> > difference between anyxml and anydata has been discussed at length and
> > we should not go there again.
>
> Then the 6020bis doesn=E2=80=99t make this difference clear, to me at lea=
st.
>
>
This is an academic exercise, but the difference is very clear.

The "anyxml" node allows XML-specific details like processing instructions.
It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
This is academic, because the vast majority of servers do not support anyxm=
l
at all.  None. Zero.  Not allowed in the server.  The few that do treat
anyxml
as if it were anydata.

The "anydata" node is a blob of YANG data nodes.  It is not XML.
It is not JSON. This too will likely not be implemented in the vast majorit=
y
of servers.


Lada
>
>


> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka <=
;lhotka@nic.cz> wrote:


> On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<=
/a>> wrote:

>

> On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:

>>

>> It can be stated in the description of the anydata statement. One =
can

>> then ask though why we need two constructs - anyxml and anydata -<=
br>
>> because a data model can be specified in the description of an any=
xml

>> statement as well.

>>

>

> The data model used by anydata content is clearly identified. The



Hmm, how is it clearly identified? There needn=E2=80=99t be any data model =
at all.



> difference between anyxml and anydata has been discussed at length and=


> we should not go there again.



Then the 6020bis doesn=E2=80=99t make this difference clear, to me at least=
.








--089e013d170e237c51051fe16cc1--


From nobody Wed Sep 16 11:29:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA491A886E for ; Wed, 16 Sep 2015 11:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox4PTfOomZvs for ; Wed, 16 Sep 2015 11:29:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EC21A882F for ; Wed, 16 Sep 2015 11:29:08 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id E67A318170D; Wed, 16 Sep 2015 20:29:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442428147; bh=RC0DhJDzh9KvBPXBPxG2RZv4FJv3z08OTKKRdzh5oDw=; h=From:Date:To; b=JbIwQx4SZQaCTaalTA77i16zT7RCNtj7ajmN6fEYnpO3mgtIVbWifLa4UQHkmu6/k zqOqRpa58DlCX8E2ZweGLkvILndR11SCYtw4BnegS7GOGRAkEIraMBGJ9mHOoZjmXc XiJnrA7hrFHiG1XpYGM+qX2VLGlACbwRDyj6y4Dk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 16 Sep 2015 20:29:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 18:29:10 -0000

> On 16 Sep 2015, at 18:00, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder =
 wrote:
> On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
> > On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
> > randy_presuhn@mindspring.com> wrote:
> >
> > > Hi -
> > >
> > > >From: Juergen Schoenwaelder =

> > > >Sent: Sep 14, 2015 11:41 PM
> > > >To: Ladislav Lhotka 
> > > >Cc: NETMOD Working Group 
> > > >Subject: Re: [netmod] Fwd: New Version Notification for
> > > draft-ietf-netmod-yang-json-05.txt
> > > ...
> > > >My question is why the text is silent about the case where the =
data
> > > >model is present. Should it not say that if the data model is =
present,
> > > >the data encoded inside the anydata node must follow the rules of =
this
> > > >document? Perhaps this is the implicit assumption but I think it =
will
> > > >be useful to say this explicitly (if we agree on this).
> > > >
> > > >If the data model is not present, then I think an implementation =
is
> > > >still expected to produce an encoding that follows the rules of =
this
> > > >document as much as possible except that things that requires =
data
> > > >model knowledge may be encoded differently (e.g., numbers =
appearing as
> > > >strings or namespace names being different). I am thinking along =
the
> > > >lines of this proposed new text:
> > > >
> > > >   An anydata data node can contain an unknown set of nodes that =
can
> > > >   be modelled by YANG. A data model for anydata content may or =
may
> > > >   not exist at run time.  If the data model for anydata content =
is
> > > >   available, then the anydata content MUST be encoded according =
to
> > > >   the rules of this specification. If the data model for anydata
> > > >   content is not available, the encoding MUST follow the rules =
of
> > > >   this specification except for rules that require data model
> > > >   knowledge (and as a consequence, numbers may appear as strings =
or
> > > >   namespace qualifiers may not match module names).
> > >
> > > This leaves me wondering what it means for the data model for
> > > anydata content to be "available".  In the case of ASN.1's
> > > "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> > > unambiguously identify the grammar (and associated semantics)
> > > to be used to understand the content, so tools can, if needed,
> > > scurry off to obtain the parsing instructions for those
> > > particular bits.  How does an implementation know in the case
> > > of "anydata" which datamodel to use?
> > >
> > >
> > Good questions....
> > The text "If the data model for anydata content is available" gives =
a hint
> > of just
> > what a hack anydata is in YANG.  The definition of anydata is that =
there is
> > no data model for the specified subtree.  The mere mention of an =
out-of-band
> > data mode is inappropriate and confusing.
> >
> > I understand this is intended to support usage like in YANG Patch, =
where the
> > description-stmt of 'value' says that the child node must follow the =
schema
> > for the node in the target leaf.  More hacks to get YANG to work.
>=20
> You are welcome to provide fixes.
>=20
>=20
> OLD:
>=20
>=20
>   An anydata data node can contain an unknown set of nodes that can
>   be modelled by YANG. A data model for anydata content may or may
>    not exist at run time.  If the data model for anydata content is
>    available, then the anydata content MUST be encoded according to
>   the rules of this specification. If the data model for anydata
>   content is not available, the encoding MUST follow the rules of
>   this specification except for rules that require data model
>    knowledge (and as a consequence, numbers may appear as strings or
>   namespace qualifiers may not match module names).
>=20
>=20
> NEW:
>=20
>   An anydata data node can contain an unknown set of nodes that can
>   be modelled by YANG.

This text is essentially in 6020bis, I see no need to repeat it.=20

> =20
>=20
>  The YANG RFC itself should be silent about data-model specific
> semantics that are added to an anydata subtree.  The text "if =
available"
> is especially non-enforceable and therefore pointless.
>=20

I must admit I am getting lost in these discussions. It seems to me =
there is a lot of hand-waving and hidden assumptions that moreover =
differ from one person to another. As I already said in Prague, both =
anyxml and anydata are IMO constructs of marginal utility and it is =
frustrating we spend so much effort on them.

Lada

>=20
>=20
> > Once again we confuse conformance to YANG with conformance to
> > a module written in YANG.  The YANG Patch text can make additional
> > requirements for conformance to YANG Patch.  This is quite different
> > than generic conformance to RFC6020bis.
>=20
> I do not think that we confuse conformance to YANG with conformance to
> a module written in YANG.
>=20
> /js
>=20
>=20
> Andy
>=20
> =20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 16 11:38:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C151A8884 for ; Wed, 16 Sep 2015 11:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL65q0FBsFM7 for ; Wed, 16 Sep 2015 11:38:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221691A0029 for ; Wed, 16 Sep 2015 11:38:18 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id CFD1018170A; Wed, 16 Sep 2015 20:38:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442428696; bh=KM/lPjsCmLcUYIFJ5brOoDgKvt8c2O/fy44vSfbNKow=; h=From:Date:To; b=WhCil7DkZUz4tnmyqLeBaoJE4kgudzif6BinIkpmtk9aTpaPVri2O8FmmpodpHnhy i79WVxP3b4EFhfqvYrMYFOTtNWAmtnPRfoFePE9TEjxphPeCS7CSmnDn4nlRGlaDF1 x7K7HbibbM1OjxBRsrt9d6SKipd5xGTEJ2WDKFo4=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <21153243.1442426142133.JavaMail.root@mswamui-backed.atl.sa.earthlink.net>
Date: Wed, 16 Sep 2015 20:38:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6625FA6C-11CF-498D-8967-4AF3A9102468@nic.cz>
References: <21153243.1442426142133.JavaMail.root@mswamui-backed.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 18:38:19 -0000

> On 16 Sep 2015, at 19:55, Randy Presuhn  =
wrote:
>=20
> Hi -
>=20
>> From: Ladislav Lhotka 
>> Sent: Sep 15, 2015 11:03 PM
>> To: Randy Presuhn , NETMOD Working =
Group 
>> Subject: Re: [netmod] Fwd: New Version Notification for =
draft-ietf-netmod-yang-json-05.txt
> ...
>>> This leaves me wondering what it means for the data model for
>>> anydata content to be "available".  In the case of ASN.1's
>>> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
>>> unambiguously identify the grammar (and associated semantics)
>>> to be used to understand the content, so tools can, if needed,
>>> scurry off to obtain the parsing instructions for those
>>> particular bits.  How does an implementation know in the case
>>> of "anydata" which datamodel to use?
>>=20
>> It can be stated in the description of the anydata statement. One can
>> then ask though why we need two constructs - anyxml and anydata -
>> because a data model can be specified in the description of an anyxml
>> statement as well.
>=20
> How does a client (or a server, for that matter) extract that
> information from the description of the anydata statement?

They don=E2=80=99t, unless they are terribly sophisticated. It=E2=80=99s =
up to a human implementer to parse the description text and write a =
corresponding code. No automation at all.

In fact, the main use case for anydata/anyxml so far has been in =
standards where YANG played the role of a schema language.

Lada  =20

>=20
> Randy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 16 11:55:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018161A8AD3 for ; Wed, 16 Sep 2015 11:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAW61DtwYD2N for ; Wed, 16 Sep 2015 11:55:35 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E821A8F4A for ; Wed, 16 Sep 2015 11:55:34 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:e135:8579:2808:67ac] (unknown [IPv6:2a01:5e0:29:ffff:e135:8579:2808:67ac]) by mail.nic.cz (Postfix) with ESMTPSA id 781FF18140C; Wed, 16 Sep 2015 20:55:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442429732; bh=ZMn8EPdsXiDWMc6UXLxiLaOxe1zQ/x3mZkgLwOfnTl0=; h=From:Date:To; b=FpR4m5s7cN7d0ekXiJ6f/FN967hlmmIF8QsVTs6NjSW5ZxaHM1glXbOVITycN8TjQ Fx4bBtUBfhTaKsnkrN3cJy1H8E2YUGX//FymWCxMoSk8a7aQB4s1oOCED0so1gSaJj fi4w6K5bzrkfMzKVKy0CGFJfrTXce/zmvcvGh904=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 16 Sep 2015 20:55:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 18:55:37 -0000

> On 16 Sep 2015, at 20:25, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder =
 wrote:
> >
> > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
> >>
> >> It can be stated in the description of the anydata statement. One =
can
> >> then ask though why we need two constructs - anyxml and anydata -
> >> because a data model can be specified in the description of an =
anyxml
> >> statement as well.
> >>
> >
> > The data model used by anydata content is clearly identified. The
>=20
> Hmm, how is it clearly identified? There needn=E2=80=99t be any data =
model at all.
>=20
> > difference between anyxml and anydata has been discussed at length =
and
> > we should not go there again.
>=20
> Then the 6020bis doesn=E2=80=99t make this difference clear, to me at =
least.
>=20
>=20
> This is an academic exercise, but the difference is very clear.
>=20
> The "anyxml" node allows XML-specific details like processing =
instructions.
> It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> This is academic, because the vast majority of servers do not support =
anyxml
> at all.  None. Zero.  Not allowed in the server.  The few that do =
treat anyxml
> as if it were anydata.
>=20
> The "anydata" node is a blob of YANG data nodes.  It is not XML.
> It is not JSON. This too will likely not be implemented in the vast =
majority
> of servers.

This is illusory unless a YANG data model is available, and, as you =
said, this is not guaranteed. For one, without a data model there is no =
way for mapping XML encoding to JSON and vice versa, so anydata received =
in one encoding cannot be sent back to clients supporting the other =
encoding.

Lada

> =20
>=20
>=20
> Lada
>=20
>=20
> =20
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
> > Fax:   +49 421 200 3103         
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 16 12:02:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256BE1A905A for ; Wed, 16 Sep 2015 12:02:42 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR7v7bkfrP2e for ; Wed, 16 Sep 2015 12:02:40 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7A1A9055 for ; Wed, 16 Sep 2015 12:01:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dszJI6hwvWTjbBeWVN6mVJn/H2jonF/MVRCyojjALJY3R4iA9qvNwgcE/HLeZ/Y4; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZcHxi-0000QS-S9 for netmod@ietf.org; Wed, 16 Sep 2015 15:01:46 -0400
Received: from 76.254.49.226 by webmail.earthlink.net with HTTP; Wed, 16 Sep 2015 15:01:21 -0400
Message-ID: <26333544.1442430081671.JavaMail.root@mswamui-backed.atl.sa.earthlink.net>
Date: Wed, 16 Sep 2015 12:01:21 -0700 (GMT-07:00)
From: Randy Presuhn 
To: NETMOD Working Group 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ede7fb20a2f92566f8035305468f791af2350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.25
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 19:02:42 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Sep 16, 2015 8:14 AM
>To: Randy Presuhn 
>Cc: NETMOD Working Group 
>Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
... 
>> This leaves me wondering what it means for the data model for
>> anydata content to be "available".  In the case of ASN.1's
>> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
>> unambiguously identify the grammar (and associated semantics)
>> to be used to understand the content, so tools can, if needed,
>> scurry off to obtain the parsing instructions for those
>> particular bits.  How does an implementation know in the case
>> of "anydata" which datamodel to use?
>
>There are situations where we need ANY and not ANY DEFINED BY. Generic
>RPCs sometimes work on arbitrary data models. I think ASN.1 allows
>ANY as well.

The "naked ANY" construct was removed from ASN.1 in the last
decade of the previous century.  It caused too many problems
for parsers, especially for some non-BER transfer syntaxes.
(Akin to some of the JSON challenges we've seen here.)  The
ASN.1 world has been chugging happily along without it, AFAICT.

The "ANY DEFINED BY" construct was replaced by the "object
class field type".  See ISO/IEC 8824-1:2003 section 3.6.51
(especially the three notes) and ISO/IEC 8824-2:2003 section 14.
Although the bits on the wire remain the same, the notation is
quite different.

Randy


From nobody Wed Sep 16 12:29:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905751A0130 for ; Wed, 16 Sep 2015 12:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63kZXMjD7aID for ; Wed, 16 Sep 2015 12:29:20 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 D53B41A0126 for ; Wed, 16 Sep 2015 12:29:19 -0700 (PDT)
Received: by lbbmp1 with SMTP id mp1so109532097lbb.1 for ; Wed, 16 Sep 2015 12:29:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sWkdnRKLqeMrjJMRxIRZH6TdBvnreCuGZzb+5RghvNU=; b=e3LFv1SwaQuiXXhADWt6GfSAvtAN3Br/ya86cvHmRn5ocsrnh7ct1ojhL9p4MIeBZs jViQwTOq6Ri9X9sR9xQp/IyQBcho+E4ZZQhsNnX8Wh7R35YlAPRf4LFFMUWiT/4C5jqU 2VhBIb5gWgYTHqKhelUSdIqzjbqBjfUeUwJJbTTrgrTcQfh67FYgLrnY4TJyEVXQmTIo vl2l7f4TQnTTqjJqb6FUKirV3bxDTHLqCwN+sw4wHwTPRi0M88pPf/qFGbPNIHW36QU3 EHLL+XdbvRKZqshwjScstoveK30v9Do5V6KRQxPYD59LM/UKkHfUkfPe3JPegYoAtWPS qKig==
X-Gm-Message-State: ALoCoQnXPA7P85+G1CbLeYqfPhQPjvfcyMdhd/VAxrCinyMrUbixfyoMuFK/lladvBUKesLKqiEf
MIME-Version: 1.0
X-Received: by 10.112.156.167 with SMTP id wf7mr31656077lbb.88.1442431758043;  Wed, 16 Sep 2015 12:29:18 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 16 Sep 2015 12:29:17 -0700 (PDT)
In-Reply-To: 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>   
Date: Wed, 16 Sep 2015 12:29:17 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c27b268d1706051fe250e5
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 19:29:22 -0000

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

On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka  wrote:

>
> > On 16 Sep 2015, at 20:25, Andy Bierman  wrote:
> >
> >
> >
> > On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka  wrote=
:
> >
> > > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
> > >>
> > >> It can be stated in the description of the anydata statement. One ca=
n
> > >> then ask though why we need two constructs - anyxml and anydata -
> > >> because a data model can be specified in the description of an anyxm=
l
> > >> statement as well.
> > >>
> > >
> > > The data model used by anydata content is clearly identified. The
> >
> > Hmm, how is it clearly identified? There needn=E2=80=99t be any data mo=
del at
> all.
> >
> > > difference between anyxml and anydata has been discussed at length an=
d
> > > we should not go there again.
> >
> > Then the 6020bis doesn=E2=80=99t make this difference clear, to me at l=
east.
> >
> >
> > This is an academic exercise, but the difference is very clear.
> >
> > The "anyxml" node allows XML-specific details like processing
> instructions.
> > It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> > This is academic, because the vast majority of servers do not support
> anyxml
> > at all.  None. Zero.  Not allowed in the server.  The few that do treat
> anyxml
> > as if it were anydata.
> >
> > The "anydata" node is a blob of YANG data nodes.  It is not XML.
> > It is not JSON. This too will likely not be implemented in the vast
> majority
> > of servers.
>
> This is illusory unless a YANG data model is available, and, as you said,
> this is not guaranteed. For one, without a data model there is no way for
> mapping XML encoding to JSON and vice versa, so anydata received in one
> encoding cannot be sent back to clients supporting the other encoding.
>
>

I don't like the idea of adding a requirement that the "hidden schema" be
used
so that JSON people will be happy to get a number instead of a string, as i=
f
that is actually a data model.

Unless there is a hidden schema, then it just doesn't matter if the client
passed in a JSON number and another client reads back an XML string.
There is no data model at all.  There is not even any schema that
says 'foo' can have any child nodes or not, let alone the required
QName and syntax for that child node.

Users that want any sort of schema-based interoperability should not
use anydata instead of real data nodes.




> Lada
>

Andy


>
> >
> >
> >
> > Lada
> >
> >
> >
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | German=
y
> > > Fax:   +49 421 200 3103         
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka <=
;lhotka@nic.cz> wrote:


> On 16 Sep 2015, at 20:25, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit=
y.de> wrote:

> >

> > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:<=
br>
> >>

> >> It can be stated in the description of the anydata statement.=
 One can

> >> then ask though why we need two constructs - anyxml and anyda=
ta -

> >> because a data model can be specified in the description of a=
n anyxml

> >> statement as well.

> >>

> >

> > The data model used by anydata content is clearly identified. The=


>

> Hmm, how is it clearly identified? There needn=E2=80=99t be any data m=
odel at all.

>

> > difference between anyxml and anydata has been discussed at lengt=
h and

> > we should not go there again.

>

> Then the 6020bis doesn=E2=80=99t make this difference clear, to me at =
least.

>

>

> This is an academic exercise, but the difference is very clear.

>

> The "anyxml" node allows XML-specific details like processin=
g instructions.

> It is a blob of XML.=C2=A0 It is not JSON.=C2=A0 It is not YANG.=C2=A0=
 It is XML.

> This is academic, because the vast majority of servers do not support =
anyxml

> at all.=C2=A0 None. Zero.=C2=A0 Not allowed in the server.=C2=A0 The f=
ew that do treat anyxml

> as if it were anydata.

>

> The "anydata" node is a blob of YANG data nodes.=C2=A0 It is=
 not XML.

> It is not JSON. This too will likely not be implemented in the vast ma=
jority

> of servers.



This is illusory unless a YANG data model is available, and, as you said, t=
his is not guaranteed. For one, without a data model there is no way for ma=
pping XML encoding to JSON and vice versa, so anydata received in one encod=
ing cannot be sent back to clients supporting the other encoding.




I don't like the id=
ea of adding a requirement that the "hidden schema" be used
=

so that JSON people will be happy to get a number instead of a string,=
 as if
that is actually a data model.

Un=
less there is a hidden schema, then it just doesn't matter if the clien=
t
passed in a JSON number and another client reads back an XML st=
ring.
There is no data model at all.=C2=A0 There is not even any =
schema that
says 'foo' can have any child nodes or not, l=
et alone the required
QName and syntax for that child node.
=


Users that want any sort of schema-based interoperabili=
ty should not
use anydata instead of real data nodes.
<=
br>

=C2=A0

Lada

Andy
=C2=A0



>

>

>

> Lada

>

>

>

> >

> > /js

> >

> > --

> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac=
obs University Bremen gGmbH

> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R=
ing 1 | 28759 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/>

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a11c27b268d1706051fe250e5--


From nobody Wed Sep 16 13:11:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEEE1A07BC for ; Wed, 16 Sep 2015 13:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k3veFMnngWN for ; Wed, 16 Sep 2015 13:11:20 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0E41A046D for ; Wed, 16 Sep 2015 13:11:19 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 13643180C53; Wed, 16 Sep 2015 22:11:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442434277; bh=OJO3NKc4SxGrjSHiG9EEX0VT4VuG5YWEFdCWdeBeED0=; h=From:Date:To; b=X3wT0BeWaWuSrPJeZ/2QeW1zWIPWI2lcITV5XWQpnQ/0R4Fthx42Y7l62P1Wi2sEy RqGjMkiNIF/Qh8eqVLYO/vrJY2xDhLgV8dWnclEHl/Hvn82gQvZ2tZ5bAmdapJIloA 3Yl57ACB14TK6g68/a4UlQzC5eSFee0M9CVDEMVc=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 16 Sep 2015 22:11:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <12FD6338-67B0-4549-9D66-2C69FF0D739F@nic.cz>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>    
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 20:11:22 -0000

> On 16 Sep 2015, at 21:29, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 16 Sep 2015, at 20:25, Andy Bierman  wrote:
> >
> >
> >
> > On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka  =
wrote:
> >
> > > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder =
 wrote:
> > >
> > > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
> > >>
> > >> It can be stated in the description of the anydata statement. One =
can
> > >> then ask though why we need two constructs - anyxml and anydata -
> > >> because a data model can be specified in the description of an =
anyxml
> > >> statement as well.
> > >>
> > >
> > > The data model used by anydata content is clearly identified. The
> >
> > Hmm, how is it clearly identified? There needn=E2=80=99t be any data =
model at all.
> >
> > > difference between anyxml and anydata has been discussed at length =
and
> > > we should not go there again.
> >
> > Then the 6020bis doesn=E2=80=99t make this difference clear, to me =
at least.
> >
> >
> > This is an academic exercise, but the difference is very clear.
> >
> > The "anyxml" node allows XML-specific details like processing =
instructions.
> > It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> > This is academic, because the vast majority of servers do not =
support anyxml
> > at all.  None. Zero.  Not allowed in the server.  The few that do =
treat anyxml
> > as if it were anydata.
> >
> > The "anydata" node is a blob of YANG data nodes.  It is not XML.
> > It is not JSON. This too will likely not be implemented in the vast =
majority
> > of servers.
>=20
> This is illusory unless a YANG data model is available, and, as you =
said, this is not guaranteed. For one, without a data model there is no =
way for mapping XML encoding to JSON and vice versa, so anydata received =
in one encoding cannot be sent back to clients supporting the other =
encoding.
>=20
>=20
>=20
> I don't like the idea of adding a requirement that the "hidden schema" =
be used
> so that JSON people will be happy to get a number instead of a string, =
as if
> that is actually a data model.

Without a data model we also cannot map module names to XML namespaces.

Lada =20

>=20
> Unless there is a hidden schema, then it just doesn't matter if the =
client
> passed in a JSON number and another client reads back an XML string.
> There is no data model at all.  There is not even any schema that
> says 'foo' can have any child nodes or not, let alone the required
> QName and syntax for that child node.
>=20
> Users that want any sort of schema-based interoperability should not
> use anydata instead of real data nodes.
>=20
>=20
> =20
> Lada
>=20
> Andy
> =20
>=20
> >
> >
> >
> > Lada
> >
> >
> >
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
> > > Fax:   +49 421 200 3103         
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 16 13:52:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7C31A1A99 for ; Wed, 16 Sep 2015 13:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvYbvV0OKJmr for ; Wed, 16 Sep 2015 13:51:56 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 C746E1A1A87 for ; Wed, 16 Sep 2015 13:51:55 -0700 (PDT)
Received: by lbbvu2 with SMTP id vu2so38456309lbb.0 for ; Wed, 16 Sep 2015 13:51:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xE4RlkxK3hGKGJ6tu0/u23Q0tibudGkytpzZUCicvvY=; b=KXkUSsyyOr4fSCqeP3SnlRd/dSnNYpBPvlRXkElGpWRoy/xH39yb/gVWrfPRgbEirE srT01THcv8sX1RZG7Hvdqe7IhUoMkVbaO/Vhesgju/kkXMv6PGkDTw3xf8y/vr8bV4zi OR7hp4dK8zLyaM1C0/J52xzntxxgr4cfjIyFoYkQmaxk6lQRylt7icSQCFutxKn333a7 8w6Z8ztfayClqtGvFnHca/wIG/y1shOf3y4sAzL3KJSClFSaZnVVWgO/2bVuguJM6FI1 gIrIvdn6IY6Y0AEc+0Ym2JgmJSQeHkiwNqu6+lWKB0psAV/iEJC+Ye18CQwntmx4cbik HJig==
X-Gm-Message-State: ALoCoQmpP971lVzuf2qqLNdNyDtR0gnXfdaxJZAR96Qqlm60Op5OfawHOiPfhYewb2Qda+pzNOx0
MIME-Version: 1.0
X-Received: by 10.152.6.230 with SMTP id e6mr11708068laa.82.1442436713929; Wed, 16 Sep 2015 13:51:53 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Wed, 16 Sep 2015 13:51:53 -0700 (PDT)
In-Reply-To: <12FD6338-67B0-4549-9D66-2C69FF0D739F@nic.cz>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>     <12FD6338-67B0-4549-9D66-2C69FF0D739F@nic.cz>
Date: Wed, 16 Sep 2015 13:51:53 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e013d170ef1f2dd051fe37725
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Sep 2015 20:51:59 -0000

--089e013d170ef1f2dd051fe37725
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 16, 2015 at 1:11 PM, Ladislav Lhotka  wrote:

>
> > On 16 Sep 2015, at 21:29, Andy Bierman  wrote:
> >
> >
> >
> > On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka  wrote=
:
> >
> > > On 16 Sep 2015, at 20:25, Andy Bierman  wrote:
> > >
> > >
> > >
> > > On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka 
> wrote:
> > >
> > > > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
> > > >>
> > > >> It can be stated in the description of the anydata statement. One
> can
> > > >> then ask though why we need two constructs - anyxml and anydata -
> > > >> because a data model can be specified in the description of an
> anyxml
> > > >> statement as well.
> > > >>
> > > >
> > > > The data model used by anydata content is clearly identified. The
> > >
> > > Hmm, how is it clearly identified? There needn=E2=80=99t be any data =
model at
> all.
> > >
> > > > difference between anyxml and anydata has been discussed at length
> and
> > > > we should not go there again.
> > >
> > > Then the 6020bis doesn=E2=80=99t make this difference clear, to me at=
 least.
> > >
> > >
> > > This is an academic exercise, but the difference is very clear.
> > >
> > > The "anyxml" node allows XML-specific details like processing
> instructions.
> > > It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> > > This is academic, because the vast majority of servers do not support
> anyxml
> > > at all.  None. Zero.  Not allowed in the server.  The few that do
> treat anyxml
> > > as if it were anydata.
> > >
> > > The "anydata" node is a blob of YANG data nodes.  It is not XML.
> > > It is not JSON. This too will likely not be implemented in the vast
> majority
> > > of servers.
> >
> > This is illusory unless a YANG data model is available, and, as you
> said, this is not guaranteed. For one, without a data model there is no w=
ay
> for mapping XML encoding to JSON and vice versa, so anydata received in o=
ne
> encoding cannot be sent back to clients supporting the other encoding.
> >
> >
> >
> > I don't like the idea of adding a requirement that the "hidden schema"
> be used
> > so that JSON people will be happy to get a number instead of a string,
> as if
> > that is actually a data model.
>
> Without a data model we also cannot map module names to XML namespaces.
>
>

Hence the value of using real data nodes instead of 'anydata'.
The 'anydata' statement says "this is a subtree without any schema".
So it doesn't really do much good to worry about encoding based on the
schema.

But if a YANG module declares an 'anydata' node then the description-stmt
for that node (or maybe extensions) MAY contain normative instructions for
encoding the descendant nodes within an anydata subtree.
This impacts conformance for that module, not general conformance
for 'anydata'.


Lada
>
>

Andy



> >
> > Unless there is a hidden schema, then it just doesn't matter if the
> client
> > passed in a JSON number and another client reads back an XML string.
> > There is no data model at all.  There is not even any schema that
> > says 'foo' can have any child nodes or not, let alone the required
> > QName and syntax for that child node.
> >
> > Users that want any sort of schema-based interoperability should not
> > use anydata instead of real data nodes.
> >
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > >
> > >
> > > Lada
> > >
> > >
> > >
> > > >
> > > > /js
> > > >
> > > > --
> > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> Germany
> > > > Fax:   +49 421 200 3103         
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Wed, Sep 16, 2015 at 1:11 PM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 16 Sep 2015, at 21:29, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> > On 16 Sep 2015, at 20:25, Andy Bierman <andy@yumaworks.com> wrote:

> >

> >

> >

> > On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> >

> > > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni=
versity.de> wrote:

> > >

> > > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wr=
ote:

> > >>

> > >> It can be stated in the description of the anydata state=
ment. One can

> > >> then ask though why we need two constructs - anyxml and =
anydata -

> > >> because a data model can be specified in the description=
 of an anyxml

> > >> statement as well.

> > >>

> > >

> > > The data model used by anydata content is clearly identified=
. The

> >

> > Hmm, how is it clearly identified? There needn=E2=80=99t be any d=
ata model at all.

> >

> > > difference between anyxml and anydata has been discussed at =
length and

> > > we should not go there again.

> >

> > Then the 6020bis doesn=E2=80=99t make this difference clear, to m=
e at least.

> >

> >

> > This is an academic exercise, but the difference is very clear.
> >

> > The "anyxml" node allows XML-specific details like proc=
essing instructions.

> > It is a blob of XML.=C2=A0 It is not JSON.=C2=A0 It is not YANG.=
=C2=A0 It is XML.

> > This is academic, because the vast majority of servers do not sup=
port anyxml

> > at all.=C2=A0 None. Zero.=C2=A0 Not allowed in the server.=C2=A0 =
The few that do treat anyxml

> > as if it were anydata.

> >

> > The "anydata" node is a blob of YANG data nodes.=C2=A0 =
It is not XML.

> > It is not JSON. This too will likely not be implemented in the va=
st majority

> > of servers.

>

> This is illusory unless a YANG data model is available, and, as you sa=
id, this is not guaranteed. For one, without a data model there is no way f=
or mapping XML encoding to JSON and vice versa, so anydata received in one =
encoding cannot be sent back to clients supporting the other encoding.

>

>

>

> I don't like the idea of adding a requirement that the "hidde=
n schema" be used

> so that JSON people will be happy to get a number instead of a string,=
 as if

> that is actually a data model.



Without a data model we also cannot map module names to XML namespaces.




Hence the value of usin=
g real data nodes instead of 'anydata'.
The 'anydata&=
#39; statement says "this is a subtree without any schema".
=

So it doesn't really do much good to worry about encoding based on=
 the schema.

But if a YANG module declares an '=
;anydata' node then the description-stmt
for that node (or ma=
ybe extensions) MAY contain normative instructions for
encoding t=
he descendant nodes within an anydata subtree.
This impacts confo=
rmance for that module, not general conformance
for 'anydata&=
#39;.



Lada




Andy

=C2=A0

>

> Unless there is a hidden schema, then it just doesn't matter if th=
e client

> passed in a JSON number and another client reads back an XML string.
> There is no data model at all.=C2=A0 There is not even any schema that=


> says 'foo' can have any child nodes or not, let alone the requ=
ired

> QName and syntax for that child node.

>

> Users that want any sort of schema-based interoperability should not
> use anydata instead of real data nodes.

>

>

>

> Lada

>

> Andy

>

>

> >

> >

> >

> > Lada

> >

> >

> >

> > >

> > > /js

> > >

> > > --

> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen gGmbH

> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cam=
pus Ring 1 | 28759 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/>

> >

> > --

> > Ladislav Lhotka, CZ.NIC Labs

> > PGP Key ID: E74E8C0C

> >

> >

> >

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/netmod

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--089e013d170ef1f2dd051fe37725--


From nobody Wed Sep 16 23:24:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD41ACDD4 for ; Wed, 16 Sep 2015 23:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw83_SzB_WVT for ; Wed, 16 Sep 2015 23:24:33 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D622B1ACDC8 for ; Wed, 16 Sep 2015 23:24:32 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 601DA1CC0157; Thu, 17 Sep 2015 08:24:34 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman 
In-Reply-To: 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>     <12FD6338-67B0-4549-9D66-2C69FF0D739F@nic.cz> 
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 17 Sep 2015 08:24:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 06:24:35 -0000

Andy Bierman  writes:

> On Wed, Sep 16, 2015 at 1:11 PM, Ladislav Lhotka  wrote:
>
>>
>> > On 16 Sep 2015, at 21:29, Andy Bierman  wrote:
>> >
>> >
>> >
>> > On Wed, Sep 16, 2015 at 11:55 AM, Ladislav Lhotka  wrot=
e:
>> >
>> > > On 16 Sep 2015, at 20:25, Andy Bierman  wrote:
>> > >
>> > >
>> > >
>> > > On Wed, Sep 16, 2015 at 10:50 AM, Ladislav Lhotka 
>> wrote:
>> > >
>> > > > On 16 Sep 2015, at 17:19, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>> > > >
>> > > > On Wed, Sep 16, 2015 at 08:03:10AM +0200, Ladislav Lhotka wrote:
>> > > >>
>> > > >> It can be stated in the description of the anydata statement. One
>> can
>> > > >> then ask though why we need two constructs - anyxml and anydata -
>> > > >> because a data model can be specified in the description of an
>> anyxml
>> > > >> statement as well.
>> > > >>
>> > > >
>> > > > The data model used by anydata content is clearly identified. The
>> > >
>> > > Hmm, how is it clearly identified? There needn=E2=80=99t be any data=
 model at
>> all.
>> > >
>> > > > difference between anyxml and anydata has been discussed at length
>> and
>> > > > we should not go there again.
>> > >
>> > > Then the 6020bis doesn=E2=80=99t make this difference clear, to me a=
t least.
>> > >
>> > >
>> > > This is an academic exercise, but the difference is very clear.
>> > >
>> > > The "anyxml" node allows XML-specific details like processing
>> instructions.
>> > > It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
>> > > This is academic, because the vast majority of servers do not support
>> anyxml
>> > > at all.  None. Zero.  Not allowed in the server.  The few that do
>> treat anyxml
>> > > as if it were anydata.
>> > >
>> > > The "anydata" node is a blob of YANG data nodes.  It is not XML.
>> > > It is not JSON. This too will likely not be implemented in the vast
>> majority
>> > > of servers.
>> >
>> > This is illusory unless a YANG data model is available, and, as you
>> said, this is not guaranteed. For one, without a data model there is no =
way
>> for mapping XML encoding to JSON and vice versa, so anydata received in =
one
>> encoding cannot be sent back to clients supporting the other encoding.
>> >
>> >
>> >
>> > I don't like the idea of adding a requirement that the "hidden schema"
>> be used
>> > so that JSON people will be happy to get a number instead of a string,
>> as if
>> > that is actually a data model.
>>
>> Without a data model we also cannot map module names to XML namespaces.
>>
>>
>
> Hence the value of using real data nodes instead of 'anydata'.
> The 'anydata' statement says "this is a subtree without any schema".

anyxml says the same.

> So it doesn't really do much good to worry about encoding based on the
> schema.
>
> But if a YANG module declares an 'anydata' node then the description-stmt
> for that node (or maybe extensions) MAY contain normative instructions for
> encoding the descendant nodes within an anydata subtree.
> This impacts conformance for that module, not general conformance
> for 'anydata'.
>

Yes, but the same thing can be done with anyxml, right? It has been
demonstrated in RFC 6241, ietf-yang-patch and probably elsewhere, too,
and it does the job.

The use case of passing around literally "any XML" is really only
theoretical, I think some kind of schema is always assumed.

So I believe we don't need two data node types for this purpose. And an
advantage of anyxml is that its definition (from YANG point of view) is
clear and unambiguous, whereas for anydata the phrase "can be modelled
with YANG" may be interpreted in different ways. We are introducing a
dubious new concept in YANG 1.1 with no apparent gain.

Lada

>
> Lada
>>
>>
>
> Andy
>
>
>
>> >
>> > Unless there is a hidden schema, then it just doesn't matter if the
>> client
>> > passed in a JSON number and another client reads back an XML string.
>> > There is no data model at all.  There is not even any schema that
>> > says 'foo' can have any child nodes or not, let alone the required
>> > QName and syntax for that child node.
>> >
>> > Users that want any sort of schema-based interoperability should not
>> > use anydata instead of real data nodes.
>> >
>> >
>> >
>> > Lada
>> >
>> > Andy
>> >
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>> > >
>> > > >
>> > > > /js
>> > > >
>> > > > --
>> > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>> Germany
>> > > > Fax:   +49 421 200 3103         
>> > >
>> > > --
>> > > Ladislav Lhotka, CZ.NIC Labs
>> > > PGP Key ID: E74E8C0C
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Thu Sep 17 01:13:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37481AD0CF; Thu, 17 Sep 2015 01:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptWPlS5BAo3E; Thu, 17 Sep 2015 01:13:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 739831AD0BB; Thu, 17 Sep 2015 01:13:22 -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.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150917081322.7673.97580.idtracker@ietfa.amsl.com>
Date: Thu, 17 Sep 2015 01:13:22 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 08:13:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : Defining and Using Metadata with YANG
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-yang-metadata-02.txt
	Pages           : 20
	Date            : 2015-09-17

Abstract:
   This document defines a YANG extension statement that allows for
   defining metadata annotations in YANG modules.  The document also
   specifies XML and JSON encoding of annotations and other rules for
   annotating instances of YANG data nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Sep 17 01:16:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94C1AD0CF for ; Thu, 17 Sep 2015 01:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cya8PthZm1sU for ; Thu, 17 Sep 2015 01:16:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1281AD0C5 for ; Thu, 17 Sep 2015 01:16:44 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 043E01818CD for ; Thu, 17 Sep 2015 10:16:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442477803; bh=vNOa+VHwFr7AlHK4vWM9OfrafFux9HZuHvOdqB9uY3g=; h=From:Date:To; b=U1TjETjaA2Af0joLdtr0Esxl0p+2uUMrjrJFk6voOWh5UpfvGXbHoxpzFYTdxRhis dLUP4djlZ2wl85cmaCvOspYJJKY6r2JBwknEjFpLrcxtx5b5usprylQkfd4rXsBYkl 7a19LJgywbUl3XruWOVI4l6VB8vCaDjrr1DssZkc=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Sep 2015 10:16:43 +0200
References: <20150917081322.7673.1991.idtracker@ietfa.amsl.com>
To: NETMOD Working Group 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 08:16:46 -0000

Hi,

this revision includes updates based on reviews by Benoit, Juergen, Kent =
and Martin, thanks to all.

Please check especially sections 3 and 4.

Thanks, Lada

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-ietf-netmod-yang-metadata-02.txt
> Date: 17 Sep 2015 10:13:22 CEST
> To: "Ladislav Lhotka" , "Ladislav Lhotka" =

>=20
>=20
> A new version of I-D, draft-ietf-netmod-yang-metadata-02.txt
> has been successfully submitted by Ladislav Lhotka and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-netmod-yang-metadata
> Revision:	02
> Title:		Defining and Using Metadata with YANG
> Document date:	2015-09-17
> Group:		netmod
> Pages:		20
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-metadata-02.tx=
t
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-metadata-02
>=20
> Abstract:
>   This document defines a YANG extension statement that allows for
>   defining metadata annotations in YANG modules.  The document also
>   specifies XML and JSON encoding of annotations and other rules for
>   annotating instances of YANG data nodes.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Sep 17 03:39:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472281B2CE5 for ; Thu, 17 Sep 2015 03:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBjLbmTZRzdn for ; Thu, 17 Sep 2015 03:39:50 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD6301B2CDD for ; Thu, 17 Sep 2015 03:39:49 -0700 (PDT)
Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id DFF641AE0959; Thu, 17 Sep 2015 12:39:47 +0200 (CEST)
Date: Thu, 17 Sep 2015 12:39:47 +0200 (CEST)
Message-Id: <20150917.123947.1589992296795354113.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20150914150234.GA67696@elstar.local> <20150915.155458.124799884157219010.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 10:39:52 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTUgU2Vw
IDIwMTUsIGF0IDE1OjU0LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6
DQo+ID4gDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz
LXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+PiBPbiBNb24sIFNlcCAxNCwgMjAxNSBhdCAwMzo1
NDo1OVBNICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+Pj4gDQo+ID4+PiBTdXJl
LiAgVGhlIHVzZSBjYXNlIGlzIGZvciBleGFtcGxlIHNlcnZlcnMgdGhhdCBpbXBsZW1lbnQgaWV0
Zi1pcA0KPiA+Pj4gKHdoaWNoIGltcG9ydHMgaWV0Zi1pbnRlcmZhY2VzKSwgYW5kIGlldGYtaW50
ZXJmYWNlcy4gIFN1cHBvc2Ugd2UNCj4gPj4+IHVwZGF0ZSBpZXRmLWludGVyZmFjZXMgdG8gMS4x
LiAgSXQgc2hvdWxkIHN0aWxsIGJlIG9rIGZvciBhIHNlcnZlciB0bw0KPiA+Pj4gaW1wbGVtZW50
IGlldGYtaXAgd2l0aCB0aGUgbmV3IGlldGYtaW50ZXJmYWNlcy4NCj4gPj4+IA0KPiA+PiANCj4g
Pj4gSXMgdGhlIGNvbmZ1c2lvbiBpcyBiZXR3ZWVuIGltcGxlbWVudHMgYW5kIGltcG9ydHMgaGVy
ZT8gVGhlIG1vZHVsZQ0KPiA+PiBpZXRmLWlwIHdpbGwgX2ltcG9ydF8gYW4gb2xkZXIgdmVyc2lv
biAxIGlldGYtaW50ZXJmYWNlcyB3aGlsZSB0aGUNCj4gPj4gc2VydmVyIF9pbXBsZW1lbnRzXyBh
IG5ld2VyIHZlcnNpb24gMS4xIGlldGYtaW50ZXJmYWNlcyBtb2R1bGUuIElzDQo+ID4+IHRoaXMg
bm90IGdvaW5nIHRvIHdvcms/DQo+ID4+IA0KPiA+Pj4+IFdvdWxkIGl0IG5vdCB3b3JrIGlmIGFu
IGltcG9ydCBvZiBpZXRmLWludGVyZmFjZXMgZnJvbSBhDQo+ID4+Pj4gdmVyc2lvbiAxIG1vZHVs
ZSBzaW1wbHkgcmVzb2x2ZXMgdG8gdGhlIGxhdGVzdCBpZXRmLWludGVyZmFjZXMNCj4gPj4+PiBy
ZXZpc2lvbiB0aGF0IGlzIHN0aWxsIHZlcnNpb24gMT8NCj4gPj4+IA0KPiA+Pj4gQnV0IHRoYXQg
d291bGQgbWVhbiBlaXRoZXIgdGhhdCBhIHNlcnZlciBpcyBzdHVjayBpbXBsZW1lbnRpbmcgdmVy
c2lvbg0KPiA+Pj4gMSBtb2R1bGVzLCBvciB0aGF0IHRoZSBzZXJ2ZXIgbXVzdCBpbXBsZW1lbnQg
Ym90aCB0aGUgdmVyc2lvbiAxIGFuZA0KPiA+Pj4gdmVyc2lvbiAxLjEgbW9kdWxlIC0gYW5kIHdl
IGhhdmUgYWxyZWFkeSBzYWlkIHRoYXQgdGhpcyBpc24ndA0KPiA+Pj4gcG9zc2libGUuDQo+ID4+
IA0KPiA+PiBCdXQgdGhpcyBzZWVtcyBvbmx5IHRydWUgaWYgaW1wb3J0ID09PSBpbXBsZW1lbnRl
ZC4NCj4gPj4gDQo+ID4+PiBBIHNldCBvZiBzaW1wbGVyIHJ1bGVzIHdvdWxkIGJlOg0KPiA+Pj4g
DQo+ID4+PiAgIEEgWUFORyB2ZXJzaW9uIDEuMSBtb2R1bGUgTVVTVCBOT1QgaW5jbHVkZSBhIHZl
cnNpb24gMSBtb2R1bGUuDQo+ID4+PiAgIEEgWUFORyB2ZXJzaW9uIDEgbW9kdWxlIE1VU1QgTk9U
IGluY2x1ZGUgYSB2ZXJzaW9uIDEuMSBtb2R1bGUuDQo+ID4+PiANCj4gPj4+ICAgQSBZQU5HIHZl
cnNpb24gMS4xIChzdWIpbW9kdWxlIE1BWSBpbXBvcnQgYSB2ZXJzaW9uIDEgbW9kdWxlLg0KPiA+
Pj4gICBBIFlBTkcgdmVyc2lvbiAxIChzdWIpbW9kdWxlIE1BWSBpbXBvcnQgYSB2ZXJzaW9uIDEu
MSBtb2R1bGUuDQo+ID4+IA0KPiA+PiBJdCBpcyB0aGUgbGFzdCBvbmUgd2UgYXJlIGRpc2N1c3Np
bmcsIG5vPyBJIGFtIHRyeWluZyBhZ2FpbjogV2h5IGlzDQo+ID4+IHRoZSBNQVkgbmVlZGVkPyBX
aHkgaXMgaXQgbm90IHN1ZmZpY2llbnQgZm9yIGEgdmVyc2lvbiAxIG1vZHVsZSB0bw0KPiA+PiB3
b3JrIHdpdGggYW4gaW1wb3J0IGZvciAodGhlIGxhdGVzdCkgdmVyc2lvbiAxIG1vZHVsZT8NCj4g
PiANCj4gPiBIb3cgYWJvdXQgdGhpczoNCj4gPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tDQo+
ID4gDQo+ID4gKiBDb2V4aXN0ZW5jZSB3aXRoIFlBTkcgdmVyc2lvbiAxIEBjb2V4aXN0ZW5jZUAN
Cj4gPiANCj4gPiBBIFlBTkcgdmVyc2lvbiAxLjEgbW9kdWxlIE1VU1QgTk9UIGluY2x1ZGUgYSBZ
QU5HIHZlcnNpb24gMSBzdWJtb2R1bGUsDQo+ID4gYW5kIGEgWUFORyB2ZXJzaW9uIDEgbW9kdWxl
IE1VU1QgTk9UIGluY2x1ZGUgYSBZQU5HIHZlcnNpb24gMS4xDQo+ID4gc3VibW9kdWxlLg0KPiAN
Cj4gRG9lcyB0aGlzIGFwcGx5IG9ubHkgdG8gaW5jbHVkZS1ieS1yZXZpc2lvbj8gQmVjYXVzZSBv
dGhlcndpc2UgaG93IGNhbg0KPiB3ZSB0ZWxsPw0KDQpJdCBpcyBzdXBwb3NlZCB0byBhcHBseSB0
byBib3RoOyBpZiBpdCBpcyBpbmNsdWRlIGJ5IHJldmlzaW9uIGl0IGlzDQpvYnZpb3VzLCBidXQg
Zm9yIGluY2x1ZGUgdy9vIHJldmlzaW9uIGl0IG1lYW5zIHRoYXQgYW55IHRvb2wgKHNlcnZlciwN
CmNsaWVudCwgLi4uKSBNVVNUIHRyZWF0IHZlcnNpb24gbWlzbWF0Y2ggYXMgYW4gZXJyb3IuDQoN
Cj4gPiBBIFlBTkcgdmVyc2lvbiAxIG1vZHVsZSBvciBzdWJtb2R1bGUgTVVTVCBOT1QgaW1wb3J0
IGEgWUFORyB2ZXJzaW9uDQo+ID4gMS4xIG1vZHVsZSBieSByZXZpc2lvbi4NCj4gPiANCj4gPiBB
IFlBTkcgdmVyc2lvbiAxLjEgbW9kdWxlIG9yIHN1Ym1vZHVsZSBNQVkgaW1wb3J0IGEgWUFORyB2
ZXJzaW9uDQo+ID4gMSBtb2R1bGUgYnkgcmV2aXNpb24uDQo+ID4gDQo+ID4gSWYgYSBZQU5HIHZl
cnNpb24gMSBtb2R1bGUgQSBpbXBvcnRzIG1vZHVsZSBCIHdpdGhvdXQgcmV2aXNpb24sIGFuZA0K
PiA+IG1vZHVsZSBCIGlzIHVwZGF0ZWQgdG8gWUFORyB2ZXJzaW9uIDEuMSwgYSBzZXJ2ZXIgTUFZ
IGltcGxlbWVudCBib3RoDQo+IA0KPiBXaGF0IGFib3V0IGltcG9ydHMgdGhhdCBhcmUgb25seSBm
b3IgZ3JvdXBpbmdzL3R5cGVkZWZzPw0KDQpUaGV5IGFyZSBzdXBwb3NlZCB0byBiZSBjb3ZlcmVk
Lg0KDQo+IOKAnEltcGxlbWVudOKAnQ0KPiBkb2VzbuKAmXQgY292ZXIgdGhpcyBjYXNlDQoNCkRv
IHdlIGhhdmUgYSB3b3JkIHRoYXQgY292ZXJzIHRoZW0gYXMgd2VsbD8NCg0KPiwgYW5kIHN1Y2gg
aW1wb3J0ZWQgbW9kdWxlcyBkb27igJl0IGFwcGVhciBpbg0KPiBoZWxsby4NCg0KV2VsbCB0aGlz
IGlzIG5vdCBjbGVhciBpbiA2MDIwLiAgVGhleSBtYXkgb3IgbWF5IG5vdCBhcHBlYXIgaW4gdGhl
DQpoZWxsby4gIChJIHRoaW5rIG1vc3QgaW1wbGVtZW50YXRpb25zIGFjdHVhbGx5IGRvIGluY2x1
ZGUgdGhlbSBpbiB0aGUNCmhlbGxvKS4NCg0KDQovbWFydGluDQoNCg0KPiANCj4gTGFkYQ0KPiAN
Cj4gPiB0aGVzZSBtb2R1bGVzIGF0IHRoZSBzYW1lIHRpbWUuICBJbiBzdWNoIGNhc2VzLCBhIE5F
VENPTkYgc2VydmVyIE1VU1QNCj4gPiBhZHZlcnRpc2UgYm90aCBtb2R1bGVzIHVzaW5nIHRoZSBy
dWxlcyBkZWZpbmVkIGluIF5hbm5vdW5jZV4sIGFuZA0KPiA+IFNIT1VMRCBhZHZlcnRpc2UgbW9k
dWxlIEEgYW5kIHRoZSBsYXRlc3QgcmV2aXNpb24gb2YgbW9kdWxlIEIgdGhhdCBpcw0KPiA+IHNw
ZWNpZmllZCB3aXRoIFlBTkcgdmVyc2lvbiAxIGFjY29yZGluZwl0byB0aGUgcnVsZXMgZGVmaW5l
ZCBpbg0KPiA+IF5SRkM2MDIwXi4NCj4gPiANCj4gPiBUaGlzIHJ1bGUgZXhpc3RzIGluIG9yZGVy
IHRvIGFsbG93IGltcGxlbWVudGF0aW9ucyBvZiBleGlzdGluZyBZQU5HDQo+ID4gdmVyc2lvbiAx
IG1vZHVsZXMgdG9nZXRoZXIgd2l0aCBZQU5HIHZlcnNpb24gMS4xIG1vZHVsZXMuICBXaXRob3V0
DQo+ID4gdGhpcyBydWxlLCB1cGRhdGluZyBhIHNpbmdsZSBtb2R1bGUgdG8gWUFORyB2ZXJzaW9u
IDEuMSB3b3VsZCBoYXZlIGENCj4gPiBjYXNjYWRpbmcgZWZmZWN0IG9uIG1vZHVsZXMgdGhhdCBp
bXBvcnQgaXQsIHJlcXVpcmluZyBhbGwgb2YgdGhlbSB0bw0KPiA+IGFsc28gYmUgdXBkYXRlZCB0
byBZQU5HIHZlcnNpb24gMS4xLCBhbmQgc28gb24uDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0tLS0t
LQ0KPiA+IA0KPiA+IE5vdGUgdGhhdCB0aGlzIHRleHQgYWdhaW4gdGFsa3MgYWJvdXQgTkVUQ09O
RiBpbiB0aGUgbWFpbiB0ZXh0Li4uDQo+ID4gDQo+ID4gDQo+ID4gL21hcnRpbg0KPiA+IA0KPiA+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0
bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90
a2EsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0KPiANCj4gDQo+IA0K


From nobody Thu Sep 17 03:57:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9951B2CEE for ; Thu, 17 Sep 2015 03:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYXAGpZ4saeK for ; Thu, 17 Sep 2015 03:57:35 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D831B2CE5 for ; Thu, 17 Sep 2015 03:57:34 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:64c6:b78:c6c3:337c] (unknown [IPv6:2001:718:1a02:1:64c6:b78:c6c3:337c]) by mail.nic.cz (Postfix) with ESMTPSA id 4D01D181842; Thu, 17 Sep 2015 12:57:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442487453; bh=Z2e8lc/24dOidnVlZ528FJU0RqxPX3nXIIKZXJC79/I=; h=From:Date:To; b=EzwqonqdZIul3S6Q06UAWKa7FCLGt40LDrim1qG/FHybZHZOHYiSAjTZ8UGgrCiD9 YrINcTRzWcas+kRdFi0r16AF3AKKljY4vsXhBPbAIDBAQWXvK/LgmktpECsybE9LEv NjukCgtvtPg8ln8ruKknd5gw5egO3opdIEk7nV5Y=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150917.123947.1589992296795354113.mbj@tail-f.com>
Date: Thu, 17 Sep 2015 12:57:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CD0F8DB-C20A-4F34-B9DF-2BC920994050@nic.cz>
References: <20150914150234.GA67696@elstar.local> <20150915.155458.124799884157219010.mbj@tail-f.com>  <20150917.123947.1589992296795354113.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 10:57:37 -0000

> On 17 Sep 2015, at 12:39, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 15 Sep 2015, at 15:54, Martin Bjorklund  wrote:
>>>=20
>>> Juergen Schoenwaelder  wrote:
>>>> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
>>>>>=20
>>>>> Sure.  The use case is for example servers that implement ietf-ip
>>>>> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
>>>>> update ietf-interfaces to 1.1.  It should still be ok for a server =
to
>>>>> implement ietf-ip with the new ietf-interfaces.
>>>>>=20
>>>>=20
>>>> Is the confusion is between implements and imports here? The module
>>>> ietf-ip will _import_ an older version 1 ietf-interfaces while the
>>>> server _implements_ a newer version 1.1 ietf-interfaces module. Is
>>>> this not going to work?
>>>>=20
>>>>>> Would it not work if an import of ietf-interfaces from a
>>>>>> version 1 module simply resolves to the latest ietf-interfaces
>>>>>> revision that is still version 1?
>>>>>=20
>>>>> But that would mean either that a server is stuck implementing =
version
>>>>> 1 modules, or that the server must implement both the version 1 =
and
>>>>> version 1.1 module - and we have already said that this isn't
>>>>> possible.
>>>>=20
>>>> But this seems only true if import =3D=3D=3D implemented.
>>>>=20
>>>>> A set of simpler rules would be:
>>>>>=20
>>>>>  A YANG version 1.1 module MUST NOT include a version 1 module.
>>>>>  A YANG version 1 module MUST NOT include a version 1.1 module.
>>>>>=20
>>>>>  A YANG version 1.1 (sub)module MAY import a version 1 module.
>>>>>  A YANG version 1 (sub)module MAY import a version 1.1 module.
>>>>=20
>>>> It is the last one we are discussing, no? I am trying again: Why is
>>>> the MAY needed? Why is it not sufficient for a version 1 module to
>>>> work with an import for (the latest) version 1 module?
>>>=20
>>> How about this:
>>>=20
>>> -------------------
>>>=20
>>> * Coexistence with YANG version 1 @coexistence@
>>>=20
>>> A YANG version 1.1 module MUST NOT include a YANG version 1 =
submodule,
>>> and a YANG version 1 module MUST NOT include a YANG version 1.1
>>> submodule.
>>=20
>> Does this apply only to include-by-revision? Because otherwise how =
can
>> we tell?
>=20
> It is supposed to apply to both; if it is include by revision it is
> obvious, but for include w/o revision it means that any tool (server,
> client, ...) MUST treat version mismatch as an error.

Do you mean that it depends on what revisions are actually available to =
the tool? The formulation looks like it it aimed at module authors.

>=20
>>> A YANG version 1 module or submodule MUST NOT import a YANG version
>>> 1.1 module by revision.
>>>=20
>>> A YANG version 1.1 module or submodule MAY import a YANG version
>>> 1 module by revision.
>>>=20
>>> If a YANG version 1 module A imports module B without revision, and
>>> module B is updated to YANG version 1.1, a server MAY implement both
>>=20
>> What about imports that are only for groupings/typedefs?
>=20
> They are supposed to be covered.
>=20
>> =E2=80=9CImplement=E2=80=9D
>> doesn=E2=80=99t cover this case
>=20
> Do we have a word that covers them as well?

Probably not, it would be useful to have it.

>=20
>> , and such imported modules don=E2=80=99t appear in
>> hello.
>=20
> Well this is not clear in 6020.  They may or may not appear in the
> hello.  (I think most implementations actually do include them in the
> hello).

But that means it is impossible to reuse top-level typedefs/groupings =
from a module without implementing all its data.
And what if different modules import different revisions of the same =
module?

Lada

>=20
>=20
> /martin
>=20
>=20
>>=20
>> Lada
>>=20
>>> these modules at the same time.  In such cases, a NETCONF server =
MUST
>>> advertise both modules using the rules defined in ^announce^, and
>>> SHOULD advertise module A and the latest revision of module B that =
is
>>> specified with YANG version 1 according	to the rules defined in
>>> ^RFC6020^.
>>>=20
>>> This rule exists in order to allow implementations of existing YANG
>>> version 1 modules together with YANG version 1.1 modules.  Without
>>> this rule, updating a single module to YANG version 1.1 would have a
>>> cascading effect on modules that import it, requiring all of them to
>>> also be updated to YANG version 1.1, and so on.
>>>=20
>>> ----------------
>>>=20
>>> Note that this text again talks about NETCONF in the main text...
>>>=20
>>>=20
>>> /martin
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Sep 17 11:21:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82B61B30C7 for ; Thu, 17 Sep 2015 11:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp80dNlr91BM for ; Thu, 17 Sep 2015 11:21:46 -0700 (PDT)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5E91B30CA for ; Thu, 17 Sep 2015 11:21:44 -0700 (PDT)
Received: by lbpo4 with SMTP id o4so13813367lbp.2 for ; Thu, 17 Sep 2015 11:21:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zyVW3rzN5L/d/cOdUSafsdHvS5qYvKPRv7toCaoU4ww=; b=mJGlXCc9ReuyTPjzsfME7RptzRBR/wd4O8heJYQZS8tWfpO1iIDs/S5JuCdtrkVi/o ANBmsKEt9afd1ENAtt60P+X7GBZAzWMidk46xUwfCtTr80ICawUoE3JwNxmd3ZgEuPga 1SU+KrDYsC2oaWFm66T8dHCVDv84IuyBuGL1f65sYNxMNOnzZxcU9jqGkKv70zRgl903 lNbxtrsS4Su+kgfbALfuilS+nuNa6B0tnc5RciB4h7V4VD3ZZWjDk5BjTkcw0EwfUV4R I4sMWi13jYXXNfH6SVu99nJMFrTxRGefae9HPgOMfX7pWQhtEIwD03OPHrtnOPHFczzs qy6A==
X-Gm-Message-State: ALoCoQnpP2njHOXYkb95ub6t4Co9atMrM0KQp2lqCK8Tkl8yGM4/lxa3RSv/4bsQyXXjDkMWAeO9
MIME-Version: 1.0
X-Received: by 10.152.179.40 with SMTP id dd8mr664362lac.119.1442514103110; Thu, 17 Sep 2015 11:21:43 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Thu, 17 Sep 2015 11:21:43 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 17 Sep 2015 11:21:43 -0700
Message-ID: 
From: Andy Bierman 
To: "Eric Voit (evoit)" 
Content-Type: multipart/alternative; boundary=001a113433eeb3291e051ff57c84
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" , Sander Mertens 
Subject: Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 18:21:48 -0000

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

Hi,


I think the NETCONF WG really needs to think about the architecture
it is creating, and the role of proxy servers in network management.

When we were designing NETCONF (pre-4741) we were told by
knowledgeable operators like Randy Bush that NETCONF MUST NOT
have any Proxy-based management, because it added too much complexity.

   To date systems built upon YANG models have been missing two
   capabilities:

   1.  YANG Datastore Mount: Datastores have not been able to proxy
       objects located elsewhere on the same device, or upon a different
       device.  This puts additional burden upon applications which then
       need to find and access multiple locations and which may be on
       remote systems.

   2.  Eventual Consistency: YANG Datastore implementations have
       typically assumed ACID [1] transaction models.  There is nothing
       inherent in YANG itself which demands ACID transactional
       guarantees.  YANG models can also expose information which might
       be in the process of undergoing convergence.  Since IP networking
       has been designed with convergence in mind, this is a useful
       capability since some types of applications must participate
       where there is dynamically changing state.

The NETCONF WG should decide first "we need proxy servers" before debating
the best way to do that.

We have been told there are systems that converge very slowly (although
nobody seems
to know if that means 5 minutes of 5 hours).  All the "get-actual" type of
proposals
seem to address this issue.  Not sure how YANG Mount addresses the issue,
and how it is related to the other solution proposals.


Andy



On Tue, Sep 15, 2015 at 8:21 AM, Eric Voit (evoit)  wrote:

> There was a recent thread on structuring YANG models so that application
> developers might be able to reference alternative local hierarchies/tree
> structures for certain objects.  This thread motivated Alex, Sander, and I
> to rework the YANG Mount requirements draft.  v03 is posted at:
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/
>
> This draft has been retitled to "Requirements for mounting of local and
> remote YANG subtrees".  This retitling was done because we have separated
> the thinking on what it takes to Mount objects from remote devices (Peer
> Mount) from what it takes to Mount within the same device (Alias Mount).
>
> We would be interested in your thoughts.
>
> Eric
>
> -----Original Message-----
> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>
> Randy Presuhn  writes:
>
> > Hi -
> >
> > It is with no little amusement that I watch this thread struggling
> > with questions that were solved fairly neatly a quarter century ago in
> > GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like
> > to offer an observation about modeling that might help.
> >
> > The organization of instance data in SNMP is a direct mirror of the
> > "object" definitions.  Simple at first, but quickly becoming baroque
> > as various minds of "multiplexing" are added to compensate for post
> > hoc deficiencies in the index structures.
> >
> > Life is such that once a resource has been modeled, it will be
> > used/re-used/embedded in systems in ways in which its designers
> > couldn't be expected to imagine.  A consequence of this is that if
> > instance naming is completely locked down when the management
> > interface for a resource is first defined (as it is in SNMP) then all
> > sorts of peculiar hacks will be needed to deal with, for example,
> > virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so
> > pervasive that folks seem to overlook that there are other ways to
> > deal with this situation.
> >
> > What GDMO did was to use a separate "NAME BINDING" construct to
> > specify contexts in which instances might show up, allowing instances
> > to be put in places that weren't even imagined when the original class
> > definition was written.  Name bindings could be standardized, or be
> > vendor or even product-specific, allowing the simplicity or complexity
> > of a given system's instance tree to reflect the actual simplicity or
> > complexity of that system, rather than requiring all systems to be
> > structured for the worst case.
>
> How could this be expressed in YANG terms? (I tried to figure it out
> myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT
> Recommendation X.722).
>
> Thanks, Lada
>
> >
> > Yes, separating the specification of instance naming in large part
> > from class definition does have implications for how one does access
> > control, and how clients figure out how to ask a server to create
> > something, but it's not a huge deal - it's just not like VACM, and a
> > whole slew of hacky solutions and "wierd plumbing adapters" (to borrow
> > from Jeff Case) just go away.  Strangely, it makes the job of the
> > initial modeler and of the eventual user much easier.
> >
> > Randy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,


I think the NETCONF =
WG really needs to think about the architecture
it is creating, a=
nd the role of proxy servers in network management.

When we were designing NETCONF (pre-4741) we were told by
knowl=
edgeable operators like Randy Bush that NETCONF MUST NOT
have any=
 Proxy-based management, because it added too much complexity.
   To date systems built upon YANG models have =
been missing two
   capabilities:

   1.  YANG Datastore Mount: Datastores have not been able to proxy
       objects located elsewhere on the same device, or upon a different
       device.  This puts additional burden upon applications which then
       need to find and access multiple locations and which may be on
       remote systems.

   2.  Eventual Consistency: YANG Datastore implementations have
       typically assumed ACID [1] transaction models.  There is nothing
       inherent in YANG itself which demands ACID transactional
       guarantees.  YANG models can also expose information which might
       be in the process of undergoing convergence.  Since IP networking
       has been designed with convergence in mind, this is a useful
       capability since some types of applications must participate
       where there is dynamically changing state.


The NETCONF WG should decide first "we need proxy servers" =
before debating
the best way to do that.

We hav=
e been told there are systems that converge very slowly (although nobody se=
ems
to know if that means 5 minutes of 5 hours).=C2=A0 All the &q=
uot;get-actual" type of proposals
seem to address this issue=
.=C2=A0 Not sure how YANG Mount addresses the issue,
and how it i=
s related to the other solution proposals.


Andy



On Tue, Sep 15, 2015 at 8:21 AM, Eric =
Voit (evoit) <evoit@cisco.com> wrote:
There was a recent thread on structuring YANG models so that appl=
ication developers might be able to reference alternative local hierarchies=
/tree structures for certain objects.=C2=A0 This thread motivated Alex, San=
der, and I to rework the YANG Mount requirements draft.=C2=A0 v03 is posted=
 at:

http://datatracker.ietf.or=
g/doc/draft-voit-netmod-peer-mount-requirements/



This draft has been retitled to "Requirements for mounting of local an=
d remote YANG subtrees".=C2=A0 This retitling was done because we have=
 separated the thinking on what it takes to Mount objects from remote devic=
es (Peer Mount) from what it takes to Mount within the same device (Alias M=
ount).



We would be interested in your thoughts.



Eric



-----Original Message-----

From: Ladislav Lhotka, August 31, 2015 11:05 AM



Randy Presuhn <randy_pre=
suhn@mindspring.com> writes:



> Hi -

>

> It is with no little amusement that I watch this thread struggling

> with questions that were solved fairly neatly a quarter century ago in=


> GDMO/CMIP-land.=C2=A0 I'm *not* suggesting we go back there, but w=
ould like

> to offer an observation about modeling that might help.

>

> The organization of instance data in SNMP is a direct mirror of the
> "object" definitions.=C2=A0 Simple at first, but quickly bec=
oming baroque

> as various minds of "multiplexing" are added to compensate f=
or post

> hoc deficiencies in the index structures.

>

> Life is such that once a resource has been modeled, it will be

> used/re-used/embedded in systems in ways in which its designers

> couldn't be expected to imagine.=C2=A0 A consequence of this is th=
at if

> instance naming is completely locked down when the management

> interface for a resource is first defined (as it is in SNMP) then all<=
br>
> sorts of peculiar hacks will be needed to deal with, for example,

> virtual routers.=C2=A0 Unfortunately, an SNMP/SMI-like mindset is so
> pervasive that folks seem to overlook that there are other ways to

> deal with this situation.

>

> What GDMO did was to use a separate "NAME BINDING" construct=
 to

> specify contexts in which instances might show up, allowing instances<=
br>
> to be put in places that weren't even imagined when the original c=
lass

> definition was written.=C2=A0 Name bindings could be standardized, or =
be

> vendor or even product-specific, allowing the simplicity or complexity=


> of a given system's instance tree to reflect the actual simplicity=
 or

> complexity of that system, rather than requiring all systems to be

> structured for the worst case.



How could this be expressed in YANG terms? (I tried to figure it out myself=
 but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recom=
mendation X.722).



Thanks, Lada



>

> Yes, separating the specification of instance naming in large part

> from class definition does have implications for how one does access
> control, and how clients figure out how to ask a server to create

> something, but it's not a huge deal - it's just not like VACM,=
 and a

> whole slew of hacky solutions and "wierd plumbing adapters" =
(to borrow

> from Jeff Case) just go away.=C2=A0 Strangely, it makes the job of the=


> initial modeler and of the eventual user much easier.

>

> Randy

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a113433eeb3291e051ff57c84--


From nobody Thu Sep 17 11:55:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ACF1B3122 for ; Thu, 17 Sep 2015 11:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VvLOvQbhlrH for ; Thu, 17 Sep 2015 11:55:53 -0700 (PDT)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 37E771B311F for ; Thu, 17 Sep 2015 11:55:53 -0700 (PDT)
Received: by lamp12 with SMTP id p12so16819403lam.0 for ; Thu, 17 Sep 2015 11:55:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oGMxoX9s6W5sIz4BNZAt9WtNBDPv6EAMpAFxpjU9knU=; b=H05W+n39UkdZoy3aDtxwYeBuZqC2ZNlkrMd5RV0hqLmXaLRv832i7SPF8JzkRex4E7 KbXLKMjBMRis2DYiaIM8ZnHwWgxUbIy3/SI06SDL0aezDDHXqU9o8luKHCCQiFSqLMzg jJjxNDBvk7TEtS1GaFCSStYm3QIfJFVLWlxXsNEBR48xz2neZuKda+MTManXts85J9fq SWEp1pL63d8fGSuowFziziIS0X7a1nYTBrf6ADBXXgQ1kzu5xlIU8njtlzCC+rMpufM1 6nqMiY3vw6zcTH7bNKvWHZzax57EQTawbJqmz9HblXsbcEZZVoAS3lorQZBCKO0cZ53j Ui2A==
X-Gm-Message-State: ALoCoQnJ3mXjINEmkv8aiSL7KlmE1dLnZ0waUjLs4agkALvJt1TmkRvAC46MaYIX6YkYqc2PDwVm
MIME-Version: 1.0
X-Received: by 10.152.30.105 with SMTP id r9mr889289lah.33.1442516151236; Thu, 17 Sep 2015 11:55:51 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Thu, 17 Sep 2015 11:55:51 -0700 (PDT)
In-Reply-To: <20150917.123947.1589992296795354113.mbj@tail-f.com>
References: <20150914150234.GA67696@elstar.local> <20150915.155458.124799884157219010.mbj@tail-f.com>  <20150917.123947.1589992296795354113.mbj@tail-f.com>
Date: Thu, 17 Sep 2015 11:55:51 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=089e0160b794c716b7051ff5f6a0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 18:55:56 -0000

--089e0160b794c716b7051ff5f6a0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 17, 2015 at 3:39 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
> >
> > > On 15 Sep 2015, at 15:54, Martin Bjorklund  wrote:
> > >
> > > Juergen Schoenwaelder  wrote:
> > >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > >>>
> > >>> Sure.  The use case is for example servers that implement ietf-ip
> > >>> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > >>> update ietf-interfaces to 1.1.  It should still be ok for a server =
to
> > >>> implement ietf-ip with the new ietf-interfaces.
> > >>>
> > >>
> > >> Is the confusion is between implements and imports here? The module
> > >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> > >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> > >> this not going to work?
> > >>
> > >>>> Would it not work if an import of ietf-interfaces from a
> > >>>> version 1 module simply resolves to the latest ietf-interfaces
> > >>>> revision that is still version 1?
> > >>>
> > >>> But that would mean either that a server is stuck implementing
> version
> > >>> 1 modules, or that the server must implement both the version 1 and
> > >>> version 1.1 module - and we have already said that this isn't
> > >>> possible.
> > >>
> > >> But this seems only true if import =3D=3D=3D implemented.
> > >>
> > >>> A set of simpler rules would be:
> > >>>
> > >>>   A YANG version 1.1 module MUST NOT include a version 1 module.
> > >>>   A YANG version 1 module MUST NOT include a version 1.1 module.
> > >>>
> > >>>   A YANG version 1.1 (sub)module MAY import a version 1 module.
> > >>>   A YANG version 1 (sub)module MAY import a version 1.1 module.
> > >>
> > >> It is the last one we are discussing, no? I am trying again: Why is
> > >> the MAY needed? Why is it not sufficient for a version 1 module to
> > >> work with an import for (the latest) version 1 module?
> > >
> > > How about this:
> > >
> > > -------------------
> > >
> > > * Coexistence with YANG version 1 @coexistence@
> > >
> > > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule=
,
> > > and a YANG version 1 module MUST NOT include a YANG version 1.1
> > > submodule.
> >
> > Does this apply only to include-by-revision? Because otherwise how can
> > we tell?
>
> It is supposed to apply to both; if it is include by revision it is
> obvious, but for include w/o revision it means that any tool (server,
> client, ...) MUST treat version mismatch as an error.
>

This is still a problem:

    A YANG version 1 (sub)module MAY import a version 1.1 module.

This assumes the tools understand YANG 1.1.
YANG 1 says it is undefined what happens if the YANG 1 compiler
finds a yang-version value other than '1'.

You want to make a distinction between a YANG 1.1 capable tool
and a YANG 1.0 capable tool. Obviously a YANG 1 capable tool
is not required to EVER accept a YANG 1.1 module.

So when the YANG author imports a YANG 1.1 module from a YANG 1 module
and no revision date is given, there really are no rules that YANG 1.1 can
specify
that would apply to a YANG 1 tool.  There is no way to enforce any
interoperability
requirements wrt/ the revision of the imported module that is used in this
case.





>
> > > A YANG version 1 module or submodule MUST NOT import a YANG version
> > > 1.1 module by revision.
> > >
> > > A YANG version 1.1 module or submodule MAY import a YANG version
> > > 1 module by revision.
> > >
> > > If a YANG version 1 module A imports module B without revision, and
> > > module B is updated to YANG version 1.1, a server MAY implement both
> >
> > What about imports that are only for groupings/typedefs?
>
> They are supposed to be covered.
>
> > =E2=80=9CImplement=E2=80=9D
> > doesn=E2=80=99t cover this case
>
> Do we have a word that covers them as well?
>
> >, and such imported modules don=E2=80=99t appear in
> > hello.
>
> Well this is not clear in 6020.  They may or may not appear in the
> hello.  (I think most implementations actually do include them in the
> hello).
>
>
Yes -- and there is no way we are ever changing this code.
The full list of revision dates is needed so the client and server will
produce the same schema set.  YANG 1 would be unusable without this info.



>
> /martin
>
>

Andy


>
> >
> > Lada
> >
> > > these modules at the same time.  In such cases, a NETCONF server MUST
> > > advertise both modules using the rules defined in ^announce^, and
> > > SHOULD advertise module A and the latest revision of module B that is
> > > specified with YANG version 1 according     to the rules defined in
> > > ^RFC6020^.
> > >
> > > This rule exists in order to allow implementations of existing YANG
> > > version 1 modules together with YANG version 1.1 modules.  Without
> > > this rule, updating a single module to YANG version 1.1 would have a
> > > cascading effect on modules that import it, requiring all of them to
> > > also be updated to YANG version 1.1, and so on.
> > >
> > > ----------------
> > >
> > > Note that this text again talks about NETCONF in the main text...
> > >
> > >
> > > /martin
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Thu, Sep 17, 2015 at 3:39 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> > On 15 Sep 2015, at 15:54, Martin Bjorklund <mbj@tail-f.com> wrote:

> >

> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wr=
ote:

> >>>

> >>> Sure.=C2=A0 The use case is for example servers that impl=
ement ietf-ip

> >>> (which imports ietf-interfaces), and ietf-interfaces.=C2=
=A0 Suppose we

> >>> update ietf-interfaces to 1.1.=C2=A0 It should still be o=
k for a server to

> >>> implement ietf-ip with the new ietf-interfaces.

> >>>

> >>

> >> Is the confusion is between implements and imports here? The =
module

> >> ietf-ip will _import_ an older version 1 ietf-interfaces whil=
e the

> >> server _implements_ a newer version 1.1 ietf-interfaces modul=
e. Is

> >> this not going to work?

> >>

> >>>> Would it not work if an import of ietf-interfaces fro=
m a

> >>>> version 1 module simply resolves to the latest ietf-i=
nterfaces

> >>>> revision that is still version 1?

> >>>

> >>> But that would mean either that a server is stuck impleme=
nting version

> >>> 1 modules, or that the server must implement both the ver=
sion 1 and

> >>> version 1.1 module - and we have already said that this i=
sn't

> >>> possible.

> >>

> >> But this seems only true if import =3D=3D=3D implemented.

> >>

> >>> A set of simpler rules would be:

> >>>

> >>>=C2=A0 =C2=A0A YANG version 1.1 module MUST NOT include a =
version 1 module.

> >>>=C2=A0 =C2=A0A YANG version 1 module MUST NOT include a ve=
rsion 1.1 module.

> >>>

> >>>=C2=A0 =C2=A0A YANG version 1.1 (sub)module MAY import a v=
ersion 1 module.

> >>>=C2=A0 =C2=A0A YANG version 1 (sub)module MAY import a ver=
sion 1.1 module.

> >>

> >> It is the last one we are discussing, no? I am trying again: =
Why is

> >> the MAY needed? Why is it not sufficient for a version 1 modu=
le to

> >> work with an import for (the latest) version 1 module?

> >

> > How about this:

> >

> > -------------------

> >

> > * Coexistence with YANG version 1 @coexistence@

> >

> > A YANG version 1.1 module MUST NOT include a YANG version 1 submo=
dule,

> > and a YANG version 1 module MUST NOT include a YANG version 1.1
> > submodule.

>

> Does this apply only to include-by-revision? Because otherwise how can=


> we tell?



It is supposed to apply to both; if it is include by revision it is

obvious, but for include w/o revision it means that any tool (server,

client, ...) MUST treat version mismatch as an error.
=

This is still a problem:

=C2=A0 =C2=
=A0 A YANG version 1 (sub)module MAY import a version 1.1 module.
=


This assumes the tools understand YANG 1.1.
Y=
ANG 1 says it is undefined what happens if the YANG 1 compiler
fi=
nds a yang-version value other than '1'.

Y=
ou want to make a distinction between a YANG 1.1 capable tool
and=
 a YANG 1.0 capable tool. Obviously a YANG 1 capable tool
is not =
required to EVER accept a YANG 1.1 module.

So when=
 the YANG author imports a YANG 1.1 module from a YANG 1 module
a=
nd no revision date is given, there really are no rules that YANG 1.1 can s=
pecify
that would apply to a YANG 1 tool.=C2=A0 There is no way t=
o enforce any interoperability
requirements wrt/ the revision of =
the imported module that is used in this case.


=C2=A0



> > A YANG version 1 module or submodule MUST NOT import a YANG versi=
on

> > 1.1 module by revision.

> >

> > A YANG version 1.1 module or submodule MAY import a YANG version<=
br>
> > 1 module by revision.

> >

> > If a YANG version 1 module A imports module B without revision, a=
nd

> > module B is updated to YANG version 1.1, a server MAY implement b=
oth

>

> What about imports that are only for groupings/typedefs?



They are supposed to be covered.



> =E2=80=9CImplement=E2=80=9D

> doesn=E2=80=99t cover this case



Do we have a word that covers them as well?



>, and such imported modules don=E2=80=99t appear in

> hello.



Well this is not clear in 6020.=C2=A0 They may or may not appear in the

hello.=C2=A0 (I think most implementations actually do include them in the<=
br>
hello).



Yes -- and there is no way we are ever=
 changing this code.
The full list of revision dates is needed so=
 the client and server will
produce the same schema set.=C2=A0 YA=
NG 1 would be unusable without this info.

=C2=A0



/martin




Andy
=C2=A0



>

> Lada

>

> > these modules at the same time.=C2=A0 In such cases, a NETCONF se=
rver MUST

> > advertise both modules using the rules defined in ^announce^, and=


> > SHOULD advertise module A and the latest revision of module B tha=
t is

> > specified with YANG version 1 according=C2=A0 =C2=A0 =C2=A0to the=
 rules defined in

> > ^RFC6020^.

> >

> > This rule exists in order to allow implementations of existing YA=
NG

> > version 1 modules together with YANG version 1.1 modules.=C2=A0 W=
ithout

> > this rule, updating a single module to YANG version 1.1 would hav=
e a

> > cascading effect on modules that import it, requiring all of them=
 to

> > also be updated to YANG version 1.1, and so on.

> >

> > ----------------

> >

> > Note that this text again talks about NETCONF in the main text...=


> >

> >

> > /martin

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/netmod

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

_______________________________________________

netmod mailing list

netmod@ietf.org

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





--089e0160b794c716b7051ff5f6a0--


From nobody Thu Sep 17 12:30:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D81A8968 for ; Thu, 17 Sep 2015 12:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgY4UP5wYZeI for ; Thu, 17 Sep 2015 12:30:47 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C777A1A6FF0 for ; Thu, 17 Sep 2015 12:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38634; q=dns/txt; s=iport; t=1442518246; x=1443727846; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+FPfp5o7+eHSOEou8UcF6AFvKWHm1IIfEyygF+bXkaQ=; b=e2w3+qryu4lBkpR+Qe7CnOXqKaC+XWUJlQHDO/NXkNlJHzgqC4KpUlvD +EZeGmrGi0oL+WF32qTtQCZpbMbZVCi1n7TtLaF0g5UtSvEp/xstMIkBB yt4zDrn5+ugsewL9dPpUQj9XK5vc9oiCY2QGnJJ+caENxJFwsnQ8YYVht s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AkAgAhFPtV/4oNJK1VCIJTTVRpBqx8kEABDYFvAQuFLUoCHIEpOBQBAQEBAQEBgQqEIwEBAQMBAQEBIApBCwUHBAIBCBIDIwEGAwICAiULFAMOAgQOBQgBEAKICwgNt0WUOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9gj6BeAUBAQUpBxcEBgEJgiU7EoExBYx7AYU9gygBhRCJQkaVGoNsAREOAQFCghEcFoE+cQGIajqBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,548,1437436800";  d="scan'208,217";a="189071042"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 17 Sep 2015 19:30:44 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t8HJUiBV004702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2015 19:30:44 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Sep 2015 14:30:43 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Thu, 17 Sep 2015 14:30:43 -0500
From: "Eric Voit (evoit)" 
To: Andy Bierman 
Thread-Topic: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
Thread-Index: AQHQ8XW+z0pPL4ZgfE+QMHw8hrK1p55BDXWg
Date: Thu, 17 Sep 2015 19:30:43 +0000
Message-ID: 
References:  
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.229]
Content-Type: multipart/alternative; boundary="_000_c8a68c9263dd4d2ea35a744f23c1fd95XCHALN013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" , Sander Mertens 
Subject: Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 19:30:51 -0000

--_000_c8a68c9263dd4d2ea35a744f23c1fd95XCHALN013ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIGZvciB5b3VyIHRob3VnaHRzIEFuZHkuICBJIGJlbGlldmUgdGhlIGNvbXBsZXhpdGll
cyBvZiBwcm94eSBjYW4gYmUgb3V0d2VpZ2hlZCBieSB0aGUgYmVuZWZpdHMgb2Ygc2ltcGxpZnlp
bmcgbGlmZSBmb3IgdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciBpbiB0d28gc2NlbmFyaW9zOg0K
DQoNCigxKSAgICBBbGlhcyBNb3VudDogd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgb3IgY29udGV4
dCBzcGVjaWZpYyBleHBvc3VyZXMgb2YgdGhlIHNhbWUgb2JqZWN0Lg0KTm90ZTogSSB3YXMgYXR0
ZW1wdGluZyB0byBjYXB0dXJlIHNvbWUgb2YgdGhlIGlkZWEgeW91IHdlcmUgcmVmZXJyaW5nIHRv
IGF0IHRoZSBlbmQgb2YgeW91ciDigJxZMzQgLSByb290IG5vZGXigJ0gcG9zdDogaHR0cDovL3d3
dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzEzMjYwLmh0bWwg
ICAgSXQgaXMgdXNlZnVsIHdoZW4gYW4gYXBwbGljYXRpb24gZGV2ZWxvcGVyIGRvZXNu4oCZdCBo
YXZlIHRvIGh1bnQgZG93biB0aHJvdWdoIGRvemVucyBvZiBtb2RlbHMvdHJlZXMgZm9yIHRoZSBm
ZXcgb2JqZWN0cyB0aGV5IGNhcmUgYWJvdXQuDQoNCg0KKDIpICAgIFBlZXIgTW91bnQ6IHdoZW4g
YXBwbGljYXRpb25zIG5lZWQgYSBsb2NhbCByZXByZXNlbnRhdGlvbiBvZiBvYmplY3RzIHNpdHRp
bmcgb24gYSByZW1vdGUgZGV2aWNlLg0KTm90ZTogSSBrbm93IHRoaXMgaXMgbW9yZSBjb250cm92
ZXJzaWFsLiAgQnV0IGEgdGhlIEdvb2dsZSBzZWFyY2ggb2YgIk1vdW50IiBvbiBzaXRlID0gb3Bl
bmRheWxpZ2h0Lm9yZyBnaXZlcyBvdmVyIDEwMDAgaGl0cyByZWxhdGluZyB0byBZQU5HLCBOZXRj
b25mLCBhbmQgUmVzdGNvbmYuICBTb21lIGFyZSBmaW5kaW5nIGl0IHVzZWZ1bC4NCg0KSSBhZ3Jl
ZSB0aGF0IHRoZSBXRyBuZWVkcyB0byBkZWNpZGUgd2hldGhlciB3ZSB3YW50IHRvIHRha2Ugb24g
c29tZSBvciBhbGwgb2YgdGhpcyB0b3BpYy4NCg0KRXJpYw0KDQpGcm9tOiBBbmR5IEJpZXJtYW4s
IFNlcHRlbWJlciAxNywgMjAxNSAyOjIyIFBNDQoNCkhpLA0KDQoNCkkgdGhpbmsgdGhlIE5FVENP
TkYgV0cgcmVhbGx5IG5lZWRzIHRvIHRoaW5rIGFib3V0IHRoZSBhcmNoaXRlY3R1cmUNCml0IGlz
IGNyZWF0aW5nLCBhbmQgdGhlIHJvbGUgb2YgcHJveHkgc2VydmVycyBpbiBuZXR3b3JrIG1hbmFn
ZW1lbnQuDQoNCldoZW4gd2Ugd2VyZSBkZXNpZ25pbmcgTkVUQ09ORiAocHJlLTQ3NDEpIHdlIHdl
cmUgdG9sZCBieQ0Ka25vd2xlZGdlYWJsZSBvcGVyYXRvcnMgbGlrZSBSYW5keSBCdXNoIHRoYXQg
TkVUQ09ORiBNVVNUIE5PVA0KaGF2ZSBhbnkgUHJveHktYmFzZWQgbWFuYWdlbWVudCwgYmVjYXVz
ZSBpdCBhZGRlZCB0b28gbXVjaCBjb21wbGV4aXR5Lg0KDQoNCiAgIFRvIGRhdGUgc3lzdGVtcyBi
dWlsdCB1cG9uIFlBTkcgbW9kZWxzIGhhdmUgYmVlbiBtaXNzaW5nIHR3bw0KDQogICBjYXBhYmls
aXRpZXM6DQoNCg0KDQogICAxLiAgWUFORyBEYXRhc3RvcmUgTW91bnQ6IERhdGFzdG9yZXMgaGF2
ZSBub3QgYmVlbiBhYmxlIHRvIHByb3h5DQoNCiAgICAgICBvYmplY3RzIGxvY2F0ZWQgZWxzZXdo
ZXJlIG9uIHRoZSBzYW1lIGRldmljZSwgb3IgdXBvbiBhIGRpZmZlcmVudA0KDQogICAgICAgZGV2
aWNlLiAgVGhpcyBwdXRzIGFkZGl0aW9uYWwgYnVyZGVuIHVwb24gYXBwbGljYXRpb25zIHdoaWNo
IHRoZW4NCg0KICAgICAgIG5lZWQgdG8gZmluZCBhbmQgYWNjZXNzIG11bHRpcGxlIGxvY2F0aW9u
cyBhbmQgd2hpY2ggbWF5IGJlIG9uDQoNCiAgICAgICByZW1vdGUgc3lzdGVtcy4NCg0KDQoNCiAg
IDIuICBFdmVudHVhbCBDb25zaXN0ZW5jeTogWUFORyBEYXRhc3RvcmUgaW1wbGVtZW50YXRpb25z
IGhhdmUNCg0KICAgICAgIHR5cGljYWxseSBhc3N1bWVkIEFDSUQgWzFdIHRyYW5zYWN0aW9uIG1v
ZGVscy4gIFRoZXJlIGlzIG5vdGhpbmcNCg0KICAgICAgIGluaGVyZW50IGluIFlBTkcgaXRzZWxm
IHdoaWNoIGRlbWFuZHMgQUNJRCB0cmFuc2FjdGlvbmFsDQoNCiAgICAgICBndWFyYW50ZWVzLiAg
WUFORyBtb2RlbHMgY2FuIGFsc28gZXhwb3NlIGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0DQoNCiAg
ICAgICBiZSBpbiB0aGUgcHJvY2VzcyBvZiB1bmRlcmdvaW5nIGNvbnZlcmdlbmNlLiAgU2luY2Ug
SVAgbmV0d29ya2luZw0KDQogICAgICAgaGFzIGJlZW4gZGVzaWduZWQgd2l0aCBjb252ZXJnZW5j
ZSBpbiBtaW5kLCB0aGlzIGlzIGEgdXNlZnVsDQoNCiAgICAgICBjYXBhYmlsaXR5IHNpbmNlIHNv
bWUgdHlwZXMgb2YgYXBwbGljYXRpb25zIG11c3QgcGFydGljaXBhdGUNCg0KICAgICAgIHdoZXJl
IHRoZXJlIGlzIGR5bmFtaWNhbGx5IGNoYW5naW5nIHN0YXRlLg0KDQoNClRoZSBORVRDT05GIFdH
IHNob3VsZCBkZWNpZGUgZmlyc3QgIndlIG5lZWQgcHJveHkgc2VydmVycyIgYmVmb3JlIGRlYmF0
aW5nDQp0aGUgYmVzdCB3YXkgdG8gZG8gdGhhdC4NCg0KV2UgaGF2ZSBiZWVuIHRvbGQgdGhlcmUg
YXJlIHN5c3RlbXMgdGhhdCBjb252ZXJnZSB2ZXJ5IHNsb3dseSAoYWx0aG91Z2ggbm9ib2R5IHNl
ZW1zDQp0byBrbm93IGlmIHRoYXQgbWVhbnMgNSBtaW51dGVzIG9mIDUgaG91cnMpLiAgQWxsIHRo
ZSAiZ2V0LWFjdHVhbCIgdHlwZSBvZiBwcm9wb3NhbHMNCnNlZW0gdG8gYWRkcmVzcyB0aGlzIGlz
c3VlLiAgTm90IHN1cmUgaG93IFlBTkcgTW91bnQgYWRkcmVzc2VzIHRoZSBpc3N1ZSwNCmFuZCBo
b3cgaXQgaXMgcmVsYXRlZCB0byB0aGUgb3RoZXIgc29sdXRpb24gcHJvcG9zYWxzLg0KDQoNCkFu
ZHkNCg0KDQoNCk9uIFR1ZSwgU2VwIDE1LCAyMDE1IGF0IDg6MjEgQU0sIEVyaWMgVm9pdCAoZXZv
aXQpIDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhl
cmUgd2FzIGEgcmVjZW50IHRocmVhZCBvbiBzdHJ1Y3R1cmluZyBZQU5HIG1vZGVscyBzbyB0aGF0
IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgbWlnaHQgYmUgYWJsZSB0byByZWZlcmVuY2UgYWx0ZXJu
YXRpdmUgbG9jYWwgaGllcmFyY2hpZXMvdHJlZSBzdHJ1Y3R1cmVzIGZvciBjZXJ0YWluIG9iamVj
dHMuICBUaGlzIHRocmVhZCBtb3RpdmF0ZWQgQWxleCwgU2FuZGVyLCBhbmQgSSB0byByZXdvcmsg
dGhlIFlBTkcgTW91bnQgcmVxdWlyZW1lbnRzIGRyYWZ0LiAgdjAzIGlzIHBvc3RlZCBhdDoNCmh0
dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3Vu
dC1yZXF1aXJlbWVudHMvDQoNClRoaXMgZHJhZnQgaGFzIGJlZW4gcmV0aXRsZWQgdG8gIlJlcXVp
cmVtZW50cyBmb3IgbW91bnRpbmcgb2YgbG9jYWwgYW5kIHJlbW90ZSBZQU5HIHN1YnRyZWVzIi4g
IFRoaXMgcmV0aXRsaW5nIHdhcyBkb25lIGJlY2F1c2Ugd2UgaGF2ZSBzZXBhcmF0ZWQgdGhlIHRo
aW5raW5nIG9uIHdoYXQgaXQgdGFrZXMgdG8gTW91bnQgb2JqZWN0cyBmcm9tIHJlbW90ZSBkZXZp
Y2VzIChQZWVyIE1vdW50KSBmcm9tIHdoYXQgaXQgdGFrZXMgdG8gTW91bnQgd2l0aGluIHRoZSBz
YW1lIGRldmljZSAoQWxpYXMgTW91bnQpLg0KDQpXZSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIHlv
dXIgdGhvdWdodHMuDQoNCkVyaWMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IExhZGlzbGF2IExob3RrYSwgQXVndXN0IDMxLCAyMDE1IDExOjA1IEFNDQoNClJhbmR5IFByZXN1
aG4gPHJhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb208bWFpbHRvOnJhbmR5X3ByZXN1aG5AbWlu
ZHNwcmluZy5jb20+PiB3cml0ZXM6DQoNCj4gSGkgLQ0KPg0KPiBJdCBpcyB3aXRoIG5vIGxpdHRs
ZSBhbXVzZW1lbnQgdGhhdCBJIHdhdGNoIHRoaXMgdGhyZWFkIHN0cnVnZ2xpbmcNCj4gd2l0aCBx
dWVzdGlvbnMgdGhhdCB3ZXJlIHNvbHZlZCBmYWlybHkgbmVhdGx5IGEgcXVhcnRlciBjZW50dXJ5
IGFnbyBpbg0KPiBHRE1PL0NNSVAtbGFuZC4gIEknbSAqbm90KiBzdWdnZXN0aW5nIHdlIGdvIGJh
Y2sgdGhlcmUsIGJ1dCB3b3VsZCBsaWtlDQo+IHRvIG9mZmVyIGFuIG9ic2VydmF0aW9uIGFib3V0
IG1vZGVsaW5nIHRoYXQgbWlnaHQgaGVscC4NCj4NCj4gVGhlIG9yZ2FuaXphdGlvbiBvZiBpbnN0
YW5jZSBkYXRhIGluIFNOTVAgaXMgYSBkaXJlY3QgbWlycm9yIG9mIHRoZQ0KPiAib2JqZWN0IiBk
ZWZpbml0aW9ucy4gIFNpbXBsZSBhdCBmaXJzdCwgYnV0IHF1aWNrbHkgYmVjb21pbmcgYmFyb3F1
ZQ0KPiBhcyB2YXJpb3VzIG1pbmRzIG9mICJtdWx0aXBsZXhpbmciIGFyZSBhZGRlZCB0byBjb21w
ZW5zYXRlIGZvciBwb3N0DQo+IGhvYyBkZWZpY2llbmNpZXMgaW4gdGhlIGluZGV4IHN0cnVjdHVy
ZXMuDQo+DQo+IExpZmUgaXMgc3VjaCB0aGF0IG9uY2UgYSByZXNvdXJjZSBoYXMgYmVlbiBtb2Rl
bGVkLCBpdCB3aWxsIGJlDQo+IHVzZWQvcmUtdXNlZC9lbWJlZGRlZCBpbiBzeXN0ZW1zIGluIHdh
eXMgaW4gd2hpY2ggaXRzIGRlc2lnbmVycw0KPiBjb3VsZG4ndCBiZSBleHBlY3RlZCB0byBpbWFn
aW5lLiAgQSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgaWYNCj4gaW5zdGFuY2UgbmFtaW5n
IGlzIGNvbXBsZXRlbHkgbG9ja2VkIGRvd24gd2hlbiB0aGUgbWFuYWdlbWVudA0KPiBpbnRlcmZh
Y2UgZm9yIGEgcmVzb3VyY2UgaXMgZmlyc3QgZGVmaW5lZCAoYXMgaXQgaXMgaW4gU05NUCkgdGhl
biBhbGwNCj4gc29ydHMgb2YgcGVjdWxpYXIgaGFja3Mgd2lsbCBiZSBuZWVkZWQgdG8gZGVhbCB3
aXRoLCBmb3IgZXhhbXBsZSwNCj4gdmlydHVhbCByb3V0ZXJzLiAgVW5mb3J0dW5hdGVseSwgYW4g
U05NUC9TTUktbGlrZSBtaW5kc2V0IGlzIHNvDQo+IHBlcnZhc2l2ZSB0aGF0IGZvbGtzIHNlZW0g
dG8gb3Zlcmxvb2sgdGhhdCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0bw0KPiBkZWFsIHdpdGggdGhp
cyBzaXR1YXRpb24uDQo+DQo+IFdoYXQgR0RNTyBkaWQgd2FzIHRvIHVzZSBhIHNlcGFyYXRlICJO
QU1FIEJJTkRJTkciIGNvbnN0cnVjdCB0bw0KPiBzcGVjaWZ5IGNvbnRleHRzIGluIHdoaWNoIGlu
c3RhbmNlcyBtaWdodCBzaG93IHVwLCBhbGxvd2luZyBpbnN0YW5jZXMNCj4gdG8gYmUgcHV0IGlu
IHBsYWNlcyB0aGF0IHdlcmVuJ3QgZXZlbiBpbWFnaW5lZCB3aGVuIHRoZSBvcmlnaW5hbCBjbGFz
cw0KPiBkZWZpbml0aW9uIHdhcyB3cml0dGVuLiAgTmFtZSBiaW5kaW5ncyBjb3VsZCBiZSBzdGFu
ZGFyZGl6ZWQsIG9yIGJlDQo+IHZlbmRvciBvciBldmVuIHByb2R1Y3Qtc3BlY2lmaWMsIGFsbG93
aW5nIHRoZSBzaW1wbGljaXR5IG9yIGNvbXBsZXhpdHkNCj4gb2YgYSBnaXZlbiBzeXN0ZW0ncyBp
bnN0YW5jZSB0cmVlIHRvIHJlZmxlY3QgdGhlIGFjdHVhbCBzaW1wbGljaXR5IG9yDQo+IGNvbXBs
ZXhpdHkgb2YgdGhhdCBzeXN0ZW0sIHJhdGhlciB0aGFuIHJlcXVpcmluZyBhbGwgc3lzdGVtcyB0
byBiZQ0KPiBzdHJ1Y3R1cmVkIGZvciB0aGUgd29yc3QgY2FzZS4NCg0KSG93IGNvdWxkIHRoaXMg
YmUgZXhwcmVzc2VkIGluIFlBTkcgdGVybXM/IChJIHRyaWVkIHRvIGZpZ3VyZSBpdCBvdXQgbXlz
ZWxmIGJ1dCBJIHVuZm9ydHVuYXRlbHkgY291bGRuJ3QgbWFrZSBhbnkgc2Vuc2Ugb2Ygc2VjLiA4
LjYgaW4gQ0NJVFQgUmVjb21tZW5kYXRpb24gWC43MjIpLg0KDQpUaGFua3MsIExhZGENCg0KPg0K
PiBZZXMsIHNlcGFyYXRpbmcgdGhlIHNwZWNpZmljYXRpb24gb2YgaW5zdGFuY2UgbmFtaW5nIGlu
IGxhcmdlIHBhcnQNCj4gZnJvbSBjbGFzcyBkZWZpbml0aW9uIGRvZXMgaGF2ZSBpbXBsaWNhdGlv
bnMgZm9yIGhvdyBvbmUgZG9lcyBhY2Nlc3MNCj4gY29udHJvbCwgYW5kIGhvdyBjbGllbnRzIGZp
Z3VyZSBvdXQgaG93IHRvIGFzayBhIHNlcnZlciB0byBjcmVhdGUNCj4gc29tZXRoaW5nLCBidXQg
aXQncyBub3QgYSBodWdlIGRlYWwgLSBpdCdzIGp1c3Qgbm90IGxpa2UgVkFDTSwgYW5kIGENCj4g
d2hvbGUgc2xldyBvZiBoYWNreSBzb2x1dGlvbnMgYW5kICJ3aWVyZCBwbHVtYmluZyBhZGFwdGVy
cyIgKHRvIGJvcnJvdw0KPiBmcm9tIEplZmYgQ2FzZSkganVzdCBnbyBhd2F5LiAgU3RyYW5nZWx5
LCBpdCBtYWtlcyB0aGUgam9iIG9mIHRoZQ0KPiBpbml0aWFsIG1vZGVsZXIgYW5kIG9mIHRoZSBl
dmVudHVhbCB1c2VyIG11Y2ggZWFzaWVyLg0KPg0KPiBSYW5keQ0KPg0KPiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0
DQo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQotLQ0KTGFkaXNsYXYgTGhvdGth
LCBDWi5OSUMgTGFicw0KUEdQIEtleSBJRDogRTc0RThDMEMNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1v
ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K

--_000_c8a68c9263dd4d2ea35a744f23c1fd95XCHALN013ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n
czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ
cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm
b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBs
aS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJp
b3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4t
Ym90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ
cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9v
blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w
aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox
MTE2MDk4MjE0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk
czotMzkyNTU2MjEwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz
IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0K
CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs
aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0
Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu
dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K
QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs
aXN0IGwxDQoJe21zby1saXN0LWlkOjE1MzM4MzUxMzY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7
DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MzcxMTQzODIgLTU4MTI3NjUwOCA2NzY5ODcxMyA2
NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5
ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IlwoJTFcKSI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0
ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh
LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku
MHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0
IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs
Mg0KCXttc28tbGlzdC1pZDoxNjM0NDgwNzkzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z
by1saXN0LXRlbXBsYXRlLWlkczotMTk0MjQzMTY3MCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5
MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9
DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl
dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt
YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciB0aG91Z2h0cyBBbmR5
LiAmbmJzcDtJIGJlbGlldmUgdGhlIGNvbXBsZXhpdGllcyBvZiBwcm94eSBjYW4gYmUgb3V0d2Vp
Z2hlZCBieSB0aGUgYmVuZWZpdHMgb2Ygc2ltcGxpZnlpbmcgbGlmZSBmb3IgdGhlIGFwcGxpY2F0
aW9uIGRldmVsb3BlciBpbiB0d28NCiBzY2VuYXJpb3M6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy
YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s
aXN0OmwxIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl
Ij4oMSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi
PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbGlhcyBNb3VudDogd2hlbiB0
aGVyZSBhcmUgbXVsdGlwbGUgb3IgY29udGV4dCBzcGVjaWZpYyBleHBvc3VyZXMgb2YgdGhlIHNh
bWUgb2JqZWN0LiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Tm90ZTogSSB3YXMgYXR0ZW1wdGluZyB0byBjYXB0dXJlDQo8aT5z
b21lPC9pPiBvZiB0aGUgaWRlYSB5b3Ugd2VyZSByZWZlcnJpbmcgdG8gYXQgdGhlIGVuZCBvZiB5
b3VyIOKAnFkzNCAtIHJvb3Qgbm9kZeKAnSBwb3N0Og0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm
Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzEzMjYwLmh0bWwiPmh0dHA6
Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxMzI2MC5o
dG1sPC9hPiAmbmJzcDsmbmJzcDsmbmJzcDtJdCBpcyB1c2VmdWwgd2hlbiBhbiBhcHBsaWNhdGlv
biBkZXZlbG9wZXIgZG9lc27igJl0IGhhdmUgdG8gaHVudCBkb3duIHRocm91Z2ggZG96ZW5zIG9m
IG1vZGVscy90cmVlcyBmb3IgdGhlDQogZmV3IG9iamVjdHMgdGhleSBjYXJlIGFib3V0LiZuYnNw
OyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm
dDouMjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPCFb
aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPigyKTxzcGFuIHN0eWxlPSJmb250Ojcu
MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw
YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPlBlZXIgTW91bnQ6IHdoZW4gYXBwbGljYXRpb25zIG5lZWQgYSBsb2NhbCBy
ZXByZXNlbnRhdGlvbiBvZiBvYmplY3RzIHNpdHRpbmcgb24gYSByZW1vdGUgZGV2aWNlLiZuYnNw
Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi43NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Tm90ZTogSSBrbm93IHRoaXMgaXMgbW9yZSBjb250cm92ZXJzaWFsLiZuYnNwOyBCdXQgYSB0
aGUgR29vZ2xlIHNlYXJjaCBvZiAmcXVvdDtNb3VudCZxdW90OyBvbiBzaXRlID0gb3BlbmRheWxp
Z2h0Lm9yZyBnaXZlcyBvdmVyIDEwMDAgaGl0cyByZWxhdGluZw0KIHRvIFlBTkcsIE5ldGNvbmYs
IGFuZCBSZXN0Y29uZi4mbmJzcDsgU29tZSBhcmUgZmluZGluZyBpdCB1c2VmdWwuJm5ic3A7ICZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHRoZSBXRyBuZWVkcyB0byBkZWNpZGUgd2hldGhl
ciB3ZSB3YW50IHRvIHRha2Ugb24gc29tZSBvciBhbGwgb2YgdGhpcyB0b3BpYy4NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+IEFuZHkgQmllcm1hbiwgU2VwdGVtYmVyIDE3LCAyMDE1IDI6MjIg
UE08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHRoaW5rIHRo
ZSBORVRDT05GIFdHIHJlYWxseSBuZWVkcyB0byB0aGluayBhYm91dCB0aGUgYXJjaGl0ZWN0dXJl
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aXQgaXMgY3JlYXRpbmcsIGFuZCB0aGUgcm9sZSBvZiBwcm94
eSBzZXJ2ZXJzIGluIG5ldHdvcmsgbWFuYWdlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj5XaGVuIHdlIHdlcmUgZGVzaWduaW5nIE5FVENPTkYgKHBy
ZS00NzQxKSB3ZSB3ZXJlIHRvbGQgYnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5rbm93bGVkZ2VhYmxl
IG9wZXJhdG9ycyBsaWtlIFJhbmR5IEJ1c2ggdGhhdCBORVRDT05GIE1VU1QgTk9UPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+aGF2ZSBhbnkgUHJveHktYmFzZWQgbWFuYWdlbWVudCwgYmVjYXVzZSBpdCBh
ZGRlZCB0b28gbXVjaCBjb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt3
b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsgVG8gZGF0ZSBzeXN0ZW1zIGJ1aWx0IHVwb24gWUFORyBtb2RlbHMgaGF2ZSBiZWVuIG1pc3Np
bmcgdHdvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjYXBhYmlsaXRpZXM6
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsgMS4mbmJzcDsgWUFORyBEYXRhc3RvcmUgTW91bnQ6IERhdGFzdG9yZXMgaGF2
ZSBub3QgYmVlbiBhYmxlIHRvIHByb3h5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvYmplY3RzIGxvY2F0ZWQgZWxzZXdoZXJlIG9u
IHRoZSBzYW1lIGRldmljZSwgb3IgdXBvbiBhIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGV2aWNlLiZuYnNwOyBU
aGlzIHB1dHMgYWRkaXRpb25hbCBidXJkZW4gdXBvbiBhcHBsaWNhdGlvbnMgd2hpY2ggdGhlbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgbmVlZCB0byBmaW5kIGFuZCBhY2Nlc3MgbXVsdGlwbGUgbG9jYXRpb25zIGFuZCB3aGljaCBt
YXkgYmUgb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHJlbW90ZSBzeXN0ZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IEV2ZW50dWFs
IENvbnNpc3RlbmN5OiBZQU5HIERhdGFzdG9yZSBpbXBsZW1lbnRhdGlvbnMgaGF2ZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlw
aWNhbGx5IGFzc3VtZWQgQUNJRCBbMV0gdHJhbnNhY3Rpb24gbW9kZWxzLiZuYnNwOyBUaGVyZSBp
cyBub3RoaW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBpbmhlcmVudCBpbiBZQU5HIGl0c2VsZiB3aGljaCBkZW1hbmRzIEFDSUQg
dHJhbnNhY3Rpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgZ3VhcmFudGVlcy4mbmJzcDsgWUFORyBtb2RlbHMgY2FuIGFsc28g
ZXhwb3NlIGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBpbiB0aGUgcHJvY2VzcyBvZiB1
bmRlcmdvaW5nIGNvbnZlcmdlbmNlLiZuYnNwOyBTaW5jZSBJUCBuZXR3b3JraW5nPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYXMg
YmVlbiBkZXNpZ25lZCB3aXRoIGNvbnZlcmdlbmNlIGluIG1pbmQsIHRoaXMgaXMgYSB1c2VmdWw8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGNhcGFiaWxpdHkgc2luY2Ugc29tZSB0eXBlcyBvZiBhcHBsaWNhdGlvbnMgbXVzdCBwYXJ0
aWNpcGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgd2hlcmUgdGhlcmUgaXMgZHluYW1pY2FsbHkgY2hhbmdpbmcgc3RhdGUuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPlRoZSBORVRDT05GIFdHIHNob3VsZCBkZWNpZGUgZmlyc3QgJnF1b3Q7d2UgbmVl
ZCBwcm94eSBzZXJ2ZXJzJnF1b3Q7IGJlZm9yZSBkZWJhdGluZzxicj4NCnRoZSBiZXN0IHdheSB0
byBkbyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PldlIGhhdmUgYmVlbiB0b2xkIHRoZXJlIGFyZSBzeXN0ZW1zIHRoYXQgY29udmVyZ2UgdmVyeSBz
bG93bHkgKGFsdGhvdWdoIG5vYm9keSBzZWVtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRvIGtub3cg
aWYgdGhhdCBtZWFucyA1IG1pbnV0ZXMgb2YgNSBob3VycykuJm5ic3A7IEFsbCB0aGUgJnF1b3Q7
Z2V0LWFjdHVhbCZxdW90OyB0eXBlIG9mIHByb3Bvc2FsczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnNl
ZW0gdG8gYWRkcmVzcyB0aGlzIGlzc3VlLiZuYnNwOyBOb3Qgc3VyZSBob3cgWUFORyBNb3VudCBh
ZGRyZXNzZXMgdGhlIGlzc3VlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmFuZCBob3cgaXQgaXMgcmVs
YXRlZCB0byB0aGUgb3RoZXIgc29sdXRpb24gcHJvcG9zYWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFu
ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBUdWUsIFNl
cCAxNSwgMjAxNSBhdCA4OjIxIEFNLCBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmV2b2l0QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmV2b2l0QGNpc2NvLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPlRoZXJlIHdhcyBhIHJlY2VudCB0aHJlYWQgb24gc3RydWN0dXJpbmcg
WUFORyBtb2RlbHMgc28gdGhhdCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIG1pZ2h0IGJlIGFibGUg
dG8gcmVmZXJlbmNlIGFsdGVybmF0aXZlIGxvY2FsIGhpZXJhcmNoaWVzL3RyZWUgc3RydWN0dXJl
cyBmb3IgY2VydGFpbiBvYmplY3RzLiZuYnNwOyBUaGlzIHRocmVhZCBtb3RpdmF0ZWQgQWxleCwg
U2FuZGVyLA0KIGFuZCBJIHRvIHJld29yayB0aGUgWUFORyBNb3VudCByZXF1aXJlbWVudHMgZHJh
ZnQuJm5ic3A7IHYwMyBpcyBwb3N0ZWQgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50
cy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLzwvYT48YnI+DQo8YnI+DQpUaGlz
IGRyYWZ0IGhhcyBiZWVuIHJldGl0bGVkIHRvICZxdW90O1JlcXVpcmVtZW50cyBmb3IgbW91bnRp
bmcgb2YgbG9jYWwgYW5kIHJlbW90ZSBZQU5HIHN1YnRyZWVzJnF1b3Q7LiZuYnNwOyBUaGlzIHJl
dGl0bGluZyB3YXMgZG9uZSBiZWNhdXNlIHdlIGhhdmUgc2VwYXJhdGVkIHRoZSB0aGlua2luZyBv
biB3aGF0IGl0IHRha2VzIHRvIE1vdW50IG9iamVjdHMgZnJvbSByZW1vdGUgZGV2aWNlcyAoUGVl
ciBNb3VudCkgZnJvbSB3aGF0IGl0IHRha2VzIHRvIE1vdW50IHdpdGhpbg0KIHRoZSBzYW1lIGRl
dmljZSAoQWxpYXMgTW91bnQpLjxicj4NCjxicj4NCldlIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4g
eW91ciB0aG91Z2h0cy48YnI+DQo8YnI+DQpFcmljPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBMYWRpc2xhdiBMaG90a2EsIEF1Z3VzdCAzMSwgMjAxNSAx
MTowNSBBTTxicj4NCjxicj4NClJhbmR5IFByZXN1aG4gJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5k
eV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tIj5yYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tPC9h
PiZndDsgd3JpdGVzOjxicj4NCjxicj4NCiZndDsgSGkgLTxicj4NCiZndDs8YnI+DQomZ3Q7IEl0
IGlzIHdpdGggbm8gbGl0dGxlIGFtdXNlbWVudCB0aGF0IEkgd2F0Y2ggdGhpcyB0aHJlYWQgc3Ry
dWdnbGluZzxicj4NCiZndDsgd2l0aCBxdWVzdGlvbnMgdGhhdCB3ZXJlIHNvbHZlZCBmYWlybHkg
bmVhdGx5IGEgcXVhcnRlciBjZW50dXJ5IGFnbyBpbjxicj4NCiZndDsgR0RNTy9DTUlQLWxhbmQu
Jm5ic3A7IEknbSAqbm90KiBzdWdnZXN0aW5nIHdlIGdvIGJhY2sgdGhlcmUsIGJ1dCB3b3VsZCBs
aWtlPGJyPg0KJmd0OyB0byBvZmZlciBhbiBvYnNlcnZhdGlvbiBhYm91dCBtb2RlbGluZyB0aGF0
IG1pZ2h0IGhlbHAuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIG9yZ2FuaXphdGlvbiBvZiBpbnN0
YW5jZSBkYXRhIGluIFNOTVAgaXMgYSBkaXJlY3QgbWlycm9yIG9mIHRoZTxicj4NCiZndDsgJnF1
b3Q7b2JqZWN0JnF1b3Q7IGRlZmluaXRpb25zLiZuYnNwOyBTaW1wbGUgYXQgZmlyc3QsIGJ1dCBx
dWlja2x5IGJlY29taW5nIGJhcm9xdWU8YnI+DQomZ3Q7IGFzIHZhcmlvdXMgbWluZHMgb2YgJnF1
b3Q7bXVsdGlwbGV4aW5nJnF1b3Q7IGFyZSBhZGRlZCB0byBjb21wZW5zYXRlIGZvciBwb3N0PGJy
Pg0KJmd0OyBob2MgZGVmaWNpZW5jaWVzIGluIHRoZSBpbmRleCBzdHJ1Y3R1cmVzLjxicj4NCiZn
dDs8YnI+DQomZ3Q7IExpZmUgaXMgc3VjaCB0aGF0IG9uY2UgYSByZXNvdXJjZSBoYXMgYmVlbiBt
b2RlbGVkLCBpdCB3aWxsIGJlPGJyPg0KJmd0OyB1c2VkL3JlLXVzZWQvZW1iZWRkZWQgaW4gc3lz
dGVtcyBpbiB3YXlzIGluIHdoaWNoIGl0cyBkZXNpZ25lcnM8YnI+DQomZ3Q7IGNvdWxkbid0IGJl
IGV4cGVjdGVkIHRvIGltYWdpbmUuJm5ic3A7IEEgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0
IGlmPGJyPg0KJmd0OyBpbnN0YW5jZSBuYW1pbmcgaXMgY29tcGxldGVseSBsb2NrZWQgZG93biB3
aGVuIHRoZSBtYW5hZ2VtZW50PGJyPg0KJmd0OyBpbnRlcmZhY2UgZm9yIGEgcmVzb3VyY2UgaXMg
Zmlyc3QgZGVmaW5lZCAoYXMgaXQgaXMgaW4gU05NUCkgdGhlbiBhbGw8YnI+DQomZ3Q7IHNvcnRz
IG9mIHBlY3VsaWFyIGhhY2tzIHdpbGwgYmUgbmVlZGVkIHRvIGRlYWwgd2l0aCwgZm9yIGV4YW1w
bGUsPGJyPg0KJmd0OyB2aXJ0dWFsIHJvdXRlcnMuJm5ic3A7IFVuZm9ydHVuYXRlbHksIGFuIFNO
TVAvU01JLWxpa2UgbWluZHNldCBpcyBzbzxicj4NCiZndDsgcGVydmFzaXZlIHRoYXQgZm9sa3Mg
c2VlbSB0byBvdmVybG9vayB0aGF0IHRoZXJlIGFyZSBvdGhlciB3YXlzIHRvPGJyPg0KJmd0OyBk
ZWFsIHdpdGggdGhpcyBzaXR1YXRpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBHRE1PIGRp
ZCB3YXMgdG8gdXNlIGEgc2VwYXJhdGUgJnF1b3Q7TkFNRSBCSU5ESU5HJnF1b3Q7IGNvbnN0cnVj
dCB0bzxicj4NCiZndDsgc3BlY2lmeSBjb250ZXh0cyBpbiB3aGljaCBpbnN0YW5jZXMgbWlnaHQg
c2hvdyB1cCwgYWxsb3dpbmcgaW5zdGFuY2VzPGJyPg0KJmd0OyB0byBiZSBwdXQgaW4gcGxhY2Vz
IHRoYXQgd2VyZW4ndCBldmVuIGltYWdpbmVkIHdoZW4gdGhlIG9yaWdpbmFsIGNsYXNzPGJyPg0K
Jmd0OyBkZWZpbml0aW9uIHdhcyB3cml0dGVuLiZuYnNwOyBOYW1lIGJpbmRpbmdzIGNvdWxkIGJl
IHN0YW5kYXJkaXplZCwgb3IgYmU8YnI+DQomZ3Q7IHZlbmRvciBvciBldmVuIHByb2R1Y3Qtc3Bl
Y2lmaWMsIGFsbG93aW5nIHRoZSBzaW1wbGljaXR5IG9yIGNvbXBsZXhpdHk8YnI+DQomZ3Q7IG9m
IGEgZ2l2ZW4gc3lzdGVtJ3MgaW5zdGFuY2UgdHJlZSB0byByZWZsZWN0IHRoZSBhY3R1YWwgc2lt
cGxpY2l0eSBvcjxicj4NCiZndDsgY29tcGxleGl0eSBvZiB0aGF0IHN5c3RlbSwgcmF0aGVyIHRo
YW4gcmVxdWlyaW5nIGFsbCBzeXN0ZW1zIHRvIGJlPGJyPg0KJmd0OyBzdHJ1Y3R1cmVkIGZvciB0
aGUgd29yc3QgY2FzZS48YnI+DQo8YnI+DQpIb3cgY291bGQgdGhpcyBiZSBleHByZXNzZWQgaW4g
WUFORyB0ZXJtcz8gKEkgdHJpZWQgdG8gZmlndXJlIGl0IG91dCBteXNlbGYgYnV0IEkgdW5mb3J0
dW5hdGVseSBjb3VsZG4ndCBtYWtlIGFueSBzZW5zZSBvZiBzZWMuIDguNiBpbiBDQ0lUVCBSZWNv
bW1lbmRhdGlvbiBYLjcyMikuPGJyPg0KPGJyPg0KVGhhbmtzLCBMYWRhPGJyPg0KPGJyPg0KJmd0
Ozxicj4NCiZndDsgWWVzLCBzZXBhcmF0aW5nIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGluc3RhbmNl
IG5hbWluZyBpbiBsYXJnZSBwYXJ0PGJyPg0KJmd0OyBmcm9tIGNsYXNzIGRlZmluaXRpb24gZG9l
cyBoYXZlIGltcGxpY2F0aW9ucyBmb3IgaG93IG9uZSBkb2VzIGFjY2Vzczxicj4NCiZndDsgY29u
dHJvbCwgYW5kIGhvdyBjbGllbnRzIGZpZ3VyZSBvdXQgaG93IHRvIGFzayBhIHNlcnZlciB0byBj
cmVhdGU8YnI+DQomZ3Q7IHNvbWV0aGluZywgYnV0IGl0J3Mgbm90IGEgaHVnZSBkZWFsIC0gaXQn
cyBqdXN0IG5vdCBsaWtlIFZBQ00sIGFuZCBhPGJyPg0KJmd0OyB3aG9sZSBzbGV3IG9mIGhhY2t5
IHNvbHV0aW9ucyBhbmQgJnF1b3Q7d2llcmQgcGx1bWJpbmcgYWRhcHRlcnMmcXVvdDsgKHRvIGJv
cnJvdzxicj4NCiZndDsgZnJvbSBKZWZmIENhc2UpIGp1c3QgZ28gYXdheS4mbmJzcDsgU3RyYW5n
ZWx5LCBpdCBtYWtlcyB0aGUgam9iIG9mIHRoZTxicj4NCiZndDsgaW5pdGlhbCBtb2RlbGVyIGFu
ZCBvZiB0aGUgZXZlbnR1YWwgdXNlciBtdWNoIGVhc2llci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBS
YW5keTxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8
YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0K
Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kPC9hPjxicj4NCjxicj4NCi0tPGJyPg0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFi
czxicj4NClBHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_c8a68c9263dd4d2ea35a744f23c1fd95XCHALN013ciscocom_--


From nobody Thu Sep 17 12:48:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1EE1A037F for ; Thu, 17 Sep 2015 12:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T-lYf3H0M3E for ; Thu, 17 Sep 2015 12:48:09 -0700 (PDT)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 7A6991A899F for ; Thu, 17 Sep 2015 12:48:08 -0700 (PDT)
Received: by lbbmp1 with SMTP id mp1so14945215lbb.1 for ; Thu, 17 Sep 2015 12:48:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/6TwSsqltAZzTP0jbwwM0nZa08+VpMDYUfoPe+xRFs4=; b=ZdLfS7BGF0Itpqbq69OI0vrIWkxyueVH0hlWC5bwmCoarNzbQ6ytsP/SPIE13+m8UU 1BZEKkTMmLO0nHb0nMMCwYjweC+L9QalOwucPnLI85/OKBO2u4kS1PNVdJh0Bsu+IGWy x8yST6i1L6JNTnh70gz1fj+ZF0/f7uXR90FxR6qUOzKH5KcFFBomWDvzziZB7K41xS21 DUvIpD9VwT1oSKGh5k6EDGEHe3R5/ULvV4LTb7QlDFXLDhpq5No5917fNvhItZnknPLX p+tQZ32SRo3fCEGASgEi8y3xpq9a0GoZxkXE9mu4+mn4sOwUFGIIxC3el6Z/xIMrBcnZ S1Vw==
X-Gm-Message-State: ALoCoQkm1cSYnmlDLEpscKsZUUlU6ISPkT0Is3Vf6VZXmmy/Hg3iiqUOVWiTwNdRbmG2igLcQHo4
MIME-Version: 1.0
X-Received: by 10.152.30.105 with SMTP id r9mr1120511lah.33.1442519286551; Thu, 17 Sep 2015 12:48:06 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Thu, 17 Sep 2015 12:48:06 -0700 (PDT)
In-Reply-To: 
References:   
Date: Thu, 17 Sep 2015 12:48:06 -0700
Message-ID: 
From: Andy Bierman 
To: "Eric Voit (evoit)" 
Content-Type: multipart/alternative; boundary=089e0160b794a82dc6051ff6b146
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" , Sander Mertens 
Subject: Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 19:48:12 -0000

--089e0160b794a82dc6051ff6b146
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 17, 2015 at 12:30 PM, Eric Voit (evoit)  wrote=
:

> Thanks for your thoughts Andy.  I believe the complexities of proxy can b=
e
> outweighed by the benefits of simplifying life for the application
> developer in two scenarios:
>
>
>
> (1)    Alias Mount: when there are multiple or context specific exposures
> of the same object.
>
> Note: I was attempting to capture *some* of the idea you were referring
> to at the end of your =E2=80=9CY34 - root node=E2=80=9D post:
> http://www.ietf.org/mail-archive/web/netmod/current/msg13260.html    It
> is useful when an application developer doesn=E2=80=99t have to hunt down=
 through
> dozens of models/trees for the few objects they care about.
>
>
>
> (2)    Peer Mount: when applications need a local representation of
> objects sitting on a remote device.
>
> Note: I know this is more controversial.  But a the Google search of
> "Mount" on site =3D opendaylight.org gives over 1000 hits relating to YAN=
G,
> Netconf, and Restconf.  Some are finding it useful.
>
>
>
> I agree that the WG needs to decide whether we want to take on some or al=
l
> of this topic.
>
>
>

The landscape has changed a lot since the RFC 3535 timeframe,
in which the only proxy was really SNMP Proxy.

Once we start talking about standardizing the controller layer,
it isn't really proxy anymore (in the same sense we thought about it in the
90s).
I look at YANG Mount, pub/sub, etc. together as a "configurable push model"=
.
This could be a much better design than hard-coded polling.   It is the
kind of
feature we would expect to see, moving from a proprietary controller to
a standardized controller.


Eric
>

Andy



>
>
> *From:* Andy Bierman, September 17, 2015 2:22 PM
>
> Hi,
>
>
>
>
>
> I think the NETCONF WG really needs to think about the architecture
>
> it is creating, and the role of proxy servers in network management.
>
>
>
> When we were designing NETCONF (pre-4741) we were told by
>
> knowledgeable operators like Randy Bush that NETCONF MUST NOT
>
> have any Proxy-based management, because it added too much complexity.
>
>
>
>    To date systems built upon YANG models have been missing two
>
>    capabilities:
>
>
>
>    1.  YANG Datastore Mount: Datastores have not been able to proxy
>
>        objects located elsewhere on the same device, or upon a different
>
>        device.  This puts additional burden upon applications which then
>
>        need to find and access multiple locations and which may be on
>
>        remote systems.
>
>
>
>    2.  Eventual Consistency: YANG Datastore implementations have
>
>        typically assumed ACID [1] transaction models.  There is nothing
>
>        inherent in YANG itself which demands ACID transactional
>
>        guarantees.  YANG models can also expose information which might
>
>        be in the process of undergoing convergence.  Since IP networking
>
>        has been designed with convergence in mind, this is a useful
>
>        capability since some types of applications must participate
>
>        where there is dynamically changing state.
>
>
>
> The NETCONF WG should decide first "we need proxy servers" before debatin=
g
> the best way to do that.
>
>
>
> We have been told there are systems that converge very slowly (although
> nobody seems
>
> to know if that means 5 minutes of 5 hours).  All the "get-actual" type o=
f
> proposals
>
> seem to address this issue.  Not sure how YANG Mount addresses the issue,
>
> and how it is related to the other solution proposals.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Tue, Sep 15, 2015 at 8:21 AM, Eric Voit (evoit) 
> wrote:
>
> There was a recent thread on structuring YANG models so that application
> developers might be able to reference alternative local hierarchies/tree
> structures for certain objects.  This thread motivated Alex, Sander, and =
I
> to rework the YANG Mount requirements draft.  v03 is posted at:
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements=
/
>
> This draft has been retitled to "Requirements for mounting of local and
> remote YANG subtrees".  This retitling was done because we have separated
> the thinking on what it takes to Mount objects from remote devices (Peer
> Mount) from what it takes to Mount within the same device (Alias Mount).
>
> We would be interested in your thoughts.
>
> Eric
>
> -----Original Message-----
> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>
> Randy Presuhn  writes:
>
> > Hi -
> >
> > It is with no little amusement that I watch this thread struggling
> > with questions that were solved fairly neatly a quarter century ago in
> > GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like
> > to offer an observation about modeling that might help.
> >
> > The organization of instance data in SNMP is a direct mirror of the
> > "object" definitions.  Simple at first, but quickly becoming baroque
> > as various minds of "multiplexing" are added to compensate for post
> > hoc deficiencies in the index structures.
> >
> > Life is such that once a resource has been modeled, it will be
> > used/re-used/embedded in systems in ways in which its designers
> > couldn't be expected to imagine.  A consequence of this is that if
> > instance naming is completely locked down when the management
> > interface for a resource is first defined (as it is in SNMP) then all
> > sorts of peculiar hacks will be needed to deal with, for example,
> > virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so
> > pervasive that folks seem to overlook that there are other ways to
> > deal with this situation.
> >
> > What GDMO did was to use a separate "NAME BINDING" construct to
> > specify contexts in which instances might show up, allowing instances
> > to be put in places that weren't even imagined when the original class
> > definition was written.  Name bindings could be standardized, or be
> > vendor or even product-specific, allowing the simplicity or complexity
> > of a given system's instance tree to reflect the actual simplicity or
> > complexity of that system, rather than requiring all systems to be
> > structured for the worst case.
>
> How could this be expressed in YANG terms? (I tried to figure it out
> myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT
> Recommendation X.722).
>
> Thanks, Lada
>
> >
> > Yes, separating the specification of instance naming in large part
> > from class definition does have implications for how one does access
> > control, and how clients figure out how to ask a server to create
> > something, but it's not a huge deal - it's just not like VACM, and a
> > whole slew of hacky solutions and "wierd plumbing adapters" (to borrow
> > from Jeff Case) just go away.  Strangely, it makes the job of the
> > initial modeler and of the eventual user much easier.
> >
> > Randy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>

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




On Thu, Sep 17, 2015 at 12:30 PM, Eric Voit (evoit) &=
lt;evoit@cisco.com=
> wrote:











Thanks for your thoughts =
Andy.=C2=A0 I believe the complexities of proxy can be outweighed by the be=
nefits of simplifying life for the application developer in two
 scenarios:


=C2=A0



(1)=C2=A0=C2=A0=C2=A0
Alias Mount: when th=
ere are multiple or context specific exposures of the same object.=C2=A0



Note: I was attempting to capture
some of the idea you were referring to at the end of your =E2=80=9CY=
34 - root node=E2=80=9D post:
http://www.ietf.org/mail-archive/web/netmod/current/ms=
g13260.html =C2=A0=C2=A0=C2=A0It is useful when an application develope=
r doesn=E2=80=99t have to hunt down through dozens of models/trees for the
 few objects they care about.=C2=A0=C2=A0 


=C2=A0



(2)=C2=A0=C2=A0=C2=A0
Peer Mount: when app=
lications need a local representation of objects sitting on a remote device=
.=C2=A0



Note: I know this is more controversial.=C2=A0 But a the Google search o=
f "Mount" on site =3D opendaylight.org gives over 1000 hits relating
 to YANG, Netconf, and Restconf.=C2=A0 Some are finding it useful.=C2=A0 =
=C2=A0


=C2=A0


I agree that the WG needs=
 to decide whether we want to take on some or all of this topic.



=C2=A0
<=
/div>

The landscape has changed a lot=
 since the RFC 3535 timeframe,
in which the only proxy was really=
 SNMP Proxy.

Once we start talking about standardi=
zing the controller layer,
it isn't really proxy anymore (in =
the same sense we thought about it in the 90s).
I look at YANG Mo=
unt, pub/sub, etc. together as a "configurable push model".
=

This could be a much better design than hard-coded polling. =C2=A0 It =
is the kind of
feature we would expect to see, moving from a prop=
rietary controller to
a standardized controller.




Eric

Andy

=C2=A0
<=
/u>


=C2=A0


From: Andy Bierman, September 17, 2015 2:22 PM








Hi,




=C2=A0






=C2=A0






I think the NETCONF WG re=
ally needs to think about the architecture






it is creating, and the r=
ole of proxy servers in network management.






=C2=A0






When we were designing NE=
TCONF (pre-4741) we were told by






knowledgeable operators l=
ike Randy Bush that NETCONF MUST NOT






have any Proxy-based mana=
gement, because it added too much complexity.






=C2=A0






=C2=A0=C2=A0 To date systems built upon YANG models have been missing=
 two


=C2=A0=C2=A0 ca=
pabilities:


=C2=A0


=C2=A0=C2=A0 1.=
=C2=A0 YANG Datastore Mount: Datastores have not been able to proxy<=
u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 objects located elsewhere on the same device, or upon=
 a different


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 device.=C2=A0 This puts additional burden upon applic=
ations which then


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 need to find and access multiple locations and which =
may be on


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 remote systems.


=C2=A0


=C2=A0=C2=A0 2.=
=C2=A0 Eventual Consistency: YANG Datastore implementations have<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 typically assumed ACID [1] transaction models.=C2=A0 =
There is nothing


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 inherent in YANG itself which demands ACID transactio=
nal


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 guarantees.=C2=A0 YANG models can also expose informa=
tion which might


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 be in the process of undergoing convergence.=C2=A0 Si=
nce IP networking


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 has been designed with convergence in mind, this is a=
 useful


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 capability since some types of applications must part=
icipate


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 where there is dynamically changing state.<=
/u>


=C2=A0


The NETCONF WG should dec=
ide first "we need proxy servers" before debating

the best way to do that.






=C2=A0






We have been told there a=
re systems that converge very slowly (although nobody seems





to know if that means 5 m=
inutes of 5 hours).=C2=A0 All the "get-actual" type of proposals<=
u>






seem to address this issu=
e.=C2=A0 Not sure how YANG Mount addresses the issue,






and how it is related to =
the other solution proposals.






=C2=A0






=C2=A0






Andy






=C2=A0






=C2=A0








=C2=A0




On Tue, Sep 15, 2015 at 8=
:21 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:


There was a recent thread=
 on structuring YANG models so that application developers might be able to=
 reference alternative local hierarchies/tree structures for certain object=
s.=C2=A0 This thread motivated Alex, Sander,
 and I to rework the YANG Mount requirements draft.=C2=A0 v03 is posted at:=


http://datatracker.ietf.org/doc/draft-voit-ne=
tmod-peer-mount-requirements/



This draft has been retitled to "Requirements for mounting of local an=
d remote YANG subtrees".=C2=A0 This retitling was done because we have=
 separated the thinking on what it takes to Mount objects from remote devic=
es (Peer Mount) from what it takes to Mount within
 the same device (Alias Mount).



We would be interested in your thoughts.



Eric



-----Original Message-----

From: Ladislav Lhotka, August 31, 2015 11:05 AM



Randy Presuhn <randy_presuhn@mindspring.com> writes:



> Hi -

>

> It is with no little amusement that I watch this thread struggling

> with questions that were solved fairly neatly a quarter century ago in=


> GDMO/CMIP-land.=C2=A0 I'm *not* suggesting we go back there, but w=
ould like

> to offer an observation about modeling that might help.

>

> The organization of instance data in SNMP is a direct mirror of the
> "object" definitions.=C2=A0 Simple at first, but quickly bec=
oming baroque

> as various minds of "multiplexing" are added to compensate f=
or post

> hoc deficiencies in the index structures.

>

> Life is such that once a resource has been modeled, it will be

> used/re-used/embedded in systems in ways in which its designers

> couldn't be expected to imagine.=C2=A0 A consequence of this is th=
at if

> instance naming is completely locked down when the management

> interface for a resource is first defined (as it is in SNMP) then all<=
br>
> sorts of peculiar hacks will be needed to deal with, for example,

> virtual routers.=C2=A0 Unfortunately, an SNMP/SMI-like mindset is so
> pervasive that folks seem to overlook that there are other ways to

> deal with this situation.

>

> What GDMO did was to use a separate "NAME BINDING" construct=
 to

> specify contexts in which instances might show up, allowing instances<=
br>
> to be put in places that weren't even imagined when the original c=
lass

> definition was written.=C2=A0 Name bindings could be standardized, or =
be

> vendor or even product-specific, allowing the simplicity or complexity=


> of a given system's instance tree to reflect the actual simplicity=
 or

> complexity of that system, rather than requiring all systems to be

> structured for the worst case.



How could this be expressed in YANG terms? (I tried to figure it out myself=
 but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recom=
mendation X.722).



Thanks, Lada



>

> Yes, separating the specification of instance naming in large part

> from class definition does have implications for how one does access
> control, and how clients figure out how to ask a server to create

> something, but it's not a huge deal - it's just not like VACM,=
 and a

> whole slew of hacky solutions and "wierd plumbing adapters" =
(to borrow

> from Jeff Case) just go away.=C2=A0 Strangely, it makes the job of the=


> initial modeler and of the eventual user much easier.

>

> Randy

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C



_______________________________________________

netmod mailing list

netmod@ietf.org
=
https://www.ietf.org/mailman/listinfo/netmod




=C2=A0












--089e0160b794a82dc6051ff6b146--


From nobody Thu Sep 17 13:32:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1181A0094 for ; Thu, 17 Sep 2015 13:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1X7dvcmshGx for ; Thu, 17 Sep 2015 13:32:10 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 1A75B1A0074 for ; Thu, 17 Sep 2015 13:32:10 -0700 (PDT)
Received: by padhk3 with SMTP id hk3so28494916pad.3 for ; Thu, 17 Sep 2015 13:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=b3NKkd91voOWho8Phc1wfVhqzwnWQynycXs7tGjMBCg=; b=z2QQ5FRpvA8V1gT/dPzIV5La/bc/KruiDt8u3Mtl7my+iuC+BvyO5j1u8M9TSZ3bjG W+3GuV86aEDKie77/QIzSbmSJMHYZxPa1n1lyI5yqrGbCR7lCLWT7zSz6l7FZognEEit IpC0OUMtIo2uKu6bDW44jZt3BPHdUHpcx+ov/DuhjSx+bSaDM1w2jCne+DwlYvAjQlua g0ucebOc+GysBH9xLz76vfUmttXWK6OZ6kEgTo14X24onxfc/TSM2HsQSf7P5h4qIC+b g3mVmzlX+tFcsHgKwj9tYud37wiJzQH6PWF9WWcjCzPbkpsI2XeUUOywMTI/NPIgVcKd VK3Q==
X-Received: by 10.66.136.102 with SMTP id pz6mr2146473pab.52.1442521929686; Thu, 17 Sep 2015 13:32:09 -0700 (PDT)
Received: from ?IPv6:2001:420:302:1330:205f:6849:b753:4a7b? ([2001:420:302:1330:205f:6849:b753:4a7b]) by smtp.gmail.com with ESMTPSA id yt9sm4999698pac.32.2015.09.17.13.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Sep 2015 13:32:08 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Sep 2015 13:32:17 -0700
Message-Id: <65BE9D62-8319-4E2E-83B7-6624C6DC027D@gmail.com>
To: NETMOD Working Group 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: David Law 
Subject: [netmod] Design team for IEEE 802.3 YANG model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 20:32:11 -0000

[To be cross posted to IEEE mailing list]

We are seeking qualified individuals to form a design team to work on a =
experimental RFC for a YANG model based for IEEE 802.3 standard. =
Qualified individuals should have some knowledge of both the 802.3 =
standard and YANG.

The design team will work virtually, and no travel is required. The work =
in the form of an experimental I-D will be discussed on this mailing =
list but the result of it will be a submission to IEEE and ultimately =
the work will be transferred to IEEE, when they are ready to host the =
work, for it to be finalized there. Expect the initial work of coming up =
with a initial prototype to last 3-6 months. You can choose to follow =
the work to IEEE.

If you are interested in being part of the design team, please unicast =
me.

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Thu Sep 17 14:18:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EDE1A06FD; Thu, 17 Sep 2015 14:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6wIJeHDptKG; Thu, 17 Sep 2015 14:17:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7A81A019B; Thu, 17 Sep 2015 14:17:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IESG Secretary 
To: "IETF Announcement List" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150917211756.18187.88980.idtracker@ietfa.amsl.com>
Date: Thu, 17 Sep 2015 14:17:56 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] NETMOD WG Virtual Interim Meeting: October 1, 2015
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Sep 2015 21:17:58 -0000

The NETCONF Data Modeling Language (netmod) Working Group will hold a virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am PDT; 2pm GMT).

The title is “Openconfig Solutions Discussion (continued)”.

The WebEx is:

Meeting number:640 686 530
Meeting password:1234
Audio connection:
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 640 686 530
Meeting link: https://ietf.webex.com/ietf/j.php?MTID=mf12aa8d28a159614cb415f2f32dcbebf


From nobody Fri Sep 18 07:22:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4461B2C84 for ; Fri, 18 Sep 2015 07:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaBrKO68ztWu for ; Fri, 18 Sep 2015 07:22:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 180021B2CBB for ; Fri, 18 Sep 2015 07:22:27 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 159541AE049A; Fri, 18 Sep 2015 16:22:26 +0200 (CEST)
Date: Fri, 18 Sep 2015 16:22:28 +0200 (CEST)
Message-Id: <20150918.162228.662532849145578118.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20150917.123947.1589992296795354113.mbj@tail-f.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: netmod@ietf.org
Subject: Re: [netmod] Y60 - coexistence with YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Sep 2015 14:22:30 -0000

Andy Bierman  wrote:
> On Thu, Sep 17, 2015 at 3:39 AM, Martin Bjorklund  wrote:
> 
> > Ladislav Lhotka  wrote:
> > >
> > > > On 15 Sep 2015, at 15:54, Martin Bjorklund  wrote:
> > > >
> > > > Juergen Schoenwaelder  wrote:
> > > >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > > >>>
> > > >>> Sure.  The use case is for example servers that implement ietf-ip
> > > >>> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > > >>> update ietf-interfaces to 1.1.  It should still be ok for a server to
> > > >>> implement ietf-ip with the new ietf-interfaces.
> > > >>>
> > > >>
> > > >> Is the confusion is between implements and imports here? The module
> > > >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> > > >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> > > >> this not going to work?
> > > >>
> > > >>>> Would it not work if an import of ietf-interfaces from a
> > > >>>> version 1 module simply resolves to the latest ietf-interfaces
> > > >>>> revision that is still version 1?
> > > >>>
> > > >>> But that would mean either that a server is stuck implementing
> > version
> > > >>> 1 modules, or that the server must implement both the version 1 and
> > > >>> version 1.1 module - and we have already said that this isn't
> > > >>> possible.
> > > >>
> > > >> But this seems only true if import === implemented.
> > > >>
> > > >>> A set of simpler rules would be:
> > > >>>
> > > >>>   A YANG version 1.1 module MUST NOT include a version 1 module.
> > > >>>   A YANG version 1 module MUST NOT include a version 1.1 module.
> > > >>>
> > > >>>   A YANG version 1.1 (sub)module MAY import a version 1 module.
> > > >>>   A YANG version 1 (sub)module MAY import a version 1.1 module.
> > > >>
> > > >> It is the last one we are discussing, no? I am trying again: Why is
> > > >> the MAY needed? Why is it not sufficient for a version 1 module to
> > > >> work with an import for (the latest) version 1 module?
> > > >
> > > > How about this:
> > > >
> > > > -------------------
> > > >
> > > > * Coexistence with YANG version 1 @coexistence@
> > > >
> > > > A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> > > > and a YANG version 1 module MUST NOT include a YANG version 1.1
> > > > submodule.
> > >
> > > Does this apply only to include-by-revision? Because otherwise how can
> > > we tell?
> >
> > It is supposed to apply to both; if it is include by revision it is
> > obvious, but for include w/o revision it means that any tool (server,
> > client, ...) MUST treat version mismatch as an error.
> >
> 
> This is still a problem:
> 
>     A YANG version 1 (sub)module MAY import a version 1.1 module.

But my proposed text doesn't say that.  It was rewritten to:

  If a YANG version 1 module A imports module B without revision, and
  module B is updated to YANG version 1.1, a server MAY implement both
  these modules at the same time.  In such cases, a NETCONF server
  MUST advertise both modules using the rules defined in ^announce^,
  and SHOULD advertise module A and the latest revision of module B
  that is specified with YANG version 1 according to the rules defined
  in ^RFC6020^.

> This assumes the tools understand YANG 1.1.
> YANG 1 says it is undefined what happens if the YANG 1 compiler
> finds a yang-version value other than '1'.
> 
> You want to make a distinction between a YANG 1.1 capable tool
> and a YANG 1.0 capable tool. Obviously a YANG 1 capable tool
> is not required to EVER accept a YANG 1.1 module.

Agreed.

> So when the YANG author imports a YANG 1.1 module from a YANG 1 module
> and no revision date is given, there really are no rules that YANG 1.1 can
> specify
> that would apply to a YANG 1 tool.  There is no way to enforce any
> interoperability
> requirements wrt/ the revision of the imported module that is used in this
> case.

It is not that the version 1 module author imports a 1.1 module w/o
revision; the use case is an implementation that MAY *implement* both.


/martin


From nobody Fri Sep 18 14:00:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472CD1B359E for ; Fri, 18 Sep 2015 13:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6pdsu0oDBl3 for ; Fri, 18 Sep 2015 13:59:55 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A071A8A8B for ; Fri, 18 Sep 2015 13:59:54 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Fri, 18 Sep 2015 20:59:39 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Fri, 18 Sep 2015 20:59:39 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: closing issues on opstate-reqs
Thread-Index: AQHQ8lTudcsRmLdqBkSwXlz41djcyQ==
Date: Fri, 18 Sep 2015 20:59:38 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:aYhCe6quJfzWUkdLwsC5WyyxPJt5Zcvo9BoMAmjVbq6rvSB+wXpnEVKIRZcVwPhqBgiEAFeYe/ydPLtpcfpHtrwkfaq1OoW3iLhp+xtlHClUguTb2OAkIUKuM8HVxgCf32z8KNk2dcmaX7lNz0SRxQ==; 24:v+pmSX8HNddckFzPSILvHjXcsl0BykonDcXP7/npfVnQND+bMjmt4mxn5kNZS8U1gjy7/HkYOw83LkZrOiyooJKEpbChbteOsp0NQuhNFHo=; 20:IRNxibBpZP+mFhqy7myRLDWTbGOgzSjg2qffVyrJDmTab7KpvkUaqheSYbuYn6vXIkIExcHgqo7uXlH1GDYxbw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520078)(5005006)(520075)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0703B549E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(69234005)(199003)(189002)(164054003)(102836002)(92566002)(2351001)(11100500001)(5007970100001)(50986999)(122556002)(4001540100001)(189998001)(5001830100001)(62966003)(16236675004)(229853001)(4001350100001)(68736005)(10400500002)(19580395003)(83506001)(77156002)(54356999)(5002640100001)(5001960100002)(97736004)(81156007)(5004730100002)(107886002)(110136002)(36756003)(66066001)(19617315012)(2900100001)(5001860100001)(450100001)(105586002)(101416001)(106356001)(87936001)(15975445007)(106116001)(40100003)(99286002)(46102003)(86362001)(2501003)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D221F374DDFF3kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2015 20:59:38.9192 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [netmod] closing issues on opstate-reqs
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Sep 2015 20:59:59 -0000

--_000_D221F374DDFF3kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Seven issues were filed against draft-chairs-netmod-opstate-reqs-00:

https://github.com/netmod-wg/opstate-reqs/issues


These issues are all currently in the NEW state.  FYI, all the issue tracki=
ng states are described here:

https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-track=
ing


Immediately I plan to start a thread to track some of these issues to closu=
re.  I will start with an easy issue so we can see how it goes.

Thanks,
Kent


--_000_D221F374DDFF3kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <1B518DE9F168624AA7C671FC68E63362@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














Seven issues were filed against draft-chairs-netmod-opstate-reqs-00:



















These issues are all currentl=
y in the NEW state.  FYI, all the issue tracking states are described =
here:


















Immediately I plan to start a thread to track some of these issues to =
closure.  I will start with an easy issue so we can see how it goes.






Thanks,


Kent









--_000_D221F374DDFF3kwatsenjunipernet_--


From nobody Fri Sep 18 14:56:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFAA1B3624 for ; Fri, 18 Sep 2015 14:56:35 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SsamzNo459v for ; Fri, 18 Sep 2015 14:56:28 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84311B3621 for ; Fri, 18 Sep 2015 14:56:27 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.268.17; Fri, 18 Sep 2015 21:56:09 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Fri, 18 Sep 2015 21:56:09 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: opstate-reqs #7: Why limit scope to just IETF-defined modules
Thread-Index: AQHQ8lzThTAvqjhhWUW821rJF43C8w==
Date: Fri, 18 Sep 2015 21:56:09 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:JJVmFIIbA2igTeYHaDEi2i3t1zJgFu5us+ZsNCGu6sB9N6zmm+ltg3OD8LbR45JsMu2dzP3ytldiG28aWkfTSiSyKdyD64IPGv1L44lq3fC839vEUp6q5l2MNZWBbC7FnCK3LsuWVS9Wu2FuQ0N9gg==; 24:IQ79ecY6iNUyQheWA2XcusNt4/Cui+iXITQgxsl+smzLX6fI6N/1yJUV/dsQpWIdPh2IB02YJVTGgFFkiTZqhFLmfujMO0BUh8vtdlXIWFg=; 20:yuF9qw9qWz9Kw0/TiQdIT4r4b1T/IxS0F1ENAj6HG7ckLK4yhEZ+vZJBAi/soBt5QuaI3aNs18IavhJ6288R5A==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(520078)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 0703B549E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(64706001)(110136002)(11100500001)(15975445007)(4001540100001)(2501003)(68736005)(107886002)(81156007)(10400500002)(5002640100001)(46102003)(87936001)(92566002)(83506001)(575784001)(102836002)(101416001)(2900100001)(5001960100002)(450100001)(4001350100001)(66066001)(5007970100001)(77156002)(106356001)(189998001)(62966003)(122556002)(5001830100001)(40100003)(99286002)(2351001)(229853001)(54356999)(105586002)(97736004)(86362001)(5001860100001)(36756003)(19580395003)(106116001)(5004730100002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8C8C6A282BAC54448814071A666D3713@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2015 21:56:09.3347 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Sep 2015 21:56:35 -0000

Regarding https://github.com/netmod-wg/opstate-reqs/issues/7


  Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
            others are now defining YANG modules?

  Benoit> Good point. We need to provide guidance for the other SDOs.


Current text says:

   7.  Ability for distinct modules to leverage a common model-structure
       A.  Scope is limited to IETF-defined modules
       B.  Multiple domain-specific trees are okay
       C.  Multiple namespaces are okay



Background:

  I pulled 7A from Andy's message here:

   =20
https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

  and put a stake in the ground so that, if nothing else, it could
  be discussed...and here we are!

  FWIW, I wrote 7A this way because I didn't see how it can be
  enforced outside of the IETF.  But maybe that doesn't matter?
  Of course, we can have 6087bis guidance for other SDOs, but
  I didn't put that in the text.


Thoughts on how the text should be updated?


PS: Please Reply-All to the list rather than post comments to the GitHub
issue tracker.


Thanks,
Kent


From nobody Sun Sep 20 00:26:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C631B3F78 for ; Sun, 20 Sep 2015 00:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etxCRHuI_u5D for ; Sun, 20 Sep 2015 00:26:40 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CF21B3F77 for ; Sun, 20 Sep 2015 00:26:40 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AeAwA3Q8ZV/xUHmMZbGQEBglQsVGkGqW4GkzYJggSFeQKBJjgUAQEBAQEBAYEKhCMBAQEBAxIoNBcEAgEIDQEDBAEBCxQJBzIUCQgCBAESCBqIDAEMrGmgOgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhh+FMoQwASc4BoMSgRQFlQsBhQGJKoQlgwuRBBcPg31vgQUBHyOBBAEBAQ
X-IPAS-Result: A2AeAwA3Q8ZV/xUHmMZbGQEBglQsVGkGqW4GkzYJggSFeQKBJjgUAQEBAQEBAYEKhCMBAQEBAxIoNBcEAgEIDQEDBAEBCxQJBzIUCQgCBAESCBqIDAEMrGmgOgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhh+FMoQwASc4BoMSgRQFlQsBhQGJKoQlgwuRBBcPg31vgQUBHyOBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="142532684"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Sep 2015 03:26:38 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 20 Sep 2015 03:26:38 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Sun, 20 Sep 2015 09:26:36 +0200
From: "Romascanu, Dan (Dan)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
Thread-Index: AQHQ8lzThTAvqjhhWUW821rJF43C855FBW5w
Date: Sun, 20 Sep 2015 07:26:35 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CB28640@AZ-FFEXMB04.global.avaya.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Sep 2015 07:26:42 -0000

Hi,

There is a difference between providing guidance to other SDOs or organizat=
ions, and writing YANG modules for them. The role of the activity in the IE=
TF should be to provide guidance, partly in informational RFCs, partly in t=
he IETF YANG modules which can be used as design examples. We can also prov=
ide advice and review modules written out of the IETF as we do in the hacka=
thons. We should not IMO write YANG modules for other SDOs or models for no=
n-IETF protocols.=20

Regards,

Dan

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Saturday, September 19, 2015 12:56 AM
> To: netmod@ietf.org
> Subject: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined
> modules
>=20
>=20
> Regarding https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__github.com_netmod-2Dwg_opstate-
> 2Dreqs_issues_7&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3Dyi1uYR3VJD4JrRa5l8jqBkjtxrsJuHg
> 5dcsU1w-nzZQ&s=3Dkj8v5eC_6IVKqyfqvnd-CDGFXN97L8I02gRhUeBY278&e=3D
>=20
>=20
>   Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>             others are now defining YANG modules?
>=20
>   Benoit> Good point. We need to provide guidance for the other SDOs.
>=20
>=20
> Current text says:
>=20
>    7.  Ability for distinct modules to leverage a common model-structure
>        A.  Scope is limited to IETF-defined modules
>        B.  Multiple domain-specific trees are okay
>        C.  Multiple namespaces are okay
>=20
>=20
>=20
> Background:
>=20
>   I pulled 7A from Andy's message here:
>=20
>=20
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__mailarchive.ietf.org_arch_msg_netmod_I6clHE2665C40taRZHi0CKLD46U
> &d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfu
> cBXRucPvdrphpBsFA&m=3Dyi1uYR3VJD4JrRa5l8jqBkjtxrsJuHg5dcsU1w-
> nzZQ&s=3DRbIG290qfYTtkdYRghpbUXmzbJCGclTOYnPhBC1o2nk&e=3D
>=20
>   and put a stake in the ground so that, if nothing else, it could
>   be discussed...and here we are!
>=20
>   FWIW, I wrote 7A this way because I didn't see how it can be
>   enforced outside of the IETF.  But maybe that doesn't matter?
>   Of course, we can have 6087bis guidance for other SDOs, but
>   I didn't put that in the text.
>=20
>=20
> Thoughts on how the text should be updated?
>=20
>=20
> PS: Please Reply-All to the list rather than post comments to the GitHub =
issue
> tracker.
>=20
>=20
> Thanks,
> Kent
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DBQICAg&c=3DBFpWQw8bsuK
> pl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3Dyi1uY
> R3VJD4JrRa5l8jqBkjtxrsJuHg5dcsU1w-
> nzZQ&s=3DaLfNVEmox9KUVrZVBBSrrpoW6R3mScbV6TfvudUesa0&e=3D


From nobody Sun Sep 20 13:24:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3091B2BFB for ; Sun, 20 Sep 2015 13:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.51
X-Spam-Level: 
X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7A3GJ1g6AOO for ; Sun, 20 Sep 2015 13:24:03 -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 5663B1A6F53 for ; Sun, 20 Sep 2015 13:24:03 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 80695B5DA04BA for ; Sun, 20 Sep 2015 20:23:56 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t8KKNxmH007541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 20 Sep 2015 20:23:59 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sun, 20 Sep 2015 16:23:59 -0400
From: "Sterne, Jason (Jason)" 
To: "netmod@ietf.org" 
Thread-Topic: ACL Model 03 - ACL Type should be mandatory
Thread-Index: AQHQnK3+1WRBFqzUuEu69dSP2qQCIp3gdK+QgAK8bbCAY1hsMA==
Date: Sun, 20 Sep 2015 20:23:58 +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.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Sep 2015 20:24:06 -0000

SGkgYWxsLA0KDQpJIG1ldCB3aXRoIERlYW4gYXQgSUVURjkzIGFuZCB3ZSBhZ3JlZWQgdGhhdCBJ
IHNob3VsZCBzZW5kIGEgc3BlY2lmaWMgcHJvcG9zYWwgdG8gdGhlIGxpc3QgZm9yIHRoaXMuICBI
ZXJlIGl0IGlzOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KUmVwbGFjZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQgc25pcHBldHMgZnJvbSBt
b2RlbC0wMzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQoNCmxpc3QgYWNsIHsNCiAga2V5ICJhY2wtbmFtZSI7DQogIC4uLg0KfQ0KDQpsZWFm
IGFjbC10eXBlIHsNCiAgdHlwZSBhY2wtdHlwZTsNCiAgZGVzY3JpcHRpb24NCiAgICAiSXQgaXMg
cmVjb21tZW5kZWQgdG8gaGF2ZSBhbiBBY2Nlc3MgQ29udHJvbCBMaXN0IHdpdGgNCiAgICAgdW5p
Zm9ybSBhY2Nlc3MgbGlzdCBlbnRyaWVzLCBhbGwgb2YgdGhlIHNhbWUgdHlwZS4gV2hlbg0KICAg
ICB0aGlzIHR5cGUgaXMgbm90IGV4cGxpY2l0bHkgc3BlY2lmaWVkLCBpZiB2ZW5kb3INCiAgICAg
aW1wbGVtZW50YXRpb24gcGVybWl0cywgdGhlIGFjY2VzcyBjb250cm9sIGVudHJpZXMNCiAgICAg
aW4gdGhlIGxpc3QgY2FuIGJlIG1peGVkLA0KICAgICBieSBjb250YWluaW5nIEwyLCBMMyBhbmQg
TDQgZW50cmllcyI7DQp9DQoNCmlkZW50aXR5IGlwLWFjbCB7DQogIGJhc2UgYWNsOmFjbC1iYXNl
Ow0KICBkZXNjcmlwdGlvbg0KICAgICJJUCBBY2Nlc3MgQ29udHJvbCBMaXN0IGlzIGEgY29tbW9u
IG5hbWUgZm9yIGxpc3RzIHRoYXQgY29udGFpbg0KICAgICBsYXllciAzIGFuZC9vciBsYXllciA0
IG1hdGNoIGNvbmRpdGlvbnMuIjsNCn0NCg0KaWRlbnRpdHkgZXRoLWFjbCB7DQogIGJhc2UgYWNs
OmFjbC1iYXNlOw0KICBkZXNjcmlwdGlvbg0KICAgICJFdGhlcm5ldCBBY2Nlc3MgQ29udHJvbCBM
aXN0IGlzIG5hbWUgZm9yIGxheWVyIDIgRXRoZXJuZXQNCiAgICAgdGVjaG5vbG9neSBBY2Nlc3Mg
Q29udHJvbCBMaXN0IHR5cGVzLCBsaWtlIDEwLzEwMC8xMDAwYmFzZVQgb3INCiAgICAgV2lGaSBB
Y2Nlc3MgQ29udHJvbCBMaXN0IjsNCn0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0gIA0Kd2l0aCB0
aGUgZm9sbG93aW5nOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KbGlzdCBhY2wgew0KICBrZXkg
ImFjbC10eXBlIGFjbC1uYW1lIjsNCiAgLi4uDQp9DQoobm90ZSB0aGlzIGlzIHNpbWlsYXIgY29u
c3RydWN0IHRvIHRoZSByb3V0aW5nIG1vZGVsOiANCiAgIGxpc3Qgcm91dGluZy1wcm90b2NvbCB7
a2V5ICJ0eXBlIG5hbWUiLi4uICkNCg0KbGVhZiBhY2wtdHlwZSB7DQogIHR5cGUgYWNsLXR5cGU7
DQogIGRlc2NyaXB0aW9uDQogICAgIlR5cGUgb2YgYWNjZXNzIGNvbnRyb2wgbGlzdC4gSW5kaWNh
dGVzIHRoZSBwcmltYXJ5IGludGVuZGVkDQogICAgIHR5cGUgb2YgbWF0Y2ggY3JpdGVyaWEgKGUu
Zy4gZXRoZXJuZXQsIElQdjQsIElQdjYsIG1peGVkLCBldGMpIA0KICAgICB1c2VkIGluIHRoZSBs
aXN0IGluc3RhbmNlLiI7DQp9DQoNCmlkZW50aXR5IGlwdjQtYWNsIHsNCiAgYmFzZSBhY2w6YWNs
LWJhc2U7DQogIGRlc2NyaXB0aW9uIA0KICAgICJBQ0wgdGhhdCBwcmltYXJpbHkgbWF0Y2hlcyBv
biBmaWVsZHMgZnJvbSB0aGUgSVB2NCBoZWFkZXINCiAgICAoZS5nLiBJUHY0IGRlc3RpbmF0aW9u
IGFkZHJlc3MpIGFuZCBsYXllciA0IGhlYWRlcnMgKGUuZy4gVENQIGRlc3RpbmF0aW9uDQogICAg
cG9ydCkuICBBbiBhY2wgb2YgdHlwZSBpcHY0LWFjbCBkb2VzIG5vdCBjb250YWluIG1hdGNoZXMg
b24gZmllbGRzIGluDQogICAgdGhlIGV0aGVybmV0IGhlYWRlciBvciB0aGUgSVB2NiBoZWFkZXIu
IjsNCn0NCg0KaWRlbnRpdHkgaXB2Ni1hY2wgew0KICBiYXNlIGFjbDphY2wtYmFzZTsNCiAgZGVz
Y3JpcHRpb24NCiAgICAiQUNMIHRoYXQgcHJpbWFyaWx5IG1hdGNoZXMgb24gZmllbGRzIGZyb20g
dGhlIElQdjYgaGVhZGVyDQogICAgKGUuZy4gSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzKSBhbmQg
bGF5ZXIgNCBoZWFkZXJzIChlLmcuIFRDUCBkZXN0aW5hdGlvbg0KICAgIHBvcnQpLiBBbiBhY2wg
b2YgdHlwZSBpcHY2LWFjbCBkb2VzIG5vdCBjb250YWluIG1hdGNoZXMgb24gZmllbGRzIGluDQog
ICAgdGhlIGV0aGVybmV0IGhlYWRlciBvciB0aGUgSVB2NCBoZWFkZXIuIjsNCn0NCiAgDQppZGVu
dGl0eSBldGgtYWNsIHsNCiAgYmFzZSBhY2w6YWNsLWJhc2U7DQogIGRlc2NyaXB0aW9uDQogICAg
IkFDTCB0aGF0IHByaW1hcmlseSBtYXRjaGVzIG9uIGZpZWxkcyBpbiB0aGUgZXRoZXJuZXQgaGVh
ZGVyLg0KICAgICBBbiBhY2wgb2YgdHlwZSBldGgtYWNsIGRvZXMgbm90IGNvbnRhaW4gbWF0Y2hl
cyBvbiBmaWVsZHMgaW4NCiAgICAgdGhlIElQdjQgaGVhZGVyLCBJUHY2IGhlYWRlciBvciBsYXll
ciA0IGhlYWRlcnMuIjsNCn0NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NClBvdGVudGlhbCBmdXR1cmUgYXVnbWVudGF0aW9uIG9mIHR5cGU6DQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkZvciBmdXR1cmUgbWl4ZWQgdHlwZXMg
dmVuZG9ycyAob3IgdGhlIGlldGYpIGNvdWxkIGF1Z21lbnQgdGhlIGFjbC10eXBlLWJhc2Ugd2l0
aCB0eXBlcyBsaWtlIHRoZSBmb2xsb3dpbmc6DQoNCiAgaWRlbnRpdHkgbWl4ZWQtbDMtYWNsIHsN
CiAgICBiYXNlICJhY2Nlc3MtY29udHJvbC1saXN0OmFjbC10eXBlLWJhc2UiOw0KICAgIGRlc2Ny
aXB0aW9uICJBQ0wgdGhhdCBjb250YWlucyBhIG1peCBvZiBlbnRyaWVzIHRoYXQgcHJpbWFyaWx5
IG1hdGNoIG9uIGZpZWxkcyANCiAgICAgIGluIElQdjQgaGVhZGVycyBhbmQgZW50cmllcyB0aGF0
IHByaW1hcmlseSBtYXRjaCBvbiBmaWVsZHMgaW4gSVB2NiBoZWFkZXJzLg0KICAgICAgTWF0Y2hp
bmcgb24gbGF5ZXIgNCBoZWFkZXIgZmllbGRzIG1heSBhbHNvIGV4aXN0IGluIHRoZSBsaXN0Lg0K
ICAgICAgQW4gYWNsIG9mIHR5cGUgbWl4ZWQtbDMtYWNsIGRvZXMgbm90IGNvbnRhaW4gbWF0Y2hl
cyBvbiBmaWVsZHMgaW4NCiAgICAgIHRoZSBldGhlcm5ldCBoZWFkZXIuIjsNCiAgfQ0KIA0KICBp
ZGVudGl0eSBtaXhlZC1sMi1sMy1hY2wgew0KICAgIGJhc2UgImFjY2Vzcy1jb250cm9sLWxpc3Q6
YWNsLXR5cGUtYmFzZSI7DQogICAgZGVzY3JpcHRpb24gIkFDTCB0aGF0IGNvbnRhaW5zIGEgbWl4
IG9mIGVudHJpZXMgdGhhdCBwcmltYXJpbHkgbWF0Y2ggb24gZmllbGRzIA0KICAgICAgaW4gZXRo
ZXJuZXQgaGVhZGVycywgZW50cmllcyB0aGF0IHByaW1hcmlseSBtYXRjaCBvbiBmaWVsZHMgaW4g
SVB2NCBoZWFkZXJzLA0KICAgICAgYW5kIGVudHJpZXMgdGhhdCBwcmltYXJpbHkgbWF0Y2ggb24g
ZmllbGRzIGluIElQdjYgaGVhZGVycy4gIE1hdGNoaW5nIG9uIGxheWVyIDQgDQogICAgICBoZWFk
ZXIgZmllbGRzIG1heSBhbHNvIGV4aXN0IGluIHRoZSBsaXN0LiI7DQogIH0NCg0KUmVnYXJkcywN
Ckphc29uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVybmUsIEphc29u
IChKYXNvbikgDQpTZW50OiBTdW5kYXksIEp1bHkgMTksIDIwMTUgMTI6NTgNClRvOiBTdGVybmUs
IEphc29uIChKYXNvbik7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IEFDTCBNb2RlbCAw
MyAtIEFDTCBUeXBlIHNob3VsZCBiZSBtYW5kYXRvcnkNCg0KR2l2ZW4gdGhlIGRhdGEgbW9kZWxz
IGJlbG93IGluIHNvbWUgb2YgdGhlIG1ham9yIGltcGxlbWVudGF0aW9ucyBpdCBhbHNvIHNlZW1z
IGxpa2Ugd2Ugc2hvdWxkIGFsc28gKHJlLSljb25zaWRlciBoYXZpbmcgdGhlICd0eXBlJyBhcyBw
YXJ0IG9mIHRoZSBBQ0wga2V5ICgidHlwZSBuYW1lIikuICANCg0KSW4gYWxsIHRob3NlIGNhc2Vz
IGJlbG93IGl0IGxvb2tzIGxpa2UgYW4gb3BlcmF0b3IgY2FuIGN1cnJlbnRseSBjb25maWd1cmUg
dHdvIGRpZmZlcmVudCBBQ0xzIChlLmcuIGFuIElQdjQgYW5kIGFuIElQdjYgQUNMKSB3aXRoIHRo
ZSBzYW1lIG5hbWUvaWQgdmlhIHRoZWlyIENMSSAoZS5nLiBhIHY0IEFDTCBjYWxsZWQgIm15LWFj
bCIgYW5kIGEgdjYgQUNMIGNhbGxlZCAibXktYWNsIikuICANCg0KSG93IHdvdWxkIHRob3NlIGxp
c3RzIGJlIHJlYWQgaW4gYSA8Z2V0LWNvbmZpZz4gdmlhIHRoZSBpZXRmIEFDTCBZQU5HIG1vZHVs
ZXMgPyAgV2UnZCBhbGwgaGF2ZSB0byBtYW5nbGUgdGhlIG5hbWVzIGFuZCByZXNlcnZlIHNwZWNp
YWwgbmFtZXMvcHJlZml4LWNoYXJzIChlLmcuIF9pcHY0LW15LWFjbCBhbmQgX2lwdjYtbXktYWNs
KSB0byBzZW5kIHRoZW0gYmFjayB0byBhIE5DIGNsaWVudC4gIEknbSBub3Qgc3VyZSBpZiB0aGVy
ZSBpcyBtdWNoIG9mIGEgZGlzYWR2YW50YWdlIG9mIGp1c3QgaGF2aW5nIHR5cGUgaW4gdGhlIGtl
eSAoYXNzdW1pbmcgaXQgaXMgbWFuZGF0b3J5IGFzIGFkdm9jYXRlZCBiZWxvdykuDQoNCkkgYWxz
byBsb29rZWQgYnJpZWZseSBhdCB0aGUgQnJvY2FkZSBZQU5HIG1vZGVscyBvbiBnaXRodWIuICBJ
dCBsb29rcyBsaWtlIHRoZXkgaGF2ZSBtdWx0aXBsZSBsaXN0cyBhcyB3ZWxsIGZvciB2NCB2cyB2
NiAoYW5kIGV2ZW4gb3IgZGlmZmVyZW50IHR5cGVzIG9mIG5vcm1hbCB2cyBleHRlbmRlZCBBQ0xz
IC0gdGhhdCBjb3VsZCBiZSBoYW5kbGVkIGJ5IGF1Z21lbnRpbmcgdGhlIHR5cGUgd2l0aCBhICd2
NC1leHRlbmRlZCcgdHlwZSBmb3IgZXhhbXBsZSkuDQoNClJlZ2FyZHMsDQpKYXNvbg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVybmUsIEphc29uIChKYXNvbikNClNlbnQ6IEZy
aWRheSwgSnVseSAxNywgMjAxNSAyMzozNQ0KVG86IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDog
W25ldG1vZF0gQUNMIE1vZGVsIDAzIC0gQUNMIFR5cGUgc2hvdWxkIGJlIG1hbmRhdG9yeQ0KDQpI
aSBhbGwsDQoNCkkgdGhpbmsgd2UgbmVlZCB0byByZXZpc2l0IHRoaXMgZGlzY3Vzc2lvbiBhYm91
dCBob3cgQUNMIHR5cGUgd29ya3MgaW4gZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTAzLg0K
DQpJdCBzaG91bGQgYmUgbWFuZGF0b3J5IGFuZCB3ZSBzaG91bGQgc2VwYXJhdGUgdjQgZnJvbSB2
Ni4gIFZlbmRvcnMgY2FuIGF1Z21lbnQgZm9yIGZ1dHVyZSAibWl4ZWQiIHR5cGVzIChvciBtYXli
ZSB3ZSBzaG91bGQgbWFrZSBhbiBpZi1mZWF0dXJlIGZvciBhICJtaXhlZCIgdHlwZSBub3cgdGhh
dCBtZWFucyAiYW55dGhpbmcgZ29lcyIpLg0KDQpXZSBzaG91bGQgZm9sbG93IGV4aXN0aW5nIGNv
bW1vbiBpbXBsZW1lbnRhdGlvbnMgZm9yIHRoaXMgaW4gb3JkZXIgdG8gZm9zdGVyIGJldHRlciBh
ZG9wdGlvbi4NCg0KQ2lzY28gSU9TLVhSIGhhcyBzZXBhcmF0ZSBsaXN0cyBmb3IgaXB2NCBhbmQg
aXB2NiBhbmQgcGFydCBvZiBzcGVjaWZ5aW5nIHRoZSBsaXN0Og0KaXB2NCBhY2Nlc3MtbGlzdCA8
bmFtZT4NCmlwdjYgYWNjZXNzLWxpc3QgPG5hbWU+DQogDQpKdW5vcyBoYXMgc2VwYXJhdGUgbGlz
dHMgZm9yIHY0IGFuZCB2NjoNCmFjY2Vzcy1saXN0IDx4eXo+IC4uLg0KaXB2NiBhY2Nlc3MtbGlz
dCA8YWJjPiAuLi4NCiANCkFMVSBTUiBPUyBoYXMgc2VwYXJhdGUgbGlzdHMgZm9yIHY0LCB2NiBh
bmQgbWFjOg0KY29uZmlnIGZpbHRlciBpcC1maWx0ZXIgPGFiYz4NCmNvbmZpZyBmaWx0ZXIgaXB2
Ni1maWx0ZXIgPGRlZj4NCmNvbmZpZyBmaWx0ZXIgbWFjLWZpbHRlciA8Z2hpPg0KIA0KSHVhd2Vp
IHVzZXMgc2VwYXJhdGUgbGlzdHMgZm9yIHY0IGFuZCB2NjoNCmFjbCBudW1iZXIgMzAwMA0KYWNs
IGlwdjYgbnVtYmVyIDMwMDANCg0KUGxlYXNlIHNlZSBiZWxvdyB3aXRoIFs+PkpUU10NCg0KUmVn
YXJkcywNCkphc29uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRtb2Qg
W21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1h
bg0KU2VudDogTW9uZGF5LCBKdW5lIDAxLCAyMDE1IDE3OjAwDQpUbzogTmFiaWwgTWljaHJhZg0K
Q2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIG1hbmRhdG9yeSBBQ0wg
dHlwZSAod2FzICJjb21tZW50cyBvbiBhY2wtbW9kZWwtMDIiKQ0KDQpIaSwNCg0KDQpUaGF0IGFw
cGVhcnMgdG8gYmUgdGhlIGN1cnJlbnQgdmVyc2lvbiBvbiB0aGUgZGF0YS10cmFja2VyLg0KSSBh
Z3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBhY2Nlc3MtY29udHJvbC1saXN0LXR5cGUgbGVhZiBzaG91
bGQgYmUgbWFuZGF0b3J5Lg0KDQpJIG5vdGljZWQgdGhhdCB0aGUgZXhhbXBsZSBpbiBGaWd1cmUg
MiBoYXMgYW4gZXh0cmEgJ3RvcCcNCmNvbnRhaW5lciBhbmQgdGhlIG5hbWVzcGFjZSBmb3IgJ2Fj
Y2Vzcy1saXN0cycgaXMgbWlzc2luZy4NCg0KDQpBbmR5DQoNCk9uIE1vbiwgSnVuIDEsIDIwMTUg
YXQgMTE6MzEgQU0sIE5hYmlsIE1pY2hyYWYgPG5hYmlsLm1pY2hyYWZAZ21haWwuY29tPiB3cm90
ZToNCj4gSGkgYWxsLA0KPg0KPiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IGlmIHdlIGFyZSB0YWxr
aW5nIGFib3V0IA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW5ldG1vZC1h
Y2wtbW9kZWwtMDIudHh0IG9yIHNvbWUgDQo+IG90aGVyIGRyYWZ0Pw0KPiBJIGp1c3Qgd2FudCB0
byBtYWtlIHN1cmUgSSBhbSBsb29raW5nIGF0IHRoZSByaWdodCBBQ0wgbW9kZWwgdmVyc2lvbi4N
Cj4NCj4gVGhhbmsgeW91LA0KPiBOYWJpbA0KPg0KPiBPbiBNb24sIEp1biAxLCAyMDE1IGF0IDc6
MDYgQU0sIERhbmEgQmxhaXIgKGRibGFpcikgPGRibGFpckBjaXNjby5jb20+DQo+IHdyb3RlOg0K
Pj4NCj4+DQo+Pg0KPj4gT24gNC8xMy8xNSwgMTA6MTEgQU0sICJTdGVybmUsIEphc29uIChKYXNv
bikiDQo+PiA8amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+Pg0KPj4g
PkhpIGd1eXMsDQo+PiA+DQo+PiA+RXh0cmFjdGluZyBteSBjb21tZW50cyBhYm91dCBBQ0wgdHlw
ZSBpbnRvIGl0cyBvd24gdGhyZWFkLiAgSSBzYXcgDQo+PiA+TWFydGluIGFsc28gaGFkIHNvbWUg
Y29tbWVudHMgb24gdGhpcyB0b3BpYy4NCj4+ID4NCj4+ID5UaGUgQUNMIHR5cGUgd2FzIG1hbmRh
dG9yeSBpbiBhbiBvbGRlciB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhbmQgSSANCj4+ID50aGluayB3
ZSBzaG91bGQgcHV0IGl0IGJhY2sgYXMgbWFuZGF0b3J5LiAgSW1wbGVtZW50YXRpb25zIHRoYXQg
DQo+PiA+ZG9uJ3QgKm5lZWQqIHRoYXQgbGVhZiB2YWx1ZSBjYW4gd29yayBmaW5lIHdoZXRoZXIg
dGhleSBnZXQgaXQgDQo+PiA+ZHVyaW5nIEFDTCBjcmVhdGlvbiBvciBub3QgYnV0IHNvbWUgaW1w
bGVtZW50YXRpb25zIG5lZWQgdG8ga25vdyB0aGUgdHlwZS4NCj4+DQo+PiBXZSBkb27CuXQgd2Fu
dCB0byBtYWtlIHRoZSBBQ0wgdHlwZSBtYW5kYXRvcnkgYmVjYXVzZSB0aGVuIHdlIGhhdmUgdG8g
DQo+PiBhIGNyZWF0ZSBhIG5ldyB0eXBlIGZvciBldmVyeSBjb21iaW5hdGlvbiBvZiBtYXRjaCBj
cml0ZXJpYS4gIFRoZSANCj4+IG1vZGVsIHNob3VsZCBzdXBwb3J0IGFueSBjb21iaW5hdGlvbiBv
ZiBtYXRjaCBjcml0ZXJpYSB3aXRoIHR5cGluZyANCj4+IG9wdGlvbmFsIHRvIG1hcCB0byBwcmUt
ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBpcyBhIHRyYWRlb2ZmIA0KPj4gYmV0d2Vl
biBtYWtpbmcgdGhlIG1vZGVsIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyANCj4+
IGltcGxlbWVudGF0aW9ucyBidXQgbWFrZSBpdCBmbGV4aWJsZSBlbm91Z2ggc28gdGhhdCBhIG5l
dyBtYXRjaCANCj4+IGNyaXRlcmlhIGRvZXNuwrl0IHJlcXVpcmUgYSBuZXcgdHlwZS4NCg0KWz4+
SlRTXSBXZSBjYW4ganVzdCBjcmVhdGUgYSAibWl4ZWQiIChpLmUuIHVuc3BlY2lmaWVkKSB0eXBl
IGFuZCBwdXQgaXQgdW5kZXIgYW4gaWYtZmVhdHVyZS4gRXhpc3RpbmcgaW1wbGVtZW50YXRpb25z
IGhhdmUgYSBzaW5nbGUgdHlwZSAoYW5kIHJlcXVpcmUga25vd2luZyB0aGUgdHlwZSBhdCBsaXN0
IGNyZWF0aW9uIHRpbWUpLg0KDQo+Pg0KPj4gPg0KPj4gPkl0IHdvdWxkIGFsc28gYmUgZ29vZCB0
byBjcmVhdGUgc2VwYXJhdGUgaWRlbnRpdGllcyBmb3IgDQo+PiA+SVB2NC1hY2Nlc3MtY29udHJv
bC1saXN0IGFuZCBJUHY2LWFjY2Vzcy1jb250cm9sLWxpc3QgaW5zdGVhZCBvZiANCj4+ID5idW5k
bGluZyB0aGVtIGludG8gSVAtYWNjZXNzLWNvbnRyb2wtbGlzdC4gSWYgd2UncmUgc2VwYXJhdGlu
ZyBpbnRvIA0KPj4gPnR5cGVzIGluIHRoZSBtb2RlbCBpdCBzaG91bGQgYmUgdGhlIDMgYmFzaWMg
dHlwZXMgaW4gdGhlIGJhc2UgbW9kZWw6ICB2NCwgdjYgYW5kIGVuZXQuDQo+Pg0KPj4gQSB2ZW5k
b3Igc3BlY2lmaWMgYXVnbWVudGF0aW9uL2ltcGxlbWVudGF0aW9uIGNvdWxkIGRvIHRoaXMsIGJ1
dCB0aGUgDQo+PiBtb2RlbCBuZWVkcyB0byBzdXBwb3J0IGluY2x1c2lvbiBvZiBpcHY0IGFuZCBp
cHY2IGluIHRoZSBzYW1lIGFjbC4NCj4+IEnCuW0gYXdhcmUgb2Ygb3V0c3RhbmRpbmcgY3VzdG9t
ZXJzIHJlcXVlc3RzIGZvciBjb21iaW5pbmcgaXB2NCBydWxlcyANCj4+IGFuZCBpcHY2IHJ1bGVz
IGluIHRoZSBzYW1lIGFjbCwgYnV0IG1vc3QgaW1wbGVtZW50YXRpb25zIGhhdmUgbm90IA0KPj4g
Y2F1Z2h0IHVwIHRvIHRoaXMuICBXaGVuIGl0IGNvbWVzIHRvIG1hbmFnaW5nIGFjbHMgdGhlcmUg
c2hvdWxkbsK5dCBiZSANCj4+IHRoaXMgZGlzdGluY3Rpb24gYmV0d2VlbiBJUHY2IGFuZCBJUHY0
LiAgVGhleSBhcmUgYm90aCBJUCBhZGRyZXNzZXMuDQoNCg0KWz4+SlRTXSBBZ2FpbiAtIGxldCdz
IGZvY3VzIG9uIGNhcHR1cmluZyBjb21tb24gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGluIHRo
ZXNlIHN0YW5kYXJkIG1vZGVscyAod2hpbGUgYWxzbyBhbGxvd2luZyBmb3IgYXVnbWVudGF0aW9u
IGFuZCBmbGV4aWJpbGl0eSkuICBWNCBhbmQgVjYgYXJlIGluIHNlcGFyYXRlIGxpc3RzIHRvZGF5
LiAgQSBmdXR1cmUgbWl4ZWQgbGlzdCBjYW4gdXNlIHRoZSAibWl4ZWQiIHR5cGUgb3IgaW52ZW50
IGEgbmV3ICJ2NCt2NiIgdHlwZS4NCg0KPj4NCj4+ID4NCj4+ID5UaGF0IHdvdWxkIGFsc28gaGVs
cCBpZiB3ZSBkZWNpZGUgdG8gcHV0IHNvbWUgY29uc3RyYWludHMgdGhhdCANCj4+ID5hbGxvdy9k
aXNhbGxvdyBjZXJ0YWluIG1hdGNoaW5nIGNyaXRlcmlhIHdoZW4gdGhlIHR5cGUgaXMgYSBzcGVj
aWZpYyANCj4+ID52YWx1ZSAoZS5nLiBkb24ndCBhbGxvdyBhIHY2IGFkZHJlc3MgbWF0Y2ggaW4g
YSB2NCBsaXN0KS4NCj4+ID4gIFdlJ2QgaGF2ZSB0byBiZSBjYXJlZnVsIGFib3V0IGhvdyB0aG9z
ZSBjb25zdHJhaW50cyBhcmUgZm9ybXVsYXRlZCANCj4+ID50aG91Z2ggLSBlc3BlY2lhbGx5IGlm
IHdlIHdhbnQgdG8gYWxsb3cgYXVnbWVudGF0aW9ucyBvZiB0aGUgDQo+PiA+bGlzdC10eXBlIGZv
ciAibWl4ZWQiIEFDTHMuIEEgbmV3ICJtaXhlZC12NC1lbmV0IiB0eXBlIChpZGVudGl0eSkgDQo+
PiA+d291bGQgYWxzbyBuZWVkIHRvIHVzZSB0aGUgZGVzdGluYXRpb24taXB2NC1uZXR3b3JrIG1h
dGNoaW5nIA0KPj4gPmNyaXRlcmlhIChjYW4gIndoZW4iIG9yICJtdXN0IiBsb2dpYyBiZSBjaGFu
Z2VkIGJ5IGFuIGF1Z21lbnRhdGlvbiA/ICBJJ20gbm90IHN1cmUgdGhhdCB3b3JrcykuDQo+Pg0K
Pj4gWWVzLCB3b3VsZCBoYXZlIHRvIGJlIGNhcmVmdWwsIGFuZCBkZWZpbmluZyBjb25zdHJhaW50
cyBiYXNlZCBvbiBleGlzdGluZw0KPj4gaW1wbGVtZW50YXRpb25zIGNvdWxkIGJlIGEgdmVyeSBz
bGlwcGVyeSBzbG9wZS4gICBWZW5kb3JzIHNob3VsZCBiZSBhYmxlDQo+PiB0byBtYXAgdG8gdGhl
aXIgaW1wbGVtZW50YXRpb25zIGFuZC9vciBoYXZlIGEgcHJvcHJpZXRhcnkgDQo+PiBhdWdtZW50
YXRpb24gdGhhdCBjb25zdHJhaW5zIHRoaW5ncyBtb3JlIGFjY29yZGluZyB0bw0KPj4gdGhlaXIg
aW1wbGVtZW50YXRpb24uICAgUHJvcHJpZXRhcnkgYXVnbWVudGF0aW9ucyBjb3VsZCBiZSBwcm9w
b3NlZCwgYW5kDQo+PiByZXZpZXdlZCBmb3Igc3RhbmRhcmRpemF0aW9uLg0KDQoNCls+PkpUU10g
VGhlIGRyYWZ0IGRvZXNuJ3QgaGF2ZSBhbnkgY29uc3RyYWludHMgYmFzZWQgb24gdHlwZSBzbyBJ
IHN1cHBvc2UgdGhpcyBwb2ludCBpcyBtb290Lg0KDQo+Pg0KPj4gdGhhbmtzLA0KPj4gRGFuYQ0K
Pj4NCj4+ID4NCj4+ID5SZWdhcmRzLA0KPj4gPkphc29uDQo+PiA+DQo+PiA+DQo+PiA+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5uZXRtb2QgbWFp
bGluZyBsaXN0DQo+PiA+bmV0bW9kQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9k
QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0K
bmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5l
dG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Mon Sep 21 00:14:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8751A6FA8 for ; Mon, 21 Sep 2015 00:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAwjm9n1FM7U for ; Mon, 21 Sep 2015 00:13:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7801A6F93 for ; Mon, 21 Sep 2015 00:13:59 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B9231AE0484; Mon, 21 Sep 2015 09:13:57 +0200 (CEST)
Date: Mon, 21 Sep 2015 09:13:57 +0200 (CEST)
Message-Id: <20150921.091357.245840843414433806.mbj@tail-f.com>
To: jason.sterne@alcatel-lucent.com
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 07:14:03 -0000

Hi,

See below for some clarifying questions.


"Sterne, Jason (Jason)"  wrote:
> Hi all,
> =

> I met with Dean at IETF93 and we agreed that I should send a
> specific proposal to the list for this.  Here it is:
> =

> -----------------------------------------------------
> Replace the following current snippets from model-03:
> -----------------------------------------------------
> =

> list acl {
>   key "acl-name";
>   ...
> }
> =

> leaf acl-type {
>   type acl-type;
>   description
>     "It is recommended to have an Access Control List with
>      uniform access list entries, all of the same type. When
>      this type is not explicitly specified, if vendor
>      implementation permits, the access control entries
>      in the list can be mixed,
>      by containing L2, L3 and L4 entries";
> }
> =

> identity ip-acl {
>   base acl:acl-base;
>   description
>     "IP Access Control List is a common name for lists that contain
>      layer 3 and/or layer 4 match conditions.";
> }
> =

> identity eth-acl {
>   base acl:acl-base;
>   description
>     "Ethernet Access Control List is name for layer 2 Ethernet
>      technology Access Control List types, like 10/100/1000baseT or
>      WiFi Access Control List";
> }
> =

> --------------------  =

> with the following:
> --------------------
> =

> list acl {
>   key "acl-type acl-name";
>   ...
> }
> (note this is similar construct to the routing model: =

>    list routing-protocol {key "type name"... )
> =

> leaf acl-type {
>   type acl-type;
>   description
>     "Type of access control list. Indicates the primary intended
>      type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) =

>      used in the list instance.";

What exactly does "primary intended type of match criteria" mean?

How is the ace-type related to the acl-type?  Shouldn't the
ace-type-specific params be conditional (with "when") based on the
acl-type?


/martin



> }
> =

> identity ipv4-acl {
>   base acl:acl-base;
>   description =

>     "ACL that primarily matches on fields from the IPv4 header
>     (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP des=
tination
>     port).  An acl of type ipv4-acl does not contain matches on field=
s in
>     the ethernet header or the IPv6 header.";
> }
> =

> identity ipv6-acl {
>   base acl:acl-base;
>   description
>     "ACL that primarily matches on fields from the IPv6 header
>     (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP des=
tination
>     port). An acl of type ipv6-acl does not contain matches on fields=
 in
>     the ethernet header or the IPv4 header.";
> }
>   =

> identity eth-acl {
>   base acl:acl-base;
>   description
>     "ACL that primarily matches on fields in the ethernet header.
>      An acl of type eth-acl does not contain matches on fields in
>      the IPv4 header, IPv6 header or layer 4 headers.";
> }
> =

> =

> ---------------------------------------
> Potential future augmentation of type:
> ----------------------------------------
> =

> For future mixed types vendors (or the ietf) could augment the acl-ty=
pe-base with types like the following:
> =

>   identity mixed-l3-acl {
>     base "access-control-list:acl-type-base";
>     description "ACL that contains a mix of entries that primarily ma=
tch on fields =

>       in IPv4 headers and entries that primarily match on fields in I=
Pv6 headers.
>       Matching on layer 4 header fields may also exist in the list.
>       An acl of type mixed-l3-acl does not contain matches on fields =
in
>       the ethernet header.";
>   }
>  =

>   identity mixed-l2-l3-acl {
>     base "access-control-list:acl-type-base";
>     description "ACL that contains a mix of entries that primarily ma=
tch on fields =

>       in ethernet headers, entries that primarily match on fields in =
IPv4 headers,
>       and entries that primarily match on fields in IPv6 headers.  Ma=
tching on layer 4 =

>       header fields may also exist in the list.";
>   }
> =

> Regards,
> Jason
> =

> -----Original Message-----
> From: Sterne, Jason (Jason) =

> Sent: Sunday, July 19, 2015 12:58
> To: Sterne, Jason (Jason); netmod@ietf.org
> Subject: RE: ACL Model 03 - ACL Type should be mandatory
> =

> Given the data models below in some of the major implementations it a=
lso seems like we should also (re-)consider having the 'type' as part o=
f the ACL key ("type name").  =

> =

> In all those cases below it looks like an operator can currently conf=
igure two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the same n=
ame/id via their CLI (e.g. a v4 ACL called "my-acl" and a v6 ACL called=
 "my-acl").  =

> =

> How would those lists be read in a  via the ietf ACL YANG=
 modules ?  We'd all have to mangle the names and reserve special names=
/prefix-chars (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them back to=
 a NC client.  I'm not sure if there is much of a disadvantage of just =
having type in the key (assuming it is mandatory as advocated below).
> =

> I also looked briefly at the Brocade YANG models on github.  It looks=
 like they have multiple lists as well for v4 vs v6 (and even or differ=
ent types of normal vs extended ACLs - that could be handled by augment=
ing the type with a 'v4-extended' type for example).
> =

> Regards,
> Jason
> =

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Ja=
son (Jason)
> Sent: Friday, July 17, 2015 23:35
> To: netmod@ietf.org
> Subject: [netmod] ACL Model 03 - ACL Type should be mandatory
> =

> Hi all,
> =

> I think we need to revisit this discussion about how ACL type works i=
n draft-ietf-netmod-acl-model-03.
> =

> It should be mandatory and we should separate v4 from v6.  Vendors ca=
n augment for future "mixed" types (or maybe we should make an if-featu=
re for a "mixed" type now that means "anything goes").
> =

> We should follow existing common implementations for this in order to=
 foster better adoption.
> =

> Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of specify=
ing the list:
> ipv4 access-list 
> ipv6 access-list 
>  =

> Junos has separate lists for v4 and v6:
> access-list  ...
> ipv6 access-list  ...
>  =

> ALU SR OS has separate lists for v4, v6 and mac:
> config filter ip-filter 
> config filter ipv6-filter 
> config filter mac-filter 
>  =

> Huawei uses separate lists for v4 and v6:
> acl number 3000
> acl ipv6 number 3000
> =

> Please see below with [>>JTS]
> =

> Regards,
> Jason
> =

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierm=
an
> Sent: Monday, June 01, 2015 17:00
> To: Nabil Michraf
> Cc: netmod@ietf.org
> Subject: Re: [netmod] mandatory ACL type (was "comments on acl-model-=
02")
> =

> Hi,
> =

> =

> That appears to be the current version on the data-tracker.
> I agree with you that the access-control-list-type leaf should be man=
datory.
> =

> I noticed that the example in Figure 2 has an extra 'top'
> container and the namespace for 'access-lists' is missing.
> =

> =

> Andy
> =

> On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf  wrote:
> > Hi all,
> >
> > Can you please clarify if we are talking about =

> > https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some =

> > other draft?
> > I just want to make sure I am looking at the right ACL model versio=
n.
> >
> > Thank you,
> > Nabil
> >
> > On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair) 
> > wrote:
> >>
> >>
> >>
> >> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
> >>  wrote:
> >>
> >> >Hi guys,
> >> >
> >> >Extracting my comments about ACL type into its own thread.  I saw=
 =

> >> >Martin also had some comments on this topic.
> >> >
> >> >The ACL type was mandatory in an older version of the draft and I=
 =

> >> >think we should put it back as mandatory.  Implementations that =

> >> >don't *need* that leaf value can work fine whether they get it =

> >> >during ACL creation or not but some implementations need to know =
the type.
> >>
> >> We don=B9t want to make the ACL type mandatory because then we hav=
e to =

> >> a create a new type for every combination of match criteria.  The =

> >> model should support any combination of match criteria with typing=
 =

> >> optional to map to pre-existing implementations.  This is a tradeo=
ff =

> >> between making the model backward compatible with existing =

> >> implementations but make it flexible enough so that a new match =

> >> criteria doesn=B9t require a new type.
> =

> [>>JTS] We can just create a "mixed" (i.e. unspecified) type and put =
it under an if-feature. Existing implementations have a single type (an=
d require knowing the type at list creation time).
> =

> >>
> >> >
> >> >It would also be good to create separate identities for =

> >> >IPv4-access-control-list and IPv6-access-control-list instead of =

> >> >bundling them into IP-access-control-list. If we're separating in=
to =

> >> >types in the model it should be the 3 basic types in the base mod=
el:  v4, v6 and enet.
> >>
> >> A vendor specific augmentation/implementation could do this, but t=
he =

> >> model needs to support inclusion of ipv4 and ipv6 in the same acl.=

> >> I=B9m aware of outstanding customers requests for combining ipv4 r=
ules =

> >> and ipv6 rules in the same acl, but most implementations have not =

> >> caught up to this.  When it comes to managing acls there shouldn=B9=
t be =

> >> this distinction between IPv6 and IPv4.  They are both IP addresse=
s.
> =

> =

> [>>JTS] Again - let's focus on capturing common existing implementati=
ons in these standard models (while also allowing for augmentation and =
flexibility).  V4 and V6 are in separate lists today.  A future mixed l=
ist can use the "mixed" type or invent a new "v4+v6" type.
> =

> >>
> >> >
> >> >That would also help if we decide to put some constraints that =

> >> >allow/disallow certain matching criteria when the type is a speci=
fic =

> >> >value (e.g. don't allow a v6 address match in a v4 list).
> >> >  We'd have to be careful about how those constraints are formula=
ted =

> >> >though - especially if we want to allow augmentations of the =

> >> >list-type for "mixed" ACLs. A new "mixed-v4-enet" type (identity)=
 =

> >> >would also need to use the destination-ipv4-network matching =

> >> >criteria (can "when" or "must" logic be changed by an augmentatio=
n ?  I'm not sure that works).
> >>
> >> Yes, would have to be careful, and defining constraints based on e=
xisting
> >> implementations could be a very slippery slope.   Vendors should b=
e able
> >> to map to their implementations and/or have a proprietary =

> >> augmentation that constrains things more according to
> >> their implementation.   Proprietary augmentations could be propose=
d, and
> >> reviewed for standardization.
> =

> =

> [>>JTS] The draft doesn't have any constraints based on type so I sup=
pose this point is moot.
> =

> >>
> >> thanks,
> >> Dana
> >>
> >> >
> >> >Regards,
> >> >Jason
> >> >
> >> >
> >> >_______________________________________________
> >> >netmod mailing list
> >> >netmod@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> =

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








> https://www.ietf.org/mailman/listinfo/netmod





































From nobody Mon Sep 21 01:26:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47BB1A89C5 for ; Mon, 21 Sep 2015 01:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ALHtBAPfdOW for ; Mon, 21 Sep 2015 01:26:42 -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 9F2AB1A89BB for ; Mon, 21 Sep 2015 01:26:41 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B1EE1405; Mon, 21 Sep 2015 10:26:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zsD6R-z6g-uz; Mon, 21 Sep 2015 10:26:38 +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; Mon, 21 Sep 2015 10:26:38 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 999C620053; Mon, 21 Sep 2015 10:26:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LDJd7PscEu1Y; Mon, 21 Sep 2015 10:26:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 790DD2004E; Mon, 21 Sep 2015 10:26:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C6E143727443; Mon, 21 Sep 2015 10:26:31 +0200 (CEST)
Date: Mon, 21 Sep 2015 10:26:30 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150921082628.GA11184@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 08:26:44 -0000

On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
> >  
> >> >> Let's look at a slightly more complex hypothetical case to tease
> >> >> out how folks *want* things to work.  Assume the following have
> >> >> been defined:
> >> >>
> >> >>   - base module M
> >> >>   - augmentation Q
> >> >>   - augmentation R
> >> >>
> >> >> On a server claiming to supporting the modules containing M, Q,
> >> >> and R, respectively, which of the following might one encounter
> >> >> concurrently?
> >> >>
> >> >>      - plain M
> >> >>      - M+Q
> >> >>      - M+R
> >> >>      - M+Q+R
> >> >
> >> >It depends on what you mean by "encounter" but in terms of datastore
> >> >validity the only possible answer IMO is M+Q+R.
> >> 
> >> By "encounter" I mean if a client asks the server for all of its Ms,
> >> and the server also supports Q and R, are all of the Ms *guaranteed*
> >> to be M+Q+R, or is it possible that some of the Ms might lack Q or
> >> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
> >> how would one model a system inhabited by a mixture of the four
> >> kinds of Ms?
> >
> > Retrieval is easy since a client is going to ignore data it does not
> > understand and the server is expected to report what makes sense from
> > the server's perspective. The question is relevant for writing: Is a
> > client programmed based on M going to work even if a server supports
> > M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC
> > 6020 wanted to achieve this by forbidding mandatory nodes in
> > augmentations.
> >
> > Y26-02 says that a presence container may be used to avoid breaking an
> > old client. Frankly, it seems not totally clear to me what the
> > sentence in section 7.15 of RFC 6020 really means:
> >
> >     If the target node is in another module, then nodes added by the
> >     augmentation MUST NOT be mandatory nodes (see Section 3.1).
> >
> > Does this rule only apply to nodes directly added under the target
> > node or does it apply to the whole hierarchy added? In the later case,
> > this would still cause a problem with the presence container work
> > around.
> 
> Yes, it's unclear but IMO it is about mandatory nodes directly below the
> target node - a similar rule for module updates is in sec. 11.
> 
> >
> > The recent suggestion to replace MUST NOT with SHOULD NOT in this
> > sentence may be seen as a softer variant of Y26-01. However, I think
> > we would, in addition, have to describe when it is OK to have
> > mandatory nodes in augmentations and when not. Simply saying SHOULD
> > NOT instead of MUST NOT will not help people to understand the issues
> > around this.
> 
> The definition in RFC 2119 is:
> 
> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.
> 
> I think it should suffice if data model designers are aware of the
> fact that certain augments may break old clients, and give some
> reasoning if they use them anyway. 
> 
> >
> > When this issue was discussed in the past, it turned out to be
> > difficult to find someone to write the necessary text explaining when
> > augmenting mandatory nodes is safe and when not. Are we doing better
> > now?
> 
> I don't think we can enumerate all cases where it is allowed because
> YANG doesn't follow any rigid structure and there may be a variety of
> different designs.
> 
> I'd prefer to explain the ramifications of defining mandatory nodes in
> augments (and also in module updates) and leave it to the model designer
> to judge whether there are valid reasons to override the "SHOULD NOT" -
> and YANG doctors should verify it in IETF models.
> 
> I think the point is that parameters are mandatory not because a
> spiteful module author defines them so but rather because the system
> cannot work without them.
>

Still some text needs to be written explaining that breaking old
clients by adding new mandatory nodes is a no go. I did not ask to
enumerate all situations where it is allowed, I am looking for text
that clearly says what people have to look out for if they add
mandatory nodes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 21 01:34:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BB71A8A44 for ; Mon, 21 Sep 2015 01:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFCPxe7QVKuv for ; Mon, 21 Sep 2015 01:34:15 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC231A8A4A for ; Mon, 21 Sep 2015 01:34:14 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E5ADB1CC02AC; Mon, 21 Sep 2015 10:34:18 +0200 (CEST)
From: Ladislav Lhotka 
To: "Eric Voit \(evoit\)" , Randy Presuhn , "netmod\@ietf.org" , Rob Shakir 
In-Reply-To: 
References: 
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 21 Sep 2015 10:34:07 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Sander Mertens 
Subject: Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 08:34:17 -0000

Hi Eric,

we are dealing with two rather different problems:

1. A pull-type method for combining YANG schemas as a complement to
   "augment".

2. A proxy function that mediates access to data that are located
   elsewhere.

I believe the recent thread on structuring YANG models has been about #1
while both this draft and draft-clemm-netmod-mount-03 mainly address
#2. Each problem has its share of issues to solve but the issues don't
overlap, so I believe it would be useful to keep both problems
separate.

Lada

"Eric Voit (evoit)"  writes:

> There was a recent thread on structuring YANG models so that application developers might be able to reference alternative local hierarchies/tree structures for certain objects.  This thread motivated Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is posted at:
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/
>
> This draft has been retitled to "Requirements for mounting of local and remote YANG subtrees".  This retitling was done because we have separated the thinking on what it takes to Mount objects from remote devices (Peer Mount) from what it takes to Mount within the same device (Alias Mount).
>
> We would be interested in your thoughts.   
>
> Eric
>
> -----Original Message-----
> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>
> Randy Presuhn  writes:
>
>> Hi -
>>
>> It is with no little amusement that I watch this thread struggling 
>> with questions that were solved fairly neatly a quarter century ago in 
>> GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like 
>> to offer an observation about modeling that might help.
>>
>> The organization of instance data in SNMP is a direct mirror of the 
>> "object" definitions.  Simple at first, but quickly becoming baroque 
>> as various minds of "multiplexing" are added to compensate for post 
>> hoc deficiencies in the index structures.
>>
>> Life is such that once a resource has been modeled, it will be 
>> used/re-used/embedded in systems in ways in which its designers 
>> couldn't be expected to imagine.  A consequence of this is that if 
>> instance naming is completely locked down when the management 
>> interface for a resource is first defined (as it is in SNMP) then all 
>> sorts of peculiar hacks will be needed to deal with, for example, 
>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so 
>> pervasive that folks seem to overlook that there are other ways to 
>> deal with this situation.
>>
>> What GDMO did was to use a separate "NAME BINDING" construct to 
>> specify contexts in which instances might show up, allowing instances 
>> to be put in places that weren't even imagined when the original class 
>> definition was written.  Name bindings could be standardized, or be 
>> vendor or even product-specific, allowing the simplicity or complexity 
>> of a given system's instance tree to reflect the actual simplicity or 
>> complexity of that system, rather than requiring all systems to be 
>> structured for the worst case.
>
> How could this be expressed in YANG terms? (I tried to figure it out myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommendation X.722).
>
> Thanks, Lada
>
>>
>> Yes, separating the specification of instance naming in large part 
>> from class definition does have implications for how one does access 
>> control, and how clients figure out how to ask a server to create 
>> something, but it's not a huge deal - it's just not like VACM, and a 
>> whole slew of hacky solutions and "wierd plumbing adapters" (to borrow 
>> from Jeff Case) just go away.  Strangely, it makes the job of the 
>> initial modeler and of the eventual user much easier.
>>
>> Randy
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon Sep 21 02:34:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D61A90DD for ; Mon, 21 Sep 2015 02:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id satoQ7BExdme for ; Mon, 21 Sep 2015 02:34:42 -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 89ACF1A90DA for ; Mon, 21 Sep 2015 02:34:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1442828081; x=1444037681; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=3hK01NVez4196GrcDL7InE3WOLzEUK9sESSJA9C+eiA=; b=klKMh2SDXlNyI84GTGuX2omQDQ+JY97i/6e8V8M39jBGzvuqh5NxoICD eNXxhIGPSNKx9MovccfuVHP/dl6mCJHudC+XUdtA4Bs8/biHPTy6rG7DP cuoUtOOOGjszi+qTPdBX30VrKsbi3tFr/EZKRUyRXazTa0v/G9o8jB02X Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBAD5zf9V/xbLJq1dg3hpv0EMhS1KAoF+AQEBAQEBgQuEJAEBBAEBATU2ChELDgoJFg8JAwIBAgEVMAYBDAYCAQGIKg0DygEBAQEBAQEBAQEBAQEBAQEBAQEWBIZzhH2CPoF2AV+ELAEElWSFEYd2gU2ENYJ+khpjhAI9M4glAR+BKAEBAQ
X-IronPort-AV: E=Sophos;i="5.17,567,1437436800"; d="scan'208";a="605252275"
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; 21 Sep 2015 09:34:39 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8L9YdKx020265; Mon, 21 Sep 2015 09:34:39 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <55FFCF2F.5010902@cisco.com>
Date: Mon, 21 Sep 2015 10:34:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 09:34:43 -0000

Hi,

I suggest changing the wording for A and adding D:

    7.  Ability for distinct modules to leverage a common model-structure
        A.  Scope is limited to providing a general model-structure only
        B.  Multiple domain-specific trees are okay
        C.  Multiple namespaces are okay
        D.  The model-structure may be used or extended by other organizations.

Justifications for (A):
  - Limiting the scope to IETF-defined modules almost implies that 
'ietf' would end up in the path (which would be wrong/unnecessary).
  - Clients don't care which SDO defines the modules for the protocols 
they use, they just want a coherent organization of modules.
  - General structure only to limit the scope because trying to 
precisely place every protocol/feature is likely to be fragile in the 
face of future changes.

Justifications for (D):
  - To suggest and encourage other SDOs to use the same structure, but 
cannot mandate what they do.

Thanks,
Rob


On 18/09/2015 22:56, Kent Watsen wrote:
> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>
>
>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>              others are now defining YANG modules?
>
>    Benoit> Good point. We need to provide guidance for the other SDOs.
>
>
> Current text says:
>
>     7.  Ability for distinct modules to leverage a common model-structure
>         A.  Scope is limited to IETF-defined modules
>         B.  Multiple domain-specific trees are okay
>         C.  Multiple namespaces are okay
>
>
>
> Background:
>
>    I pulled 7A from Andy's message here:
>
>      
> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>
>    and put a stake in the ground so that, if nothing else, it could
>    be discussed...and here we are!
>
>    FWIW, I wrote 7A this way because I didn't see how it can be
>    enforced outside of the IETF.  But maybe that doesn't matter?
>    Of course, we can have 6087bis guidance for other SDOs, but
>    I didn't put that in the text.
>
>
> Thoughts on how the text should be updated?
>
>
> PS: Please Reply-All to the list rather than post comments to the GitHub
> issue tracker.
>
>
> Thanks,
> Kent
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Mon Sep 21 05:15:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5310A1A7D83 for ; Mon, 21 Sep 2015 05:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7GEjz8vadkC for ; Mon, 21 Sep 2015 05:15:18 -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 E0BA01A702F for ; Mon, 21 Sep 2015 05:15:17 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5F29E131C for ; Mon, 21 Sep 2015 14:15:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VLf1HwqAyQYA for ; Mon, 21 Sep 2015 14:15:15 +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 for ; Mon, 21 Sep 2015 14:15:15 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7761020055 for ; Mon, 21 Sep 2015 14:15:15 +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 pN8M2PGz2hqK; Mon, 21 Sep 2015 14:15:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 188BF2004E; Mon, 21 Sep 2015 14:15:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0B44137541A8; Mon, 21 Sep 2015 14:15:11 +0200 (CEST)
Date: Mon, 21 Sep 2015 14:15:11 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20150921121509.GA93631@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] today's virtual interim on YANG 1.1 cancelled
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 12:15:19 -0000

Hi,

after consulting with Martin Bjorklund, I decided to cancel today's
YANG 1.1 virtual interim meeting. Martin believes he has the input
needed to produce the next revision of draft-ietf-netmod-rfc6020bis.
This update should be posted during this week. We will then do any
word smithing that might be needed based on this revision of the YANG
1.1 specification. We will try to do most of the word smithing via the
mailing list but if needed we will make use of the YANG 1.1 virtual
interim meetings that we have allocated.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 21 05:28:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079011B3143 for ; Mon, 21 Sep 2015 05:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJPEIm6lQeA0 for ; Mon, 21 Sep 2015 05:28:03 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197021B3142 for ; Mon, 21 Sep 2015 05:28:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6088; q=dns/txt; s=iport; t=1442838483; x=1444048083; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=QHWl9jdGiN3T7NpbC/+AnmJ/wwZb/iyOE+daBaVU0ac=; b=IpQnTEzwOJwQGVCh0cWM4kjRqVXk+OeqvplsvWIfP43v2N0i/6sgiOnS CKn5pP9KgkjGG/PdcBlMfDIz5kEM4TYyB5ZeGQrTbORrH3ar0o/Q0FSrM TOCtOctDiWPweHXTRtveYwhfF9i4lR9WE55TpEQh/m+ovkcpoB4ZyRVHO 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQDs9v9V/xbLJq1dgleBIWm9QgENgXEBC4UtSgKBbBQBAQEBAQEBgQqEJAEBBAEBAWsKERkTFg8JAwIBAgEVMAYBDAYCAQEXiBMNyi8BAQEBAQEBAQEBAQEBAQEBAQEWBIZziTJfhCwFlWSFEYd2gU2HM4lhiDkfAQFChAM8M4gmgUcBAQE
X-IronPort-AV: E=Sophos;i="5.17,567,1437436800";  d="scan'208,217";a="629859752"
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; 21 Sep 2015 12:27:59 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8LCRxgn003598; Mon, 21 Sep 2015 12:27:59 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: 
From: Benoit Claise 
Message-ID: <55FFF7CF.1090807@cisco.com>
Date: Mon, 21 Sep 2015 14:27:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050803080700000902000400"
Archived-At: 
Subject: [netmod] Issue Re:  closing issues on opstate-reqs
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 12:28:05 -0000

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

Dear all,

One update on my side on 
https://github.com/netmod-wg/opstate-reqs/issues/7: Why limit scope to 
just IETF-defined modules?

This issue will be taken care of in the Guidelines document RFC6087bis, 
for both the IETF and the other SDOs, once we agree on the solution.
It is covered by both:
     https://github.com/netmod-wg/rfc6087bis/issues/18
     https://github.com/netmod-wg/rfc6087bis/issues/22

I believe the issue https://github.com/netmod-wg/opstate-reqs/issues/7 
can be closed.

Regards, Benoit
>
> Seven issues were filed against draft-chairs-netmod-opstate-reqs-00:
>
> https://github.com/netmod-wg/opstate-reqs/issues
>
>
> These issues are all currently in the NEW state.  FYI, all the issue 
> tracking states are described here:
>
> https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-tracking
>
>
> Immediately I plan to start a thread to track some of these issues to 
> closure.  I will start with an easy issue so we can see how it goes.
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
Dear all,

      

      One update on my side on
      https://github.com/netmod-wg/opstate-reqs/issues/7: Why limit scope to just IETF-defined
        modules?

        

        This issue will be taken care of in the Guidelines document
        RFC6087bis, for both the IETF and the other SDOs, once we agree
        on the solution. 

        It is covered by both:

         https://github.com/netmod-wg/rfc6087bis/issues/18

         https://github.com/netmod-wg/rfc6087bis/issues/22

        

        I believe the issue
        https://github.com/netmod-wg/opstate-reqs/issues/7 can be
        closed.

        

        Regards, Benoit

      

    

      
      

        

      

      

        Seven issues were filed
        againstdraft-chairs-netmod-opstate-reqs-00:

      

        

      

      
      

        

        

      


        

      
These
          issues are all currently in the NEW state. FYI, all the issue
          tracking states are described here:

      


        

      
      


        

      


        

      
Immediately I plan to start a thread to track some of these
        issues to closure. I will start with an easy issue so we can
        see how it goes.

      


      

      
Thanks,

      
Kent

      


      

      

      

      

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


    

    

  


--------------050803080700000902000400--


From nobody Mon Sep 21 05:38:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE1F1B3151 for ; Mon, 21 Sep 2015 05:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whl3zEJ6ZeOt for ; Mon, 21 Sep 2015 05:38:00 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78BD21B3150 for ; Mon, 21 Sep 2015 05:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8422; q=dns/txt; s=iport; t=1442839080; x=1444048680; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=sle3aQ04OUiY+Ten6gooBzbhxO4vTaBbKAa/cj9Giis=; b=QkN4GTKWBQLKsSSZ0K75OYsiNv26SpDzHXbXpECMkEJwkOwmGBdO3SV9 TP4foUbF20TE0akjfz2lBWZAzk7Xp6FkrnhWiSrVsBEePHh0lAZld4HzD 00XdqYd89x6l8XVf3cdJef8cLIne/C0AKIsj9Rneu0YI6tiG2gyCsmQCz c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ChBABO+f9V/xbLJq1dgleBIWm/QQELhS1KAoIAAQEBAQEBgQuEJAEBBAEBAWsKEQsOExYPCQMCAQIBFTAGAQwGAgEBF4gTDcosAQEBAQEBAQEBAQEBAQEBAQEBFgSGc4R9hDQBX4QsAQSVZIURh3aBTYcziWGIOWOEAzwziCUBH4EoAQEB
X-IronPort-AV: E=Sophos;i="5.17,567,1437436800";  d="scan'208,217";a="607137515"
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; 21 Sep 2015 12:37:57 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8LCbvj3017814; Mon, 21 Sep 2015 12:37:57 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:  <55FFF7CF.1090807@cisco.com>
From: Benoit Claise 
Message-ID: <55FFFA24.1030301@cisco.com>
Date: Mon, 21 Sep 2015 14:37:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55FFF7CF.1090807@cisco.com>
Content-Type: multipart/alternative; boundary="------------020503080109090608010802"
Archived-At: 
Subject: Re: [netmod] Issue 7 (Re: closing issues on opstate-reqs)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 12:38:02 -0000

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

Sent too fast.
I would change the requirement text like this.
OLD:

   7.  Ability for distinct modules to leverage a common model-structure
        A.  Scope is limited to IETF-defined modules
        B.  Multiple domain-specific trees are okay
        C.  Multiple namespaces are okay

NEW:

   7.  Ability for distinct modules to leverage a common model-structure
        A.  Focus on the IETF-defined modules, and ideally provides guidance to other SDOs
        B.  Multiple domain-specific trees are okay
        C.  Multiple namespaces are okay

Regards, Benoit
> Dear all,
>
> One update on my side on 
> https://github.com/netmod-wg/opstate-reqs/issues/7: Why limit scope to 
> just IETF-defined modules?
>
> This issue will be taken care of in the Guidelines document 
> RFC6087bis, for both the IETF and the other SDOs, once we agree on the 
> solution.
> It is covered by both:
> https://github.com/netmod-wg/rfc6087bis/issues/18
> https://github.com/netmod-wg/rfc6087bis/issues/22
>
> I believe the issue https://github.com/netmod-wg/opstate-reqs/issues/7 
> can be closed.
>
> Regards, Benoit
>>
>> Seven issues were filed against draft-chairs-netmod-opstate-reqs-00:
>>
>> https://github.com/netmod-wg/opstate-reqs/issues
>>
>>
>> These issues are all currently in the NEW state.  FYI, all the issue 
>> tracking states are described here:
>>
>> https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-tracking
>>
>>
>> Immediately I plan to start a thread to track some of these issues to 
>> closure.  I will start with an easy issue so we can see how it goes.
>>
>> Thanks,
>> Kent
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
Sent too fast.

      I would change the requirement text like this.

      OLD:

      
  7.  Ability for distinct modules to leverage a common model-structure
       A.  Scope is limited to IETF-defined modules
       B.  Multiple domain-specific trees are okay
       C.  Multiple namespaces are okay


      NEW:

      
  7.  Ability for distinct modules to leverage a common model-structure
       A.  Focus on the IETF-defined modules, and ideally provides guidance to other SDOs
       B.  Multiple domain-specific trees are okay
       C.  Multiple namespaces are okay

      Regards, Benoit

    

    

      
      
Dear all,

        

        One update on my side on https://github.com/netmod-wg/opstate-reqs/issues/7: Why limit scope to just IETF-defined
          modules?

          

          This issue will be taken care of in the Guidelines document
          RFC6087bis, for both the IETF and the other SDOs, once we
          agree on the solution. 

          It is covered by both:

           https://github.com/netmod-wg/rfc6087bis/issues/18

           https://github.com/netmod-wg/rfc6087bis/issues/22

          

          I believe the issue https://github.com/netmod-wg/opstate-reqs/issues/7
          can be closed.

          

          Regards, Benoit

        

      

        
 

        

        
 Seven issues were filed
          againstdraft-chairs-netmod-opstate-reqs-00:

        
 

        

        
        
 

          

        


          

        
These

            issues are all currently in the NEW state. FYI, all the
            issue tracking states are described here:

        


          

        
        


          

        


          

        
Immediately I plan to start a thread to track some of these
          issues to closure. I will start with an easy issue so we can
          see how it goes.

        


        

        
Thanks,

        
Kent

        


        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------020503080109090608010802--


From nobody Mon Sep 21 05:47:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538E81B30C2 for ; Mon, 21 Sep 2015 05:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD3ppF3SsWmR for ; Mon, 21 Sep 2015 05:47:30 -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 0C1A11B3160 for ; Mon, 21 Sep 2015 05:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1937; q=dns/txt; s=iport; t=1442839650; x=1444049250; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=OD01U5tQMLYUY+otpALioAe/HlHRcJyvc/dqVAeJyQk=; b=NsCXJYjc3zp2PYJPSkFlkX9baPSgxGJUhfgRWDj40JBeGm57lMg+0snj iAOmcjYR2LurOgInLuD6qwoWk+hqMBl/o6ZOzpZ5bNeEUIWZa5jpZ9UIk /uV6/6lljq7dvoeclBdTT0SgC0jTksVSH+o/VZjVtVdAUIyjrWQLeoRTG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcBADn+/9V/xbLJq1dhGHFRAKCAAEBAQEBAYELhCMBAQEEIw8BBT8BEQsOCgICBRYEBwICCQMCAQIBPAkGAQwGAgEBiCq2Q5N1AQEBAQEBAQMBAQEBAQEcgSKFUYR9hEJSgmmBQwEElWSNB4kAkhpjgkOBQDwziW0BAQE
X-IronPort-AV: E=Sophos;i="5.17,567,1437436800"; d="scan'208";a="605255679"
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; 21 Sep 2015 12:47:26 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8LClQF3003027; Mon, 21 Sep 2015 12:47:26 GMT
To: Rob Shakir , "netmod@ietf.org" , Kent Watsen 
References: <20150911213636.11309.79529.idtracker@ietfa.amsl.com>  <55F6C0EE.4010404@cisco.com> 
From: Benoit Claise 
Message-ID: <55FFFC5E.8010009@cisco.com>
Date: Mon, 21 Sep 2015 14:47:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 12:47:32 -0000

Thanks Rob, that clarifies the situation for me.

Regards, Benoit
> On 14 September 2015 at 08:43:53, Benoit Claise (bclaise@cisco.com) wrote:
>
>> Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
>> required?
>> Do we need to make the link between a config node and all the derived
>> counters/statistics it influences, which might be in different YANG
>> models btw?
> Yes - we need to deterministically retrieve, for a particular configuration object (e.g., interface, BGP peer) the set set of derived state nodes associated with it, such that we do not need to maintain complex mapping tables on the client side for this - and can efficiently query the server for them.
>
> For instance, knowing that we configured a BGP peer at $SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/config/{leaf-set} then we would find the counters at $SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/state/ - allows us to (based on the fact that we just configured a peer) retrieve the state and counters that a client application will likely want to check without having to map to some other (set of locations).
>
> Note that in previous discussions, it was expressed that this implied that the model had knowledge of how the protocol operates such that it was known that leaf A corresponding to some other derived-state leaf B. However, this isn’t true. As I expressed before, the intention is that it is possible for a NMS layer to easily retrieve the set of state objects that an interested client may require, without many disparate queries, based on the configuration path. The actual meaning may be completely unknown to this layer.
>
> The openconfig-opstate approach allows state and config to be defined in separate modules - since the ‘state’ module in this case can simply augment the relevant ‘state’ containers within the config model.
>
> Regards,
> r.
> .
>


From nobody Mon Sep 21 06:11:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED25F1B317E for ; Mon, 21 Sep 2015 06:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVMOwtYNrEVw for ; Mon, 21 Sep 2015 06:11:34 -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 ADF4C1B316B for ; Mon, 21 Sep 2015 06:11:32 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 5DA6B78140800; Mon, 21 Sep 2015 13:11:27 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t8LDBRrs020595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Sep 2015 13:11:29 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 21 Sep 2015 09:11:27 -0400
From: "Sterne, Jason (Jason)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] ACL Model 03 - ACL Type should be mandatory
Thread-Index: AQHQnK3+1WRBFqzUuEu69dSP2qQCIp3gdK+QgAK8bbCAY1hsMIAA+lOAgAAd3aA=
Date: Mon, 21 Sep 2015 13:11:27 +0000
Message-ID: 
References:    <20150921.091357.245840843414433806.mbj@tail-f.com>
In-Reply-To: <20150921.091357.245840843414433806.mbj@tail-f.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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 13:11:37 -0000

Hi Martin,

I think you raised those questions before about the model and they are usef=
ul to discuss but are they specific to my proposed modification to make the=
 type mandatory or do your questions apply equally to the current v3 model =
as-is ?

We may want to fork off two somewhat independent email threads here:
1) making type part of the key (what I hoped to focus on in this email thre=
ad)
2) use acl-type somehow in some constraints on the ace match criteria (your=
 main point)

Jason

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com]=20
Sent: Monday, September 21, 2015 3:14
To: Sterne, Jason (Jason)
Cc: netmod@ietf.org
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory

Hi,

See below for some clarifying questions.


"Sterne, Jason (Jason)"  wrote:
> Hi all,
>=20
> I met with Dean at IETF93 and we agreed that I should send a specific=20
> proposal to the list for this.  Here it is:
>=20
> -----------------------------------------------------
> Replace the following current snippets from model-03:
> -----------------------------------------------------
>=20
> list acl {
>   key "acl-name";
>   ...
> }
>=20
> leaf acl-type {
>   type acl-type;
>   description
>     "It is recommended to have an Access Control List with
>      uniform access list entries, all of the same type. When
>      this type is not explicitly specified, if vendor
>      implementation permits, the access control entries
>      in the list can be mixed,
>      by containing L2, L3 and L4 entries"; }
>=20
> identity ip-acl {
>   base acl:acl-base;
>   description
>     "IP Access Control List is a common name for lists that contain
>      layer 3 and/or layer 4 match conditions."; }
>=20
> identity eth-acl {
>   base acl:acl-base;
>   description
>     "Ethernet Access Control List is name for layer 2 Ethernet
>      technology Access Control List types, like 10/100/1000baseT or
>      WiFi Access Control List";
> }
>=20
> --------------------
> with the following:
> --------------------
>=20
> list acl {
>   key "acl-type acl-name";
>   ...
> }
> (note this is similar construct to the routing model:=20
>    list routing-protocol {key "type name"... )
>=20
> leaf acl-type {
>   type acl-type;
>   description
>     "Type of access control list. Indicates the primary intended
>      type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)=20
>      used in the list instance.";

What exactly does "primary intended type of match criteria" mean?

How is the ace-type related to the acl-type?  Shouldn't the ace-type-specif=
ic params be conditional (with "when") based on the acl-type?


/martin



> }
>=20
> identity ipv4-acl {
>   base acl:acl-base;
>   description=20
>     "ACL that primarily matches on fields from the IPv4 header
>     (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destina=
tion
>     port).  An acl of type ipv4-acl does not contain matches on fields in
>     the ethernet header or the IPv6 header."; }
>=20
> identity ipv6-acl {
>   base acl:acl-base;
>   description
>     "ACL that primarily matches on fields from the IPv6 header
>     (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destina=
tion
>     port). An acl of type ipv6-acl does not contain matches on fields in
>     the ethernet header or the IPv4 header."; }
>  =20
> identity eth-acl {
>   base acl:acl-base;
>   description
>     "ACL that primarily matches on fields in the ethernet header.
>      An acl of type eth-acl does not contain matches on fields in
>      the IPv4 header, IPv6 header or layer 4 headers."; }
>=20
>=20
> ---------------------------------------
> Potential future augmentation of type:
> ----------------------------------------
>=20
> For future mixed types vendors (or the ietf) could augment the acl-type-b=
ase with types like the following:
>=20
>   identity mixed-l3-acl {
>     base "access-control-list:acl-type-base";
>     description "ACL that contains a mix of entries that primarily match =
on fields=20
>       in IPv4 headers and entries that primarily match on fields in IPv6 =
headers.
>       Matching on layer 4 header fields may also exist in the list.
>       An acl of type mixed-l3-acl does not contain matches on fields in
>       the ethernet header.";
>   }
> =20
>   identity mixed-l2-l3-acl {
>     base "access-control-list:acl-type-base";
>     description "ACL that contains a mix of entries that primarily match =
on fields=20
>       in ethernet headers, entries that primarily match on fields in IPv4=
 headers,
>       and entries that primarily match on fields in IPv6 headers.  Matchi=
ng on layer 4=20
>       header fields may also exist in the list.";
>   }
>=20
> Regards,
> Jason
>=20
> -----Original Message-----
> From: Sterne, Jason (Jason)
> Sent: Sunday, July 19, 2015 12:58
> To: Sterne, Jason (Jason); netmod@ietf.org
> Subject: RE: ACL Model 03 - ACL Type should be mandatory
>=20
> Given the data models below in some of the major implementations it also =
seems like we should also (re-)consider having the 'type' as part of the AC=
L key ("type name"). =20
>=20
> In all those cases below it looks like an operator can currently configur=
e two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the same name/id v=
ia their CLI (e.g. a v4 ACL called "my-acl" and a v6 ACL called "my-acl"). =
=20
>=20
> How would those lists be read in a  via the ietf ACL YANG mod=
ules ?  We'd all have to mangle the names and reserve special names/prefix-=
chars (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them back to a NC client=
.  I'm not sure if there is much of a disadvantage of just having type in t=
he key (assuming it is mandatory as advocated below).
>=20
> I also looked briefly at the Brocade YANG models on github.  It looks lik=
e they have multiple lists as well for v4 vs v6 (and even or different type=
s of normal vs extended ACLs - that could be handled by augmenting the type=
 with a 'v4-extended' type for example).
>=20
> Regards,
> Jason
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne,=20
> Jason (Jason)
> Sent: Friday, July 17, 2015 23:35
> To: netmod@ietf.org
> Subject: [netmod] ACL Model 03 - ACL Type should be mandatory
>=20
> Hi all,
>=20
> I think we need to revisit this discussion about how ACL type works in dr=
aft-ietf-netmod-acl-model-03.
>=20
> It should be mandatory and we should separate v4 from v6.  Vendors can au=
gment for future "mixed" types (or maybe we should make an if-feature for a=
 "mixed" type now that means "anything goes").
>=20
> We should follow existing common implementations for this in order to fos=
ter better adoption.
>=20
> Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of specifying =
the list:
> ipv4 access-list 
> ipv6 access-list 
> =20
> Junos has separate lists for v4 and v6:
> access-list  ...
> ipv6 access-list  ...
> =20
> ALU SR OS has separate lists for v4, v6 and mac:
> config filter ip-filter 
> config filter ipv6-filter 
> config filter mac-filter 
> =20
> Huawei uses separate lists for v4 and v6:
> acl number 3000
> acl ipv6 number 3000
>=20
> Please see below with [>>JTS]
>=20
> Regards,
> Jason
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy=20
> Bierman
> Sent: Monday, June 01, 2015 17:00
> To: Nabil Michraf
> Cc: netmod@ietf.org
> Subject: Re: [netmod] mandatory ACL type (was "comments on=20
> acl-model-02")
>=20
> Hi,
>=20
>=20
> That appears to be the current version on the data-tracker.
> I agree with you that the access-control-list-type leaf should be mandato=
ry.
>=20
> I noticed that the example in Figure 2 has an extra 'top'
> container and the namespace for 'access-lists' is missing.
>=20
>=20
> Andy
>=20
> On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf  =
wrote:
> > Hi all,
> >
> > Can you please clarify if we are talking about=20
> > https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some=20
> > other draft?
> > I just want to make sure I am looking at the right ACL model version.
> >
> > Thank you,
> > Nabil
> >
> > On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair)=20
> > 
> > wrote:
> >>
> >>
> >>
> >> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
> >>  wrote:
> >>
> >> >Hi guys,
> >> >
> >> >Extracting my comments about ACL type into its own thread.  I saw=20
> >> >Martin also had some comments on this topic.
> >> >
> >> >The ACL type was mandatory in an older version of the draft and I=20
> >> >think we should put it back as mandatory.  Implementations that=20
> >> >don't *need* that leaf value can work fine whether they get it=20
> >> >during ACL creation or not but some implementations need to know the =
type.
> >>
> >> We don=B9t want to make the ACL type mandatory because then we have=20
> >> to a create a new type for every combination of match criteria. =20
> >> The model should support any combination of match criteria with=20
> >> typing optional to map to pre-existing implementations.  This is a=20
> >> tradeoff between making the model backward compatible with existing=20
> >> implementations but make it flexible enough so that a new match=20
> >> criteria doesn=B9t require a new type.
>=20
> [>>JTS] We can just create a "mixed" (i.e. unspecified) type and put it u=
nder an if-feature. Existing implementations have a single type (and requir=
e knowing the type at list creation time).
>=20
> >>
> >> >
> >> >It would also be good to create separate identities for=20
> >> >IPv4-access-control-list and IPv6-access-control-list instead of=20
> >> >bundling them into IP-access-control-list. If we're separating=20
> >> >into types in the model it should be the 3 basic types in the base mo=
del:  v4, v6 and enet.
> >>
> >> A vendor specific augmentation/implementation could do this, but=20
> >> the model needs to support inclusion of ipv4 and ipv6 in the same acl.
> >> I=B9m aware of outstanding customers requests for combining ipv4=20
> >> rules and ipv6 rules in the same acl, but most implementations have=20
> >> not caught up to this.  When it comes to managing acls there=20
> >> shouldn=B9t be this distinction between IPv6 and IPv4.  They are both =
IP addresses.
>=20
>=20
> [>>JTS] Again - let's focus on capturing common existing implementations =
in these standard models (while also allowing for augmentation and flexibil=
ity).  V4 and V6 are in separate lists today.  A future mixed list can use =
the "mixed" type or invent a new "v4+v6" type.
>=20
> >>
> >> >
> >> >That would also help if we decide to put some constraints that=20
> >> >allow/disallow certain matching criteria when the type is a=20
> >> >specific value (e.g. don't allow a v6 address match in a v4 list).
> >> >  We'd have to be careful about how those constraints are=20
> >> >formulated though - especially if we want to allow augmentations=20
> >> >of the list-type for "mixed" ACLs. A new "mixed-v4-enet" type=20
> >> >(identity) would also need to use the destination-ipv4-network=20
> >> >matching criteria (can "when" or "must" logic be changed by an augmen=
tation ?  I'm not sure that works).
> >>
> >> Yes, would have to be careful, and defining constraints based on exist=
ing
> >> implementations could be a very slippery slope.   Vendors should be ab=
le
> >> to map to their implementations and/or have a proprietary=20
> >> augmentation that constrains things more according to
> >> their implementation.   Proprietary augmentations could be proposed, a=
nd
> >> reviewed for standardization.
>=20
>=20
> [>>JTS] The draft doesn't have any constraints based on type so I suppose=
 this point is moot.
>=20
> >>
> >> thanks,
> >> Dana
> >>
> >> >
> >> >Regards,
> >> >Jason
> >> >
> >> >
> >> >_______________________________________________
> >> >netmod mailing list
> >> >netmod@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org








> https://www.ietf.org/mailman/listinfo/netmod





































From nobody Mon Sep 21 06:16:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFA81B3187 for ; Mon, 21 Sep 2015 06:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkpm0hQhsVTT for ; Mon, 21 Sep 2015 06:16:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 65BD31B317E for ; Mon, 21 Sep 2015 06:16:36 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 65B9F1AE0988; Mon, 21 Sep 2015 15:16:34 +0200 (CEST)
Date: Mon, 21 Sep 2015 15:16:33 +0200 (CEST)
Message-Id: <20150921.151633.2146306094103248790.mbj@tail-f.com>
To: jason.sterne@alcatel-lucent.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20150921.091357.245840843414433806.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 13:16:40 -0000

"Sterne, Jason (Jason)"  wrote:
> Hi Martin,
> =

> I think you raised those questions before about the model and they ar=
e
> useful to discuss but are they specific to my proposed modification t=
o
> make the type mandatory or do your questions apply equally to the
> current v3 model as-is ?
> =

> We may want to fork off two somewhat independent email threads here:
> 1) making type part of the key (what I hoped to focus on in this emai=
l
> thread)
> 2) use acl-type somehow in some constraints on the ace match criteria=

> (your main point)

I think they are related; if the ace match criteria has no coupling to =
the
acl-type it is not clear to me why the acl-type is needed at all.  And
if there is a coupling, then I agree the acl-type should be part of
the key (or made mandatory).


/martin


> =

> Jason
> =

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com] =

> Sent: Monday, September 21, 2015 3:14
> To: Sterne, Jason (Jason)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
> =

> Hi,
> =

> See below for some clarifying questions.
> =

> =

> "Sterne, Jason (Jason)"  wrote:
> > Hi all,
> > =

> > I met with Dean at IETF93 and we agreed that I should send a specif=
ic =

> > proposal to the list for this.  Here it is:
> > =

> > -----------------------------------------------------
> > Replace the following current snippets from model-03:
> > -----------------------------------------------------
> > =

> > list acl {
> >   key "acl-name";
> >   ...
> > }
> > =

> > leaf acl-type {
> >   type acl-type;
> >   description
> >     "It is recommended to have an Access Control List with
> >      uniform access list entries, all of the same type. When
> >      this type is not explicitly specified, if vendor
> >      implementation permits, the access control entries
> >      in the list can be mixed,
> >      by containing L2, L3 and L4 entries"; }
> > =

> > identity ip-acl {
> >   base acl:acl-base;
> >   description
> >     "IP Access Control List is a common name for lists that contain=

> >      layer 3 and/or layer 4 match conditions."; }
> > =

> > identity eth-acl {
> >   base acl:acl-base;
> >   description
> >     "Ethernet Access Control List is name for layer 2 Ethernet
> >      technology Access Control List types, like 10/100/1000baseT or=

> >      WiFi Access Control List";
> > }
> > =

> > --------------------
> > with the following:
> > --------------------
> > =

> > list acl {
> >   key "acl-type acl-name";
> >   ...
> > }
> > (note this is similar construct to the routing model: =

> >    list routing-protocol {key "type name"... )
> > =

> > leaf acl-type {
> >   type acl-type;
> >   description
> >     "Type of access control list. Indicates the primary intended
> >      type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)=
 =

> >      used in the list instance.";
> =

> What exactly does "primary intended type of match criteria" mean?
> =

> How is the ace-type related to the acl-type?  Shouldn't the
> ace-type-specific params be conditional (with "when") based on the
> acl-type?
> =

> =

> /martin
> =

> =

> =

> > }
> > =

> > identity ipv4-acl {
> >   base acl:acl-base;
> >   description =

> >     "ACL that primarily matches on fields from the IPv4 header
> >     (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
> >     destination
> >     port).  An acl of type ipv4-acl does not contain matches on fie=
lds in
> >     the ethernet header or the IPv6 header."; }
> > =

> > identity ipv6-acl {
> >   base acl:acl-base;
> >   description
> >     "ACL that primarily matches on fields from the IPv6 header
> >     (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
> >     destination
> >     port). An acl of type ipv6-acl does not contain matches on fiel=
ds in
> >     the ethernet header or the IPv4 header."; }
> >   =

> > identity eth-acl {
> >   base acl:acl-base;
> >   description
> >     "ACL that primarily matches on fields in the ethernet header.
> >      An acl of type eth-acl does not contain matches on fields in
> >      the IPv4 header, IPv6 header or layer 4 headers."; }
> > =

> > =

> > ---------------------------------------
> > Potential future augmentation of type:
> > ----------------------------------------
> > =

> > For future mixed types vendors (or the ietf) could augment the
> > acl-type-base with types like the following:
> > =

> >   identity mixed-l3-acl {
> >     base "access-control-list:acl-type-base";
> >     description "ACL that contains a mix of entries that primarily =
match
> >     on fields
> >       in IPv4 headers and entries that primarily match on fields in=
 IPv6
> >       headers.
> >       Matching on layer 4 header fields may also exist in the list.=

> >       An acl of type mixed-l3-acl does not contain matches on field=
s in
> >       the ethernet header.";
> >   }
> >  =

> >   identity mixed-l2-l3-acl {
> >     base "access-control-list:acl-type-base";
> >     description "ACL that contains a mix of entries that primarily =
match
> >     on fields
> >       in ethernet headers, entries that primarily match on fields i=
n IPv4
> >       headers,
> >       and entries that primarily match on fields in IPv6 headers.  =
Matching
> >       on layer 4
> >       header fields may also exist in the list.";
> >   }
> > =

> > Regards,
> > Jason
> > =

> > -----Original Message-----
> > From: Sterne, Jason (Jason)
> > Sent: Sunday, July 19, 2015 12:58
> > To: Sterne, Jason (Jason); netmod@ietf.org
> > Subject: RE: ACL Model 03 - ACL Type should be mandatory
> > =

> > Given the data models below in some of the major implementations it=

> > also seems like we should also (re-)consider having the 'type' as p=
art
> > of the ACL key ("type name").
> > =

> > In all those cases below it looks like an operator can currently
> > configure two different ACLs (e.g. an IPv4 and an IPv6 ACL) with th=
e
> > same name/id via their CLI (e.g. a v4 ACL called "my-acl" and a v6 =
ACL
> > called "my-acl").
> > =

> > How would those lists be read in a  via the ietf ACL YA=
NG
> > modules ?  We'd all have to mangle the names and reserve special
> > names/prefix-chars (e.g. _ipv4-my-acl and _ipv6-my-acl) to send the=
m
> > back to a NC client.  I'm not sure if there is much of a disadvanta=
ge
> > of just having type in the key (assuming it is mandatory as advocat=
ed
> > below).
> > =

> > I also looked briefly at the Brocade YANG models on github.  It loo=
ks
> > like they have multiple lists as well for v4 vs v6 (and even or
> > different types of normal vs extended ACLs - that could be handled =
by
> > augmenting the type with a 'v4-extended' type for example).
> > =

> > Regards,
> > Jason
> > =

> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, =

> > Jason (Jason)
> > Sent: Friday, July 17, 2015 23:35
> > To: netmod@ietf.org
> > Subject: [netmod] ACL Model 03 - ACL Type should be mandatory
> > =

> > Hi all,
> > =

> > I think we need to revisit this discussion about how ACL type works=
 in
> > draft-ietf-netmod-acl-model-03.
> > =

> > It should be mandatory and we should separate v4 from v6.  Vendors =
can
> > augment for future "mixed" types (or maybe we should make an
> > if-feature for a "mixed" type now that means "anything goes").
> > =

> > We should follow existing common implementations for this in order =
to
> > foster better adoption.
> > =

> > Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of
> > specifying the list:
> > ipv4 access-list 
> > ipv6 access-list 
> >  =

> > Junos has separate lists for v4 and v6:
> > access-list  ...
> > ipv6 access-list  ...
> >  =

> > ALU SR OS has separate lists for v4, v6 and mac:
> > config filter ip-filter 
> > config filter ipv6-filter 
> > config filter mac-filter 
> >  =

> > Huawei uses separate lists for v4 and v6:
> > acl number 3000
> > acl ipv6 number 3000
> > =

> > Please see below with [>>JTS]
> > =

> > Regards,
> > Jason
> > =

> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy =

> > Bierman
> > Sent: Monday, June 01, 2015 17:00
> > To: Nabil Michraf
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] mandatory ACL type (was "comments on =

> > acl-model-02")
> > =

> > Hi,
> > =

> > =

> > That appears to be the current version on the data-tracker.
> > I agree with you that the access-control-list-type leaf should be
> > mandatory.
> > =

> > I noticed that the example in Figure 2 has an extra 'top'
> > container and the namespace for 'access-lists' is missing.
> > =

> > =

> > Andy
> > =

> > On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf
> >  wrote:
> > > Hi all,
> > >
> > > Can you please clarify if we are talking about =

> > > https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or som=
e =

> > > other draft?
> > > I just want to make sure I am looking at the right ACL model vers=
ion.
> > >
> > > Thank you,
> > > Nabil
> > >
> > > On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair) =

> > > 
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
> > >>  wrote:
> > >>
> > >> >Hi guys,
> > >> >
> > >> >Extracting my comments about ACL type into its own thread.  I s=
aw =

> > >> >Martin also had some comments on this topic.
> > >> >
> > >> >The ACL type was mandatory in an older version of the draft and=
 I =

> > >> >think we should put it back as mandatory.  Implementations that=
 =

> > >> >don't *need* that leaf value can work fine whether they get it =

> > >> >during ACL creation or not but some implementations need to kno=
w the
> > >> >type.
> > >>
> > >> We don=B9t want to make the ACL type mandatory because then we h=
ave =

> > >> to a create a new type for every combination of match criteria. =
 =

> > >> The model should support any combination of match criteria with =

> > >> typing optional to map to pre-existing implementations.  This is=
 a =

> > >> tradeoff between making the model backward compatible with exist=
ing =

> > >> implementations but make it flexible enough so that a new match =

> > >> criteria doesn=B9t require a new type.
> > =

> > [>>JTS] We can just create a "mixed" (i.e. unspecified) type and pu=
t
> > it under an if-feature. Existing implementations have a single type=

> > (and require knowing the type at list creation time).
> > =

> > >>
> > >> >
> > >> >It would also be good to create separate identities for =

> > >> >IPv4-access-control-list and IPv6-access-control-list instead o=
f =

> > >> >bundling them into IP-access-control-list. If we're separating =

> > >> >into types in the model it should be the 3 basic types in the b=
ase
> > >> >model: v4, v6 and enet.
> > >>
> > >> A vendor specific augmentation/implementation could do this, but=
 =

> > >> the model needs to support inclusion of ipv4 and ipv6 in the sam=
e acl.
> > >> I=B9m aware of outstanding customers requests for combining ipv4=
 =

> > >> rules and ipv6 rules in the same acl, but most implementations h=
ave =

> > >> not caught up to this.  When it comes to managing acls there =

> > >> shouldn=B9t be this distinction between IPv6 and IPv4.  They are=
 both IP
> > >> addresses.
> > =

> > =

> > [>>JTS] Again - let's focus on capturing common existing
> > implementations in these standard models (while also allowing for
> > augmentation and flexibility).  V4 and V6 are in separate lists tod=
ay.
> > A future mixed list can use the "mixed" type or invent a new "v4+v6=
"
> > type.
> > =

> > >>
> > >> >
> > >> >That would also help if we decide to put some constraints that =

> > >> >allow/disallow certain matching criteria when the type is a =

> > >> >specific value (e.g. don't allow a v6 address match in a v4 lis=
t).
> > >> >  We'd have to be careful about how those constraints are =

> > >> >formulated though - especially if we want to allow augmentation=
s =

> > >> >of the list-type for "mixed" ACLs. A new "mixed-v4-enet" type =

> > >> >(identity) would also need to use the destination-ipv4-network =

> > >> >matching criteria (can "when" or "must" logic be changed by an
> > >> >augmentation ?  I'm not sure that works).
> > >>
> > >> Yes, would have to be careful, and defining constraints based on=

> > >> existing
> > >> implementations could be a very slippery slope.  Vendors should =
be
> > >> able
> > >> to map to their implementations and/or have a proprietary =

> > >> augmentation that constrains things more according to
> > >> their implementation.  Proprietary augmentations could be propos=
ed,
> > >> and
> > >> reviewed for standardization.
> > =

> > =

> > [>>JTS] The draft doesn't have any constraints based on type so I
> > suppose this point is moot.
> > =

> > >>
> > >> thanks,
> > >> Dana
> > >>
> > >> >
> > >> >Regards,
> > >> >Jason
> > >> >
> > >> >
> > >> >_______________________________________________
> > >> >netmod mailing list
> > >> >netmod@ietf.org
> > >> >https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > =

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

> =

> =

> =

> =

> =

> =

> =

> > https://www.ietf.org/mailman/listinfo/netmod
> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =

> =


From nobody Mon Sep 21 07:23:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1AF1B321E for ; Mon, 21 Sep 2015 07:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SCLLAthgSQ0 for ; Mon, 21 Sep 2015 07:23:42 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E8C441B321C for ; Mon, 21 Sep 2015 07:23:41 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3AE0B1CC00A3; Mon, 21 Sep 2015 16:23:47 +0200 (CEST)
From: Ladislav Lhotka 
To: "Sterne\, Jason \(Jason\)" , "netmod\@ietf.org" 
In-Reply-To: 
References:       
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 21 Sep 2015 16:23:21 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 14:23:46 -0000

"Sterne, Jason (Jason)"  writes:

> Hi all,
>
> I met with Dean at IETF93 and we agreed that I should send a specific pro=
posal to the list for this.  Here it is:
>
> -----------------------------------------------------
> Replace the following current snippets from model-03:
> -----------------------------------------------------
>
> list acl {
>   key "acl-name";
>   ...
> }
>
> leaf acl-type {
>   type acl-type;
>   description
>     "It is recommended to have an Access Control List with
>      uniform access list entries, all of the same type. When
>      this type is not explicitly specified, if vendor
>      implementation permits, the access control entries
>      in the list can be mixed,
>      by containing L2, L3 and L4 entries";
> }
>
> identity ip-acl {
>   base acl:acl-base;
>   description
>     "IP Access Control List is a common name for lists that contain
>      layer 3 and/or layer 4 match conditions.";
> }
>
> identity eth-acl {
>   base acl:acl-base;
>   description
>     "Ethernet Access Control List is name for layer 2 Ethernet
>      technology Access Control List types, like 10/100/1000baseT or
>      WiFi Access Control List";
> }
>
> --------------------=20=20
> with the following:
> --------------------
>
> list acl {
>   key "acl-type acl-name";
>   ...
> }
> (note this is similar construct to the routing model:=20
>    list routing-protocol {key "type name"... )

Well, originally we had "name" as the only key but some routing folks
insisted on having "type" as the second key. Personally, I am not
entirely sold to this idea.

The thing is: YANG requires config lists to have keys but it doesn't
mean these keys need to be the same as parameters that are understood as
keys in a CLI.

One advantage of having YANG list keys separate from "public" keys is
that a user is free to change the public keys, and it also doesn't break
any internal references in the configuration. If you have "acl-type" and
"acl-name" as YANG list keys, then they cannot be changed.

So in fact I'd suggest to have an opaque ID as the only list key, and
then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
unique constraint.

Lada

>
> leaf acl-type {
>   type acl-type;
>   description
>     "Type of access control list. Indicates the primary intended
>      type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)=20
>      used in the list instance.";
> }
>
> identity ipv4-acl {
>   base acl:acl-base;
>   description=20
>     "ACL that primarily matches on fields from the IPv4 header
>     (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destina=
tion
>     port).  An acl of type ipv4-acl does not contain matches on fields in
>     the ethernet header or the IPv6 header.";
> }
>
> identity ipv6-acl {
>   base acl:acl-base;
>   description
>     "ACL that primarily matches on fields from the IPv6 header
>     (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destina=
tion
>     port). An acl of type ipv6-acl does not contain matches on fields in
>     the ethernet header or the IPv4 header.";
> }
>=20=20=20
> identity eth-acl {
>   base acl:acl-base;
>   description
>     "ACL that primarily matches on fields in the ethernet header.
>      An acl of type eth-acl does not contain matches on fields in
>      the IPv4 header, IPv6 header or layer 4 headers.";
> }
>
>
> ---------------------------------------
> Potential future augmentation of type:
> ----------------------------------------
>
> For future mixed types vendors (or the ietf) could augment the acl-type-b=
ase with types like the following:
>
>   identity mixed-l3-acl {
>     base "access-control-list:acl-type-base";
>     description "ACL that contains a mix of entries that primarily match =
on fields=20
>       in IPv4 headers and entries that primarily match on fields in IPv6 =
headers.
>       Matching on layer 4 header fields may also exist in the list.
>       An acl of type mixed-l3-acl does not contain matches on fields in
>       the ethernet header.";
>   }
>=20=20
>   identity mixed-l2-l3-acl {
>     base "access-control-list:acl-type-base";
>     description "ACL that contains a mix of entries that primarily match =
on fields=20
>       in ethernet headers, entries that primarily match on fields in IPv4=
 headers,
>       and entries that primarily match on fields in IPv6 headers.  Matchi=
ng on layer 4=20
>       header fields may also exist in the list.";
>   }
>
> Regards,
> Jason
>
> -----Original Message-----
> From: Sterne, Jason (Jason)=20
> Sent: Sunday, July 19, 2015 12:58
> To: Sterne, Jason (Jason); netmod@ietf.org
> Subject: RE: ACL Model 03 - ACL Type should be mandatory
>
> Given the data models below in some of the major implementations it also =
seems like we should also (re-)consider having the 'type' as part of the AC=
L key ("type name").=20=20
>
> In all those cases below it looks like an operator can currently configur=
e two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the same name/id v=
ia their CLI (e.g. a v4 ACL called "my-acl" and a v6 ACL called "my-acl").=
=20=20
>
> How would those lists be read in a  via the ietf ACL YANG mod=
ules ?  We'd all have to mangle the names and reserve special names/prefix-=
chars (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them back to a NC client=
.  I'm not sure if there is much of a disadvantage of just having type in t=
he key (assuming it is mandatory as advocated below).
>
> I also looked briefly at the Brocade YANG models on github.  It looks lik=
e they have multiple lists as well for v4 vs v6 (and even or different type=
s of normal vs extended ACLs - that could be handled by augmenting the type=
 with a 'v4-extended' type for example).
>
> Regards,
> Jason
>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason =
(Jason)
> Sent: Friday, July 17, 2015 23:35
> To: netmod@ietf.org
> Subject: [netmod] ACL Model 03 - ACL Type should be mandatory
>
> Hi all,
>
> I think we need to revisit this discussion about how ACL type works in dr=
aft-ietf-netmod-acl-model-03.
>
> It should be mandatory and we should separate v4 from v6.  Vendors can au=
gment for future "mixed" types (or maybe we should make an if-feature for a=
 "mixed" type now that means "anything goes").
>
> We should follow existing common implementations for this in order to fos=
ter better adoption.
>
> Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of specifying =
the list:
> ipv4 access-list 
> ipv6 access-list 
>=20=20
> Junos has separate lists for v4 and v6:
> access-list  ...
> ipv6 access-list  ...
>=20=20
> ALU SR OS has separate lists for v4, v6 and mac:
> config filter ip-filter 
> config filter ipv6-filter 
> config filter mac-filter 
>=20=20
> Huawei uses separate lists for v4 and v6:
> acl number 3000
> acl ipv6 number 3000
>
> Please see below with [>>JTS]
>
> Regards,
> Jason
>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: Monday, June 01, 2015 17:00
> To: Nabil Michraf
> Cc: netmod@ietf.org
> Subject: Re: [netmod] mandatory ACL type (was "comments on acl-model-02")
>
> Hi,
>
>
> That appears to be the current version on the data-tracker.
> I agree with you that the access-control-list-type leaf should be mandato=
ry.
>
> I noticed that the example in Figure 2 has an extra 'top'
> container and the namespace for 'access-lists' is missing.
>
>
> Andy
>
> On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf  =
wrote:
>> Hi all,
>>
>> Can you please clarify if we are talking about=20
>> https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some=20
>> other draft?
>> I just want to make sure I am looking at the right ACL model version.
>>
>> Thank you,
>> Nabil
>>
>> On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair) 
>> wrote:
>>>
>>>
>>>
>>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
>>>  wrote:
>>>
>>> >Hi guys,
>>> >
>>> >Extracting my comments about ACL type into its own thread.  I saw=20
>>> >Martin also had some comments on this topic.
>>> >
>>> >The ACL type was mandatory in an older version of the draft and I=20
>>> >think we should put it back as mandatory.  Implementations that=20
>>> >don't *need* that leaf value can work fine whether they get it=20
>>> >during ACL creation or not but some implementations need to know the t=
ype.
>>>
>>> We don=C2=B9t want to make the ACL type mandatory because then we have =
to=20
>>> a create a new type for every combination of match criteria.  The=20
>>> model should support any combination of match criteria with typing=20
>>> optional to map to pre-existing implementations.  This is a tradeoff=20
>>> between making the model backward compatible with existing=20
>>> implementations but make it flexible enough so that a new match=20
>>> criteria doesn=C2=B9t require a new type.
>
> [>>JTS] We can just create a "mixed" (i.e. unspecified) type and put it u=
nder an if-feature. Existing implementations have a single type (and requir=
e knowing the type at list creation time).
>
>>>
>>> >
>>> >It would also be good to create separate identities for=20
>>> >IPv4-access-control-list and IPv6-access-control-list instead of=20
>>> >bundling them into IP-access-control-list. If we're separating into=20
>>> >types in the model it should be the 3 basic types in the base model:  =
v4, v6 and enet.
>>>
>>> A vendor specific augmentation/implementation could do this, but the=20
>>> model needs to support inclusion of ipv4 and ipv6 in the same acl.
>>> I=C2=B9m aware of outstanding customers requests for combining ipv4 rul=
es=20
>>> and ipv6 rules in the same acl, but most implementations have not=20
>>> caught up to this.  When it comes to managing acls there shouldn=C2=B9t=
 be=20
>>> this distinction between IPv6 and IPv4.  They are both IP addresses.
>
>
> [>>JTS] Again - let's focus on capturing common existing implementations =
in these standard models (while also allowing for augmentation and flexibil=
ity).  V4 and V6 are in separate lists today.  A future mixed list can use =
the "mixed" type or invent a new "v4+v6" type.
>
>>>
>>> >
>>> >That would also help if we decide to put some constraints that=20
>>> >allow/disallow certain matching criteria when the type is a specific=20
>>> >value (e.g. don't allow a v6 address match in a v4 list).
>>> >  We'd have to be careful about how those constraints are formulated=20
>>> >though - especially if we want to allow augmentations of the=20
>>> >list-type for "mixed" ACLs. A new "mixed-v4-enet" type (identity)=20
>>> >would also need to use the destination-ipv4-network matching=20
>>> >criteria (can "when" or "must" logic be changed by an augmentation ?  =
I'm not sure that works).
>>>
>>> Yes, would have to be careful, and defining constraints based on existi=
ng
>>> implementations could be a very slippery slope.   Vendors should be able
>>> to map to their implementations and/or have a proprietary=20
>>> augmentation that constrains things more according to
>>> their implementation.   Proprietary augmentations could be proposed, and
>>> reviewed for standardization.
>
>
> [>>JTS] The draft doesn't have any constraints based on type so I suppose=
 this point is moot.
>
>>>
>>> thanks,
>>> Dana
>>>
>>> >
>>> >Regards,
>>> >Jason
>>> >
>>> >
>>> >_______________________________________________
>>> >netmod mailing list
>>> >netmod@ietf.org
>>> >https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon Sep 21 07:50:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A031B3248 for ; Mon, 21 Sep 2015 07:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kc2MIYoDrME for ; Mon, 21 Sep 2015 07:50:37 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6679D1B3260 for ; Mon, 21 Sep 2015 07:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18470; q=dns/txt; s=iport; t=1442847037; x=1444056637; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z6rs3YS56pu1xFd3txghtS2GpsuV1hOMnX9AkZxehKY=; b=jFdrw6CYkNgsKKC+EcaGaHr0VRWFS/SVn2MRWlRp5VgXyQxOt1Mir71C fVANXJ5mkiDN6S1EgYJK/rPKJJtmMhiWpGXFziKZfDBoZsg3nrbup0GZv 0u4K0uGfmBXOH4pPiB18K/i7pT5I0ziltTqMzWYdJWu1DSjAcZrRUnLva s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DzAQD4GABW/4cNJK1UCYMkVGkGvT8BDYFxCoUvSgIcgRk4FAEBAQEBAQGBCoQjAQEBAwEBAQEgEToXBAIBCBEEAQEBAgIjAwICAh8GCxQBCAgCBAESiBkDCggNtlOPBA2EagEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKToJQgWEpGCIGgmOBQwWHNIVJiGcBh36DGoFugU2ENYMhijiHPx8BAUKEAXEBiGeBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,568,1437436800"; d="scan'208";a="189757632"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 21 Sep 2015 14:50:24 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8LEoNr2030586 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 14:50:23 GMT
Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 09:50:22 -0500
Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-aln-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 21 Sep 2015 09:50:22 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 09:50:22 -0500
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "Sterne, Jason (Jason)" , "netmod@ietf.org" 
Thread-Topic: [netmod] ACL Model 03 - ACL Type should be mandatory
Thread-Index: AQHQnK3+1WRBFqzUuEu69dSP2qQCIp3gdK+QgAK8bbCAY1hsMIABgxCA///EewA=
Date: Mon, 21 Sep 2015 14:50:21 +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: [173.36.7.24]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8C80BB29B4025F4098388730376434C0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 14:50:46 -0000

DQoNCk9uIDkvMjEvMTUsIDEwOjIzIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBM
aG90a2EiDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMu
Y3o+IHdyb3RlOg0KDQo+IlN0ZXJuZSwgSmFzb24gKEphc29uKSIgPGphc29uLnN0ZXJuZUBhbGNh
dGVsLWx1Y2VudC5jb20+IHdyaXRlczoNCj4NCj4+IEhpIGFsbCwNCj4+DQo+PiBJIG1ldCB3aXRo
IERlYW4gYXQgSUVURjkzIGFuZCB3ZSBhZ3JlZWQgdGhhdCBJIHNob3VsZCBzZW5kIGEgc3BlY2lm
aWMNCj4+cHJvcG9zYWwgdG8gdGhlIGxpc3QgZm9yIHRoaXMuICBIZXJlIGl0IGlzOg0KPj4NCj4+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+
PiBSZXBsYWNlIHRoZSBmb2xsb3dpbmcgY3VycmVudCBzbmlwcGV0cyBmcm9tIG1vZGVsLTAzOg0K
Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cj4+DQo+PiBsaXN0IGFjbCB7DQo+PiAgIGtleSAiYWNsLW5hbWUiOw0KPj4gICAuLi4NCj4+IH0N
Cj4+DQo+PiBsZWFmIGFjbC10eXBlIHsNCj4+ICAgdHlwZSBhY2wtdHlwZTsNCj4+ICAgZGVzY3Jp
cHRpb24NCj4+ICAgICAiSXQgaXMgcmVjb21tZW5kZWQgdG8gaGF2ZSBhbiBBY2Nlc3MgQ29udHJv
bCBMaXN0IHdpdGgNCj4+ICAgICAgdW5pZm9ybSBhY2Nlc3MgbGlzdCBlbnRyaWVzLCBhbGwgb2Yg
dGhlIHNhbWUgdHlwZS4gV2hlbg0KPj4gICAgICB0aGlzIHR5cGUgaXMgbm90IGV4cGxpY2l0bHkg
c3BlY2lmaWVkLCBpZiB2ZW5kb3INCj4+ICAgICAgaW1wbGVtZW50YXRpb24gcGVybWl0cywgdGhl
IGFjY2VzcyBjb250cm9sIGVudHJpZXMNCj4+ICAgICAgaW4gdGhlIGxpc3QgY2FuIGJlIG1peGVk
LA0KPj4gICAgICBieSBjb250YWluaW5nIEwyLCBMMyBhbmQgTDQgZW50cmllcyI7DQo+PiB9DQo+
Pg0KPj4gaWRlbnRpdHkgaXAtYWNsIHsNCj4+ICAgYmFzZSBhY2w6YWNsLWJhc2U7DQo+PiAgIGRl
c2NyaXB0aW9uDQo+PiAgICAgIklQIEFjY2VzcyBDb250cm9sIExpc3QgaXMgYSBjb21tb24gbmFt
ZSBmb3IgbGlzdHMgdGhhdCBjb250YWluDQo+PiAgICAgIGxheWVyIDMgYW5kL29yIGxheWVyIDQg
bWF0Y2ggY29uZGl0aW9ucy4iOw0KPj4gfQ0KPj4NCj4+IGlkZW50aXR5IGV0aC1hY2wgew0KPj4g
ICBiYXNlIGFjbDphY2wtYmFzZTsNCj4+ICAgZGVzY3JpcHRpb24NCj4+ICAgICAiRXRoZXJuZXQg
QWNjZXNzIENvbnRyb2wgTGlzdCBpcyBuYW1lIGZvciBsYXllciAyIEV0aGVybmV0DQo+PiAgICAg
IHRlY2hub2xvZ3kgQWNjZXNzIENvbnRyb2wgTGlzdCB0eXBlcywgbGlrZSAxMC8xMDAvMTAwMGJh
c2VUIG9yDQo+PiAgICAgIFdpRmkgQWNjZXNzIENvbnRyb2wgTGlzdCI7DQo+PiB9DQo+Pg0KPj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IHdpdGggdGhlIGZvbGxvd2luZzoNCj4+IC0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+Pg0KPj4gbGlzdCBhY2wgew0KPj4gICBrZXkgImFjbC10eXBlIGFjbC1u
YW1lIjsNCj4+ICAgLi4uDQo+PiB9DQo+PiAobm90ZSB0aGlzIGlzIHNpbWlsYXIgY29uc3RydWN0
IHRvIHRoZSByb3V0aW5nIG1vZGVsOg0KPj4gICAgbGlzdCByb3V0aW5nLXByb3RvY29sIHtrZXkg
InR5cGUgbmFtZSIuLi4gKQ0KPg0KPldlbGwsIG9yaWdpbmFsbHkgd2UgaGFkICJuYW1lIiBhcyB0
aGUgb25seSBrZXkgYnV0IHNvbWUgcm91dGluZyBmb2xrcw0KPmluc2lzdGVkIG9uIGhhdmluZyAi
dHlwZSIgYXMgdGhlIHNlY29uZCBrZXkuIFBlcnNvbmFsbHksIEkgYW0gbm90DQo+ZW50aXJlbHkg
c29sZCB0byB0aGlzIGlkZWEuDQoNCldoeSBub3Q/IEV4aXN0aW5nIHByb2R1Y3RzIHN1cHBvcnQg
dGhlc2Ugc2VtYW50aWNz4oCmIERpZmZlcmVudCB0eXBlcyBvZg0KYWNjZXNzLWxpc3Qgc2hvdWxk
IGhhdmUgaW5kZXBlbmRlbnQgbmFtZSBzcGFjZXMgKGkuZS4sIG9uZSBzaG91bGQgYmUgYWJsZQ0K
dG8gaGF2ZSBhbiBJUCBBQ0wgbmFtZWQgZm9vLCBhbiBJUHY2IEFDTCBuYW1lZCBmb28sIGFuZCBh
IEwyIEFDTCBuYW1lZA0KZm9vKS4gDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQoNCg0KPg0KPlRo
ZSB0aGluZyBpczogWUFORyByZXF1aXJlcyBjb25maWcgbGlzdHMgdG8gaGF2ZSBrZXlzIGJ1dCBp
dCBkb2Vzbid0DQo+bWVhbiB0aGVzZSBrZXlzIG5lZWQgdG8gYmUgdGhlIHNhbWUgYXMgcGFyYW1l
dGVycyB0aGF0IGFyZSB1bmRlcnN0b29kIGFzDQo+a2V5cyBpbiBhIENMSS4NCj4NCj5PbmUgYWR2
YW50YWdlIG9mIGhhdmluZyBZQU5HIGxpc3Qga2V5cyBzZXBhcmF0ZSBmcm9tICJwdWJsaWMiIGtl
eXMgaXMNCj50aGF0IGEgdXNlciBpcyBmcmVlIHRvIGNoYW5nZSB0aGUgcHVibGljIGtleXMsIGFu
ZCBpdCBhbHNvIGRvZXNuJ3QgYnJlYWsNCj5hbnkgaW50ZXJuYWwgcmVmZXJlbmNlcyBpbiB0aGUg
Y29uZmlndXJhdGlvbi4gSWYgeW91IGhhdmUgImFjbC10eXBlIiBhbmQNCj4iYWNsLW5hbWUiIGFz
IFlBTkcgbGlzdCBrZXlzLCB0aGVuIHRoZXkgY2Fubm90IGJlIGNoYW5nZWQuDQo+DQo+U28gaW4g
ZmFjdCBJJ2Qgc3VnZ2VzdCB0byBoYXZlIGFuIG9wYXF1ZSBJRCBhcyB0aGUgb25seSBsaXN0IGtl
eSwgYW5kDQo+dGhlbiAiYWNsLW5hbWUiIGFuZCAiYWNsLXR5cGUiIGFzIG5vbi1rZXkgbGVhZnMs
IHBlcmhhcHMgc3ViamVjdCB0byBhDQo+dW5pcXVlIGNvbnN0cmFpbnQuDQo+DQo+TGFkYQ0KPg0K
Pj4NCj4+IGxlYWYgYWNsLXR5cGUgew0KPj4gICB0eXBlIGFjbC10eXBlOw0KPj4gICBkZXNjcmlw
dGlvbg0KPj4gICAgICJUeXBlIG9mIGFjY2VzcyBjb250cm9sIGxpc3QuIEluZGljYXRlcyB0aGUg
cHJpbWFyeSBpbnRlbmRlZA0KPj4gICAgICB0eXBlIG9mIG1hdGNoIGNyaXRlcmlhIChlLmcuIGV0
aGVybmV0LCBJUHY0LCBJUHY2LCBtaXhlZCwgZXRjKQ0KPj4gICAgICB1c2VkIGluIHRoZSBsaXN0
IGluc3RhbmNlLiI7DQo+PiB9DQo+Pg0KPj4gaWRlbnRpdHkgaXB2NC1hY2wgew0KPj4gICBiYXNl
IGFjbDphY2wtYmFzZTsNCj4+ICAgZGVzY3JpcHRpb24gDQo+PiAgICAgIkFDTCB0aGF0IHByaW1h
cmlseSBtYXRjaGVzIG9uIGZpZWxkcyBmcm9tIHRoZSBJUHY0IGhlYWRlcg0KPj4gICAgIChlLmcu
IElQdjQgZGVzdGluYXRpb24gYWRkcmVzcykgYW5kIGxheWVyIDQgaGVhZGVycyAoZS5nLiBUQ1AN
Cj4+ZGVzdGluYXRpb24NCj4+ICAgICBwb3J0KS4gIEFuIGFjbCBvZiB0eXBlIGlwdjQtYWNsIGRv
ZXMgbm90IGNvbnRhaW4gbWF0Y2hlcyBvbiBmaWVsZHMNCj4+aW4NCj4+ICAgICB0aGUgZXRoZXJu
ZXQgaGVhZGVyIG9yIHRoZSBJUHY2IGhlYWRlci4iOw0KPj4gfQ0KPj4NCj4+IGlkZW50aXR5IGlw
djYtYWNsIHsNCj4+ICAgYmFzZSBhY2w6YWNsLWJhc2U7DQo+PiAgIGRlc2NyaXB0aW9uDQo+PiAg
ICAgIkFDTCB0aGF0IHByaW1hcmlseSBtYXRjaGVzIG9uIGZpZWxkcyBmcm9tIHRoZSBJUHY2IGhl
YWRlcg0KPj4gICAgIChlLmcuIElQdjYgZGVzdGluYXRpb24gYWRkcmVzcykgYW5kIGxheWVyIDQg
aGVhZGVycyAoZS5nLiBUQ1ANCj4+ZGVzdGluYXRpb24NCj4+ICAgICBwb3J0KS4gQW4gYWNsIG9m
IHR5cGUgaXB2Ni1hY2wgZG9lcyBub3QgY29udGFpbiBtYXRjaGVzIG9uIGZpZWxkcyBpbg0KPj4g
ICAgIHRoZSBldGhlcm5ldCBoZWFkZXIgb3IgdGhlIElQdjQgaGVhZGVyLiI7DQo+PiB9DQo+PiAg
IA0KPj4gaWRlbnRpdHkgZXRoLWFjbCB7DQo+PiAgIGJhc2UgYWNsOmFjbC1iYXNlOw0KPj4gICBk
ZXNjcmlwdGlvbg0KPj4gICAgICJBQ0wgdGhhdCBwcmltYXJpbHkgbWF0Y2hlcyBvbiBmaWVsZHMg
aW4gdGhlIGV0aGVybmV0IGhlYWRlci4NCj4+ICAgICAgQW4gYWNsIG9mIHR5cGUgZXRoLWFjbCBk
b2VzIG5vdCBjb250YWluIG1hdGNoZXMgb24gZmllbGRzIGluDQo+PiAgICAgIHRoZSBJUHY0IGhl
YWRlciwgSVB2NiBoZWFkZXIgb3IgbGF5ZXIgNCBoZWFkZXJzLiI7DQo+PiB9DQo+Pg0KPj4NCj4+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gUG90ZW50aWFsIGZ1
dHVyZSBhdWdtZW50YXRpb24gb2YgdHlwZToNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBGb3IgZnV0dXJlIG1peGVkIHR5cGVzIHZlbmRvcnMgKG9y
IHRoZSBpZXRmKSBjb3VsZCBhdWdtZW50IHRoZQ0KPj5hY2wtdHlwZS1iYXNlIHdpdGggdHlwZXMg
bGlrZSB0aGUgZm9sbG93aW5nOg0KPj4NCj4+ICAgaWRlbnRpdHkgbWl4ZWQtbDMtYWNsIHsNCj4+
ICAgICBiYXNlICJhY2Nlc3MtY29udHJvbC1saXN0OmFjbC10eXBlLWJhc2UiOw0KPj4gICAgIGRl
c2NyaXB0aW9uICJBQ0wgdGhhdCBjb250YWlucyBhIG1peCBvZiBlbnRyaWVzIHRoYXQgcHJpbWFy
aWx5DQo+Pm1hdGNoIG9uIGZpZWxkcyANCj4+ICAgICAgIGluIElQdjQgaGVhZGVycyBhbmQgZW50
cmllcyB0aGF0IHByaW1hcmlseSBtYXRjaCBvbiBmaWVsZHMgaW4NCj4+SVB2NiBoZWFkZXJzLg0K
Pj4gICAgICAgTWF0Y2hpbmcgb24gbGF5ZXIgNCBoZWFkZXIgZmllbGRzIG1heSBhbHNvIGV4aXN0
IGluIHRoZSBsaXN0Lg0KPj4gICAgICAgQW4gYWNsIG9mIHR5cGUgbWl4ZWQtbDMtYWNsIGRvZXMg
bm90IGNvbnRhaW4gbWF0Y2hlcyBvbiBmaWVsZHMgaW4NCj4+ICAgICAgIHRoZSBldGhlcm5ldCBo
ZWFkZXIuIjsNCj4+ICAgfQ0KPj4gIA0KPj4gICBpZGVudGl0eSBtaXhlZC1sMi1sMy1hY2wgew0K
Pj4gICAgIGJhc2UgImFjY2Vzcy1jb250cm9sLWxpc3Q6YWNsLXR5cGUtYmFzZSI7DQo+PiAgICAg
ZGVzY3JpcHRpb24gIkFDTCB0aGF0IGNvbnRhaW5zIGEgbWl4IG9mIGVudHJpZXMgdGhhdCBwcmlt
YXJpbHkNCj4+bWF0Y2ggb24gZmllbGRzIA0KPj4gICAgICAgaW4gZXRoZXJuZXQgaGVhZGVycywg
ZW50cmllcyB0aGF0IHByaW1hcmlseSBtYXRjaCBvbiBmaWVsZHMgaW4NCj4+SVB2NCBoZWFkZXJz
LA0KPj4gICAgICAgYW5kIGVudHJpZXMgdGhhdCBwcmltYXJpbHkgbWF0Y2ggb24gZmllbGRzIGlu
IElQdjYgaGVhZGVycy4NCj4+TWF0Y2hpbmcgb24gbGF5ZXIgNA0KPj4gICAgICAgaGVhZGVyIGZp
ZWxkcyBtYXkgYWxzbyBleGlzdCBpbiB0aGUgbGlzdC4iOw0KPj4gICB9DQo+Pg0KPj4gUmVnYXJk
cywNCj4+IEphc29uDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206
IFN0ZXJuZSwgSmFzb24gKEphc29uKQ0KPj4gU2VudDogU3VuZGF5LCBKdWx5IDE5LCAyMDE1IDEy
OjU4DQo+PiBUbzogU3Rlcm5lLCBKYXNvbiAoSmFzb24pOyBuZXRtb2RAaWV0Zi5vcmcNCj4+IFN1
YmplY3Q6IFJFOiBBQ0wgTW9kZWwgMDMgLSBBQ0wgVHlwZSBzaG91bGQgYmUgbWFuZGF0b3J5DQo+
Pg0KPj4gR2l2ZW4gdGhlIGRhdGEgbW9kZWxzIGJlbG93IGluIHNvbWUgb2YgdGhlIG1ham9yIGlt
cGxlbWVudGF0aW9ucyBpdA0KPj5hbHNvIHNlZW1zIGxpa2Ugd2Ugc2hvdWxkIGFsc28gKHJlLSlj
b25zaWRlciBoYXZpbmcgdGhlICd0eXBlJyBhcyBwYXJ0DQo+Pm9mIHRoZSBBQ0wga2V5ICgidHlw
ZSBuYW1lIikuDQo+Pg0KPj4gSW4gYWxsIHRob3NlIGNhc2VzIGJlbG93IGl0IGxvb2tzIGxpa2Ug
YW4gb3BlcmF0b3IgY2FuIGN1cnJlbnRseQ0KPj5jb25maWd1cmUgdHdvIGRpZmZlcmVudCBBQ0xz
IChlLmcuIGFuIElQdjQgYW5kIGFuIElQdjYgQUNMKSB3aXRoIHRoZQ0KPj5zYW1lIG5hbWUvaWQg
dmlhIHRoZWlyIENMSSAoZS5nLiBhIHY0IEFDTCBjYWxsZWQgIm15LWFjbCIgYW5kIGEgdjYgQUNM
DQo+PmNhbGxlZCAibXktYWNsIikuDQo+Pg0KPj4gSG93IHdvdWxkIHRob3NlIGxpc3RzIGJlIHJl
YWQgaW4gYSA8Z2V0LWNvbmZpZz4gdmlhIHRoZSBpZXRmIEFDTCBZQU5HDQo+Pm1vZHVsZXMgPyAg
V2UnZCBhbGwgaGF2ZSB0byBtYW5nbGUgdGhlIG5hbWVzIGFuZCByZXNlcnZlIHNwZWNpYWwNCj4+
bmFtZXMvcHJlZml4LWNoYXJzIChlLmcuIF9pcHY0LW15LWFjbCBhbmQgX2lwdjYtbXktYWNsKSB0
byBzZW5kIHRoZW0NCj4+YmFjayB0byBhIE5DIGNsaWVudC4gIEknbSBub3Qgc3VyZSBpZiB0aGVy
ZSBpcyBtdWNoIG9mIGEgZGlzYWR2YW50YWdlIG9mDQo+Pmp1c3QgaGF2aW5nIHR5cGUgaW4gdGhl
IGtleSAoYXNzdW1pbmcgaXQgaXMgbWFuZGF0b3J5IGFzIGFkdm9jYXRlZA0KPj5iZWxvdykuDQo+
Pg0KPj4gSSBhbHNvIGxvb2tlZCBicmllZmx5IGF0IHRoZSBCcm9jYWRlIFlBTkcgbW9kZWxzIG9u
IGdpdGh1Yi4gIEl0IGxvb2tzDQo+Pmxpa2UgdGhleSBoYXZlIG11bHRpcGxlIGxpc3RzIGFzIHdl
bGwgZm9yIHY0IHZzIHY2IChhbmQgZXZlbiBvcg0KPj5kaWZmZXJlbnQgdHlwZXMgb2Ygbm9ybWFs
IHZzIGV4dGVuZGVkIEFDTHMgLSB0aGF0IGNvdWxkIGJlIGhhbmRsZWQgYnkNCj4+YXVnbWVudGlu
ZyB0aGUgdHlwZSB3aXRoIGEgJ3Y0LWV4dGVuZGVkJyB0eXBlIGZvciBleGFtcGxlKS4NCj4+DQo+
PiBSZWdhcmRzLA0KPj4gSmFzb24NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
Pj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBTdGVybmUsDQo+Pkphc29uIChKYXNvbikNCj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxNywg
MjAxNSAyMzozNQ0KPj4gVG86IG5ldG1vZEBpZXRmLm9yZw0KPj4gU3ViamVjdDogW25ldG1vZF0g
QUNMIE1vZGVsIDAzIC0gQUNMIFR5cGUgc2hvdWxkIGJlIG1hbmRhdG9yeQ0KPj4NCj4+IEhpIGFs
bCwNCj4+DQo+PiBJIHRoaW5rIHdlIG5lZWQgdG8gcmV2aXNpdCB0aGlzIGRpc2N1c3Npb24gYWJv
dXQgaG93IEFDTCB0eXBlIHdvcmtzIGluDQo+PmRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0w
My4NCj4+DQo+PiBJdCBzaG91bGQgYmUgbWFuZGF0b3J5IGFuZCB3ZSBzaG91bGQgc2VwYXJhdGUg
djQgZnJvbSB2Ni4gIFZlbmRvcnMgY2FuDQo+PmF1Z21lbnQgZm9yIGZ1dHVyZSAibWl4ZWQiIHR5
cGVzIChvciBtYXliZSB3ZSBzaG91bGQgbWFrZSBhbiBpZi1mZWF0dXJlDQo+PmZvciBhICJtaXhl
ZCIgdHlwZSBub3cgdGhhdCBtZWFucyAiYW55dGhpbmcgZ29lcyIpLg0KPj4NCj4+IFdlIHNob3Vs
ZCBmb2xsb3cgZXhpc3RpbmcgY29tbW9uIGltcGxlbWVudGF0aW9ucyBmb3IgdGhpcyBpbiBvcmRl
ciB0bw0KPj5mb3N0ZXIgYmV0dGVyIGFkb3B0aW9uLg0KPj4NCj4+IENpc2NvIElPUy1YUiBoYXMg
c2VwYXJhdGUgbGlzdHMgZm9yIGlwdjQgYW5kIGlwdjYgYW5kIHBhcnQgb2YNCj4+c3BlY2lmeWlu
ZyB0aGUgbGlzdDoNCj4+IGlwdjQgYWNjZXNzLWxpc3QgPG5hbWU+DQo+PiBpcHY2IGFjY2Vzcy1s
aXN0IDxuYW1lPg0KPj4gIA0KPj4gSnVub3MgaGFzIHNlcGFyYXRlIGxpc3RzIGZvciB2NCBhbmQg
djY6DQo+PiBhY2Nlc3MtbGlzdCA8eHl6PiAuLi4NCj4+IGlwdjYgYWNjZXNzLWxpc3QgPGFiYz4g
Li4uDQo+PiAgDQo+PiBBTFUgU1IgT1MgaGFzIHNlcGFyYXRlIGxpc3RzIGZvciB2NCwgdjYgYW5k
IG1hYzoNCj4+IGNvbmZpZyBmaWx0ZXIgaXAtZmlsdGVyIDxhYmM+DQo+PiBjb25maWcgZmlsdGVy
IGlwdjYtZmlsdGVyIDxkZWY+DQo+PiBjb25maWcgZmlsdGVyIG1hYy1maWx0ZXIgPGdoaT4NCj4+
ICANCj4+IEh1YXdlaSB1c2VzIHNlcGFyYXRlIGxpc3RzIGZvciB2NCBhbmQgdjY6DQo+PiBhY2wg
bnVtYmVyIDMwMDANCj4+IGFjbCBpcHY2IG51bWJlciAzMDAwDQo+Pg0KPj4gUGxlYXNlIHNlZSBi
ZWxvdyB3aXRoIFs+PkpUU10NCj4+DQo+PiBSZWdhcmRzLA0KPj4gSmFzb24NCj4+DQo+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NCj4+IFNlbnQ6IE1vbmRh
eSwgSnVuZSAwMSwgMjAxNSAxNzowMA0KPj4gVG86IE5hYmlsIE1pY2hyYWYNCj4+IENjOiBuZXRt
b2RAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBtYW5kYXRvcnkgQUNMIHR5cGUg
KHdhcyAiY29tbWVudHMgb24NCj4+YWNsLW1vZGVsLTAyIikNCj4+DQo+PiBIaSwNCj4+DQo+Pg0K
Pj4gVGhhdCBhcHBlYXJzIHRvIGJlIHRoZSBjdXJyZW50IHZlcnNpb24gb24gdGhlIGRhdGEtdHJh
Y2tlci4NCj4+IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgYWNjZXNzLWNvbnRyb2wtbGlzdC10
eXBlIGxlYWYgc2hvdWxkIGJlDQo+Pm1hbmRhdG9yeS4NCj4+DQo+PiBJIG5vdGljZWQgdGhhdCB0
aGUgZXhhbXBsZSBpbiBGaWd1cmUgMiBoYXMgYW4gZXh0cmEgJ3RvcCcNCj4+IGNvbnRhaW5lciBh
bmQgdGhlIG5hbWVzcGFjZSBmb3IgJ2FjY2Vzcy1saXN0cycgaXMgbWlzc2luZy4NCj4+DQo+Pg0K
Pj4gQW5keQ0KPj4NCj4+IE9uIE1vbiwgSnVuIDEsIDIwMTUgYXQgMTE6MzEgQU0sIE5hYmlsIE1p
Y2hyYWYNCj4+PG5hYmlsLm1pY2hyYWZAZ21haWwuY29tPiB3cm90ZToNCj4+PiBIaSBhbGwsDQo+
Pj4NCj4+PiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0DQo+
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTAy
LnR4dCBvciBzb21lDQo+Pj4gb3RoZXIgZHJhZnQ/DQo+Pj4gSSBqdXN0IHdhbnQgdG8gbWFrZSBz
dXJlIEkgYW0gbG9va2luZyBhdCB0aGUgcmlnaHQgQUNMIG1vZGVsIHZlcnNpb24uDQo+Pj4NCj4+
PiBUaGFuayB5b3UsDQo+Pj4gTmFiaWwNCj4+Pg0KPj4+IE9uIE1vbiwgSnVuIDEsIDIwMTUgYXQg
NzowNiBBTSwgRGFuYSBCbGFpciAoZGJsYWlyKSA8ZGJsYWlyQGNpc2NvLmNvbT4NCj4+PiB3cm90
ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gNC8xMy8xNSwgMTA6MTEgQU0sICJTdGVybmUs
IEphc29uIChKYXNvbikiDQo+Pj4+IDxqYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNlbnQuY29tPiB3
cm90ZToNCj4+Pj4NCj4+Pj4gPkhpIGd1eXMsDQo+Pj4+ID4NCj4+Pj4gPkV4dHJhY3RpbmcgbXkg
Y29tbWVudHMgYWJvdXQgQUNMIHR5cGUgaW50byBpdHMgb3duIHRocmVhZC4gIEkgc2F3DQo+Pj4+
ID5NYXJ0aW4gYWxzbyBoYWQgc29tZSBjb21tZW50cyBvbiB0aGlzIHRvcGljLg0KPj4+PiA+DQo+
Pj4+ID5UaGUgQUNMIHR5cGUgd2FzIG1hbmRhdG9yeSBpbiBhbiBvbGRlciB2ZXJzaW9uIG9mIHRo
ZSBkcmFmdCBhbmQgSQ0KPj4+PiA+dGhpbmsgd2Ugc2hvdWxkIHB1dCBpdCBiYWNrIGFzIG1hbmRh
dG9yeS4gIEltcGxlbWVudGF0aW9ucyB0aGF0DQo+Pj4+ID5kb24ndCAqbmVlZCogdGhhdCBsZWFm
IHZhbHVlIGNhbiB3b3JrIGZpbmUgd2hldGhlciB0aGV5IGdldCBpdA0KPj4+PiA+ZHVyaW5nIEFD
TCBjcmVhdGlvbiBvciBub3QgYnV0IHNvbWUgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8ga25vdyB0
aGUNCj4+Pj50eXBlLg0KPj4+Pg0KPj4+PiBXZSBkb27CuXQgd2FudCB0byBtYWtlIHRoZSBBQ0wg
dHlwZSBtYW5kYXRvcnkgYmVjYXVzZSB0aGVuIHdlIGhhdmUgdG8NCj4+Pj4gYSBjcmVhdGUgYSBu
ZXcgdHlwZSBmb3IgZXZlcnkgY29tYmluYXRpb24gb2YgbWF0Y2ggY3JpdGVyaWEuICBUaGUNCj4+
Pj4gbW9kZWwgc2hvdWxkIHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uIG9mIG1hdGNoIGNyaXRlcmlh
IHdpdGggdHlwaW5nDQo+Pj4+IG9wdGlvbmFsIHRvIG1hcCB0byBwcmUtZXhpc3RpbmcgaW1wbGVt
ZW50YXRpb25zLiAgVGhpcyBpcyBhIHRyYWRlb2ZmDQo+Pj4+IGJldHdlZW4gbWFraW5nIHRoZSBt
b2RlbCBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcNCj4+Pj4gaW1wbGVtZW50YXRp
b25zIGJ1dCBtYWtlIGl0IGZsZXhpYmxlIGVub3VnaCBzbyB0aGF0IGEgbmV3IG1hdGNoDQo+Pj4+
IGNyaXRlcmlhIGRvZXNuwrl0IHJlcXVpcmUgYSBuZXcgdHlwZS4NCj4+DQo+PiBbPj5KVFNdIFdl
IGNhbiBqdXN0IGNyZWF0ZSBhICJtaXhlZCIgKGkuZS4gdW5zcGVjaWZpZWQpIHR5cGUgYW5kIHB1
dCBpdA0KPj51bmRlciBhbiBpZi1mZWF0dXJlLiBFeGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgaGF2
ZSBhIHNpbmdsZSB0eXBlIChhbmQNCj4+cmVxdWlyZSBrbm93aW5nIHRoZSB0eXBlIGF0IGxpc3Qg
Y3JlYXRpb24gdGltZSkuDQo+Pg0KPj4+Pg0KPj4+PiA+DQo+Pj4+ID5JdCB3b3VsZCBhbHNvIGJl
IGdvb2QgdG8gY3JlYXRlIHNlcGFyYXRlIGlkZW50aXRpZXMgZm9yDQo+Pj4+ID5JUHY0LWFjY2Vz
cy1jb250cm9sLWxpc3QgYW5kIElQdjYtYWNjZXNzLWNvbnRyb2wtbGlzdCBpbnN0ZWFkIG9mDQo+
Pj4+ID5idW5kbGluZyB0aGVtIGludG8gSVAtYWNjZXNzLWNvbnRyb2wtbGlzdC4gSWYgd2UncmUg
c2VwYXJhdGluZyBpbnRvDQo+Pj4+ID50eXBlcyBpbiB0aGUgbW9kZWwgaXQgc2hvdWxkIGJlIHRo
ZSAzIGJhc2ljIHR5cGVzIGluIHRoZSBiYXNlIG1vZGVsOg0KPj4+PiB2NCwgdjYgYW5kIGVuZXQu
DQo+Pj4+DQo+Pj4+IEEgdmVuZG9yIHNwZWNpZmljIGF1Z21lbnRhdGlvbi9pbXBsZW1lbnRhdGlv
biBjb3VsZCBkbyB0aGlzLCBidXQgdGhlDQo+Pj4+IG1vZGVsIG5lZWRzIHRvIHN1cHBvcnQgaW5j
bHVzaW9uIG9mIGlwdjQgYW5kIGlwdjYgaW4gdGhlIHNhbWUgYWNsLg0KPj4+PiBJwrltIGF3YXJl
IG9mIG91dHN0YW5kaW5nIGN1c3RvbWVycyByZXF1ZXN0cyBmb3IgY29tYmluaW5nIGlwdjQgcnVs
ZXMNCj4+Pj4gYW5kIGlwdjYgcnVsZXMgaW4gdGhlIHNhbWUgYWNsLCBidXQgbW9zdCBpbXBsZW1l
bnRhdGlvbnMgaGF2ZSBub3QNCj4+Pj4gY2F1Z2h0IHVwIHRvIHRoaXMuICBXaGVuIGl0IGNvbWVz
IHRvIG1hbmFnaW5nIGFjbHMgdGhlcmUgc2hvdWxkbsK5dCBiZQ0KPj4+PiB0aGlzIGRpc3RpbmN0
aW9uIGJldHdlZW4gSVB2NiBhbmQgSVB2NC4gIFRoZXkgYXJlIGJvdGggSVAgYWRkcmVzc2VzLg0K
Pj4NCj4+DQo+PiBbPj5KVFNdIEFnYWluIC0gbGV0J3MgZm9jdXMgb24gY2FwdHVyaW5nIGNvbW1v
biBleGlzdGluZw0KPj5pbXBsZW1lbnRhdGlvbnMgaW4gdGhlc2Ugc3RhbmRhcmQgbW9kZWxzICh3
aGlsZSBhbHNvIGFsbG93aW5nIGZvcg0KPj5hdWdtZW50YXRpb24gYW5kIGZsZXhpYmlsaXR5KS4g
IFY0IGFuZCBWNiBhcmUgaW4gc2VwYXJhdGUgbGlzdHMgdG9kYXkuDQo+PkEgZnV0dXJlIG1peGVk
IGxpc3QgY2FuIHVzZSB0aGUgIm1peGVkIiB0eXBlIG9yIGludmVudCBhIG5ldyAidjQrdjYiDQo+
PnR5cGUuDQo+Pg0KPj4+Pg0KPj4+PiA+DQo+Pj4+ID5UaGF0IHdvdWxkIGFsc28gaGVscCBpZiB3
ZSBkZWNpZGUgdG8gcHV0IHNvbWUgY29uc3RyYWludHMgdGhhdA0KPj4+PiA+YWxsb3cvZGlzYWxs
b3cgY2VydGFpbiBtYXRjaGluZyBjcml0ZXJpYSB3aGVuIHRoZSB0eXBlIGlzIGEgc3BlY2lmaWMN
Cj4+Pj4gPnZhbHVlIChlLmcuIGRvbid0IGFsbG93IGEgdjYgYWRkcmVzcyBtYXRjaCBpbiBhIHY0
IGxpc3QpLg0KPj4+PiA+ICBXZSdkIGhhdmUgdG8gYmUgY2FyZWZ1bCBhYm91dCBob3cgdGhvc2Ug
Y29uc3RyYWludHMgYXJlIGZvcm11bGF0ZWQNCj4+Pj4gPnRob3VnaCAtIGVzcGVjaWFsbHkgaWYg
d2Ugd2FudCB0byBhbGxvdyBhdWdtZW50YXRpb25zIG9mIHRoZQ0KPj4+PiA+bGlzdC10eXBlIGZv
ciAibWl4ZWQiIEFDTHMuIEEgbmV3ICJtaXhlZC12NC1lbmV0IiB0eXBlIChpZGVudGl0eSkNCj4+
Pj4gPndvdWxkIGFsc28gbmVlZCB0byB1c2UgdGhlIGRlc3RpbmF0aW9uLWlwdjQtbmV0d29yayBt
YXRjaGluZw0KPj4+PiA+Y3JpdGVyaWEgKGNhbiAid2hlbiIgb3IgIm11c3QiIGxvZ2ljIGJlIGNo
YW5nZWQgYnkgYW4gYXVnbWVudGF0aW9uID8NCj4+Pj4gSSdtIG5vdCBzdXJlIHRoYXQgd29ya3Mp
Lg0KPj4+Pg0KPj4+PiBZZXMsIHdvdWxkIGhhdmUgdG8gYmUgY2FyZWZ1bCwgYW5kIGRlZmluaW5n
IGNvbnN0cmFpbnRzIGJhc2VkIG9uDQo+Pj4+ZXhpc3RpbmcNCj4+Pj4gaW1wbGVtZW50YXRpb25z
IGNvdWxkIGJlIGEgdmVyeSBzbGlwcGVyeSBzbG9wZS4gICBWZW5kb3JzIHNob3VsZCBiZQ0KPj4+
PmFibGUNCj4+Pj4gdG8gbWFwIHRvIHRoZWlyIGltcGxlbWVudGF0aW9ucyBhbmQvb3IgaGF2ZSBh
IHByb3ByaWV0YXJ5DQo+Pj4+IGF1Z21lbnRhdGlvbiB0aGF0IGNvbnN0cmFpbnMgdGhpbmdzIG1v
cmUgYWNjb3JkaW5nIHRvDQo+Pj4+IHRoZWlyIGltcGxlbWVudGF0aW9uLiAgIFByb3ByaWV0YXJ5
IGF1Z21lbnRhdGlvbnMgY291bGQgYmUgcHJvcG9zZWQsDQo+Pj4+YW5kDQo+Pj4+IHJldmlld2Vk
IGZvciBzdGFuZGFyZGl6YXRpb24uDQo+Pg0KPj4NCj4+IFs+PkpUU10gVGhlIGRyYWZ0IGRvZXNu
J3QgaGF2ZSBhbnkgY29uc3RyYWludHMgYmFzZWQgb24gdHlwZSBzbyBJDQo+PnN1cHBvc2UgdGhp
cyBwb2ludCBpcyBtb290Lg0KPj4NCj4+Pj4NCj4+Pj4gdGhhbmtzLA0KPj4+PiBEYW5hDQo+Pj4+
DQo+Pj4+ID4NCj4+Pj4gPlJlZ2FyZHMsDQo+Pj4+ID5KYXNvbg0KPj4+PiA+DQo+Pj4+ID4NCj4+
Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+
ID5uZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+ID5uZXRtb2RAaWV0Zi5vcmcNCj4+Pj4gPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4+DQo+Pj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldG1vZCBt
YWlsaW5nIGxpc3QNCj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGlu
ZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRt
b2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+
IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCj4NCj4tLSANCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtl
eSBJRDogRTc0RThDMEMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Mon Sep 21 11:44:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F801B341E for ; Mon, 21 Sep 2015 11:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oq9DhYMYkEg for ; Mon, 21 Sep 2015 11:43:54 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888321B3409 for ; Mon, 21 Sep 2015 11:43:53 -0700 (PDT)
Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id A7A17180309; Mon, 21 Sep 2015 20:43:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442861031; bh=XGtPb2V0kVZtqrpH3w84N22e8G0S0KZBBCNd6T82o2c=; h=From:Date:To; b=YyM14T1/HOcCuqAQQE3juBpCeqH24bxrdtAetnWUxaO8RZ4mFKygpl/KWIdY8QkGZ KyKvu6MBruNG8Fn4ayjB9lx/cpwDiNOIgr6jZRvlXdnKvC32lJYjk/Rbs0YUfnlMVY ijWqdta4gL4nl+uhLJy/59KXpsbAuIaW/7QkA/34=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 21 Sep 2015 20:43:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <601AAE05-C749-4C35-B10D-6AD759D5B7A2@nic.cz>
References:         
To: "Acee Lindem (acee)" 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 18:43:58 -0000

> On 21 Sep 2015, at 16:50, Acee Lindem (acee)  wrote:
>=20
>=20
>=20
> On 9/21/15, 10:23 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>=20
>> "Sterne, Jason (Jason)"  writes:
>>=20
>>> Hi all,
>>>=20
>>> I met with Dean at IETF93 and we agreed that I should send a =
specific
>>> proposal to the list for this.  Here it is:
>>>=20
>>> -----------------------------------------------------
>>> Replace the following current snippets from model-03:
>>> -----------------------------------------------------
>>>=20
>>> list acl {
>>> key "acl-name";
>>> ...
>>> }
>>>=20
>>> leaf acl-type {
>>> type acl-type;
>>> description
>>>   "It is recommended to have an Access Control List with
>>>    uniform access list entries, all of the same type. When
>>>    this type is not explicitly specified, if vendor
>>>    implementation permits, the access control entries
>>>    in the list can be mixed,
>>>    by containing L2, L3 and L4 entries";
>>> }
>>>=20
>>> identity ip-acl {
>>> base acl:acl-base;
>>> description
>>>   "IP Access Control List is a common name for lists that contain
>>>    layer 3 and/or layer 4 match conditions.";
>>> }
>>>=20
>>> identity eth-acl {
>>> base acl:acl-base;
>>> description
>>>   "Ethernet Access Control List is name for layer 2 Ethernet
>>>    technology Access Control List types, like 10/100/1000baseT or
>>>    WiFi Access Control List";
>>> }
>>>=20
>>> --------------------
>>> with the following:
>>> --------------------
>>>=20
>>> list acl {
>>> key "acl-type acl-name";
>>> ...
>>> }
>>> (note this is similar construct to the routing model:
>>>  list routing-protocol {key "type name"... )
>>=20
>> Well, originally we had "name" as the only key but some routing folks
>> insisted on having "type" as the second key. Personally, I am not
>> entirely sold to this idea.
>=20
> Why not? Existing products support these semantics=E2=80=A6 Different =
types of
> access-list should have independent name spaces (i.e., one should be =
able
> to have an IP ACL named foo, an IPv6 ACL named foo, and a L2 ACL named
> foo).

Sure, but that=E2=80=99s (I assume) how the operators see and address =
the ACLs in their CLI or other user interface, and this needn=E2=80=99t =
change at all. But sometimes operators might also want to change the =
name of one of the lists from =E2=80=9Cfoo=E2=80=9D to =E2=80=9Cbar=E2=80=9D=
, and this wouldn=E2=80=99t be possible if the name is a list key as =
required by YANG - except via deleting the ACL and creating it again =
with a different name, which is hardly an attractive option.

Lada

>=20
>=20
> Thanks,
> Acee=20
>=20
>=20
>=20
>=20
>=20
>>=20
>> The thing is: YANG requires config lists to have keys but it doesn't
>> mean these keys need to be the same as parameters that are understood =
as
>> keys in a CLI.
>>=20
>> One advantage of having YANG list keys separate from "public" keys is
>> that a user is free to change the public keys, and it also doesn't =
break
>> any internal references in the configuration. If you have "acl-type" =
and
>> "acl-name" as YANG list keys, then they cannot be changed.
>>=20
>> So in fact I'd suggest to have an opaque ID as the only list key, and
>> then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
>> unique constraint.
>>=20
>> Lada
>>=20
>>>=20
>>> leaf acl-type {
>>> type acl-type;
>>> description
>>>   "Type of access control list. Indicates the primary intended
>>>    type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
>>>    used in the list instance.";
>>> }
>>>=20
>>> identity ipv4-acl {
>>> base acl:acl-base;
>>> description=20
>>>   "ACL that primarily matches on fields from the IPv4 header
>>>   (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
>>> destination
>>>   port).  An acl of type ipv4-acl does not contain matches on fields
>>> in
>>>   the ethernet header or the IPv6 header.";
>>> }
>>>=20
>>> identity ipv6-acl {
>>> base acl:acl-base;
>>> description
>>>   "ACL that primarily matches on fields from the IPv6 header
>>>   (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
>>> destination
>>>   port). An acl of type ipv6-acl does not contain matches on fields =
in
>>>   the ethernet header or the IPv4 header.";
>>> }
>>>=20
>>> identity eth-acl {
>>> base acl:acl-base;
>>> description
>>>   "ACL that primarily matches on fields in the ethernet header.
>>>    An acl of type eth-acl does not contain matches on fields in
>>>    the IPv4 header, IPv6 header or layer 4 headers.";
>>> }
>>>=20
>>>=20
>>> ---------------------------------------
>>> Potential future augmentation of type:
>>> ----------------------------------------
>>>=20
>>> For future mixed types vendors (or the ietf) could augment the
>>> acl-type-base with types like the following:
>>>=20
>>> identity mixed-l3-acl {
>>>   base "access-control-list:acl-type-base";
>>>   description "ACL that contains a mix of entries that primarily
>>> match on fields=20
>>>     in IPv4 headers and entries that primarily match on fields in
>>> IPv6 headers.
>>>     Matching on layer 4 header fields may also exist in the list.
>>>     An acl of type mixed-l3-acl does not contain matches on fields =
in
>>>     the ethernet header.";
>>> }
>>>=20
>>> identity mixed-l2-l3-acl {
>>>   base "access-control-list:acl-type-base";
>>>   description "ACL that contains a mix of entries that primarily
>>> match on fields=20
>>>     in ethernet headers, entries that primarily match on fields in
>>> IPv4 headers,
>>>     and entries that primarily match on fields in IPv6 headers.
>>> Matching on layer 4
>>>     header fields may also exist in the list.";
>>> }
>>>=20
>>> Regards,
>>> Jason
>>>=20
>>> -----Original Message-----
>>> From: Sterne, Jason (Jason)
>>> Sent: Sunday, July 19, 2015 12:58
>>> To: Sterne, Jason (Jason); netmod@ietf.org
>>> Subject: RE: ACL Model 03 - ACL Type should be mandatory
>>>=20
>>> Given the data models below in some of the major implementations it
>>> also seems like we should also (re-)consider having the 'type' as =
part
>>> of the ACL key ("type name").
>>>=20
>>> In all those cases below it looks like an operator can currently
>>> configure two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the
>>> same name/id via their CLI (e.g. a v4 ACL called "my-acl" and a v6 =
ACL
>>> called "my-acl").
>>>=20
>>> How would those lists be read in a  via the ietf ACL =
YANG
>>> modules ?  We'd all have to mangle the names and reserve special
>>> names/prefix-chars (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them
>>> back to a NC client.  I'm not sure if there is much of a =
disadvantage of
>>> just having type in the key (assuming it is mandatory as advocated
>>> below).
>>>=20
>>> I also looked briefly at the Brocade YANG models on github.  It =
looks
>>> like they have multiple lists as well for v4 vs v6 (and even or
>>> different types of normal vs extended ACLs - that could be handled =
by
>>> augmenting the type with a 'v4-extended' type for example).
>>>=20
>>> Regards,
>>> Jason
>>>=20
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne,
>>> Jason (Jason)
>>> Sent: Friday, July 17, 2015 23:35
>>> To: netmod@ietf.org
>>> Subject: [netmod] ACL Model 03 - ACL Type should be mandatory
>>>=20
>>> Hi all,
>>>=20
>>> I think we need to revisit this discussion about how ACL type works =
in
>>> draft-ietf-netmod-acl-model-03.
>>>=20
>>> It should be mandatory and we should separate v4 from v6.  Vendors =
can
>>> augment for future "mixed" types (or maybe we should make an =
if-feature
>>> for a "mixed" type now that means "anything goes").
>>>=20
>>> We should follow existing common implementations for this in order =
to
>>> foster better adoption.
>>>=20
>>> Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of
>>> specifying the list:
>>> ipv4 access-list 
>>> ipv6 access-list 
>>>=20
>>> Junos has separate lists for v4 and v6:
>>> access-list  ...
>>> ipv6 access-list  ...
>>>=20
>>> ALU SR OS has separate lists for v4, v6 and mac:
>>> config filter ip-filter 
>>> config filter ipv6-filter 
>>> config filter mac-filter 
>>>=20
>>> Huawei uses separate lists for v4 and v6:
>>> acl number 3000
>>> acl ipv6 number 3000
>>>=20
>>> Please see below with [>>JTS]
>>>=20
>>> Regards,
>>> Jason
>>>=20
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy =
Bierman
>>> Sent: Monday, June 01, 2015 17:00
>>> To: Nabil Michraf
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] mandatory ACL type (was "comments on
>>> acl-model-02")
>>>=20
>>> Hi,
>>>=20
>>>=20
>>> That appears to be the current version on the data-tracker.
>>> I agree with you that the access-control-list-type leaf should be
>>> mandatory.
>>>=20
>>> I noticed that the example in Figure 2 has an extra 'top'
>>> container and the namespace for 'access-lists' is missing.
>>>=20
>>>=20
>>> Andy
>>>=20
>>> On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf
>>>  wrote:
>>>> Hi all,
>>>>=20
>>>> Can you please clarify if we are talking about
>>>> https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some
>>>> other draft?
>>>> I just want to make sure I am looking at the right ACL model =
version.
>>>>=20
>>>> Thank you,
>>>> Nabil
>>>>=20
>>>> On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair) =

>>>> wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
>>>>>  wrote:
>>>>>=20
>>>>>> Hi guys,
>>>>>>=20
>>>>>> Extracting my comments about ACL type into its own thread.  I saw
>>>>>> Martin also had some comments on this topic.
>>>>>>=20
>>>>>> The ACL type was mandatory in an older version of the draft and I
>>>>>> think we should put it back as mandatory.  Implementations that
>>>>>> don't *need* that leaf value can work fine whether they get it
>>>>>> during ACL creation or not but some implementations need to know =
the
>>>>> type.
>>>>>=20
>>>>> We don=C2=B9t want to make the ACL type mandatory because then we =
have to
>>>>> a create a new type for every combination of match criteria.  The
>>>>> model should support any combination of match criteria with typing
>>>>> optional to map to pre-existing implementations.  This is a =
tradeoff
>>>>> between making the model backward compatible with existing
>>>>> implementations but make it flexible enough so that a new match
>>>>> criteria doesn=C2=B9t require a new type.
>>>=20
>>> [>>JTS] We can just create a "mixed" (i.e. unspecified) type and put =
it
>>> under an if-feature. Existing implementations have a single type =
(and
>>> require knowing the type at list creation time).
>>>=20
>>>>>=20
>>>>>>=20
>>>>>> It would also be good to create separate identities for
>>>>>> IPv4-access-control-list and IPv6-access-control-list instead of
>>>>>> bundling them into IP-access-control-list. If we're separating =
into
>>>>>> types in the model it should be the 3 basic types in the base =
model:
>>>>> v4, v6 and enet.
>>>>>=20
>>>>> A vendor specific augmentation/implementation could do this, but =
the
>>>>> model needs to support inclusion of ipv4 and ipv6 in the same acl.
>>>>> I=C2=B9m aware of outstanding customers requests for combining =
ipv4 rules
>>>>> and ipv6 rules in the same acl, but most implementations have not
>>>>> caught up to this.  When it comes to managing acls there =
shouldn=C2=B9t be
>>>>> this distinction between IPv6 and IPv4.  They are both IP =
addresses.
>>>=20
>>>=20
>>> [>>JTS] Again - let's focus on capturing common existing
>>> implementations in these standard models (while also allowing for
>>> augmentation and flexibility).  V4 and V6 are in separate lists =
today.
>>> A future mixed list can use the "mixed" type or invent a new "v4+v6"
>>> type.
>>>=20
>>>>>=20
>>>>>>=20
>>>>>> That would also help if we decide to put some constraints that
>>>>>> allow/disallow certain matching criteria when the type is a =
specific
>>>>>> value (e.g. don't allow a v6 address match in a v4 list).
>>>>>> We'd have to be careful about how those constraints are =
formulated
>>>>>> though - especially if we want to allow augmentations of the
>>>>>> list-type for "mixed" ACLs. A new "mixed-v4-enet" type (identity)
>>>>>> would also need to use the destination-ipv4-network matching
>>>>>> criteria (can "when" or "must" logic be changed by an =
augmentation ?
>>>>> I'm not sure that works).
>>>>>=20
>>>>> Yes, would have to be careful, and defining constraints based on
>>>>> existing
>>>>> implementations could be a very slippery slope.   Vendors should =
be
>>>>> able
>>>>> to map to their implementations and/or have a proprietary
>>>>> augmentation that constrains things more according to
>>>>> their implementation.   Proprietary augmentations could be =
proposed,
>>>>> and
>>>>> reviewed for standardization.
>>>=20
>>>=20
>>> [>>JTS] The draft doesn't have any constraints based on type so I
>>> suppose this point is moot.
>>>=20
>>>>>=20
>>>>> thanks,
>>>>> Dana
>>>>>=20
>>>>>>=20
>>>>>> Regards,
>>>>>> Jason
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Sep 21 12:09:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A871B342D for ; Mon, 21 Sep 2015 12:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuxgzvXui8Fz for ; Mon, 21 Sep 2015 12:09:43 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9081B3404 for ; Mon, 21 Sep 2015 12:09:41 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 21 Sep 2015 19:09:39 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Mon, 21 Sep 2015 19:09:39 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
Thread-Index: AQHQ8lzThTAvqjhhWUW821rJF43C855GvL+AgABdlQA=
Date: Mon, 21 Sep 2015 19:09:39 +0000
Message-ID: 
References:  <55FFCF2F.5010902@cisco.com>
In-Reply-To: <55FFCF2F.5010902@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:irtA1qIahLSW7L8k5K6mLq1YLyDK15YsxvvBStJCRwll1KgaXS1AWmOvwGAdOlF4lTMj5aOBWOF0zLiLP0QJjvF1KTtDj4y9nVliDjXi6QZNwQHN7mJFVPKo9Vo/TZbp2UIlf8ojkAJ8FCBF7uXhYA==; 24:0Wm5W5yqRfA2WPsPPn1XhPgC/6tCTZEv3TB6ZVZiap6wNg/qik+jdsAiiru273rJlOKUJASz65ZfwU6tWddya4JZTeftEAeFLCuPWmFPv2A=; 20:UfUEY43RsgEzn83ZoBWhu7aLDPjnC2WgYQno0Z/5yR8dCOBMeWYOh5NQnMc4PGjEPhXoEsr3u8ULgRlqQA9U+g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 07063A0A30
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(479174004)(164054003)(377454003)(24454002)(2501003)(99286002)(86362001)(40100003)(64706001)(575784001)(106116001)(101416001)(83506001)(87936001)(5002640100001)(76176999)(2900100001)(4001350100001)(5007970100001)(11100500001)(19580395003)(50986999)(105586002)(62966003)(5001960100002)(102836002)(122556002)(66066001)(77156002)(19580405001)(81156007)(2950100001)(5001920100001)(5001830100001)(15975445007)(107886002)(68736005)(5001860100001)(97736004)(36756003)(5004730100002)(92566002)(46102003)(189998001)(54356999)(4001540100001)(5001770100001)(10400500002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <928A1F6756101F42A66777DCF91C9E72@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2015 19:09:39.4649 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 19:09:45 -0000

Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
as well?

PS: I've moved this issue to the VERIFY state.

Thanks,
Kent




On 9/21/15, 5:34 AM, "Robert Wilton"  wrote:

>Hi,
>
>I suggest changing the wording for A and adding D:
>
>    7.  Ability for distinct modules to leverage a common model-structure
>        A.  Scope is limited to providing a general model-structure only
>        B.  Multiple domain-specific trees are okay
>        C.  Multiple namespaces are okay
>        D.  The model-structure may be used or extended by other
>organizations.
>
>Justifications for (A):
>  - Limiting the scope to IETF-defined modules almost implies that
>'ietf' would end up in the path (which would be wrong/unnecessary).
>  - Clients don't care which SDO defines the modules for the protocols
>they use, they just want a coherent organization of modules.
>  - General structure only to limit the scope because trying to
>precisely place every protocol/feature is likely to be fragile in the
>face of future changes.
>
>Justifications for (D):
>  - To suggest and encourage other SDOs to use the same structure, but
>cannot mandate what they do.
>
>Thanks,
>Rob
>
>
>On 18/09/2015 22:56, Kent Watsen wrote:
>> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>>
>>
>>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>>              others are now defining YANG modules?
>>
>>    Benoit> Good point. We need to provide guidance for the other SDOs.
>>
>>
>> Current text says:
>>
>>     7.  Ability for distinct modules to leverage a common
>>model-structure
>>         A.  Scope is limited to IETF-defined modules
>>         B.  Multiple domain-specific trees are okay
>>         C.  Multiple namespaces are okay
>>
>>
>>
>> Background:
>>
>>    I pulled 7A from Andy's message here:
>>
>>     =20
>> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>>
>>    and put a stake in the ground so that, if nothing else, it could
>>    be discussed...and here we are!
>>
>>    FWIW, I wrote 7A this way because I didn't see how it can be
>>    enforced outside of the IETF.  But maybe that doesn't matter?
>>    Of course, we can have 6087bis guidance for other SDOs, but
>>    I didn't put that in the text.
>>
>>
>> Thoughts on how the text should be updated?
>>
>>
>> PS: Please Reply-All to the list rather than post comments to the GitHub
>> issue tracker.
>>
>>
>> Thanks,
>> Kent
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>


From nobody Mon Sep 21 12:29:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67A1B349D for ; Mon, 21 Sep 2015 12:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YipZzw86aaVd for ; Mon, 21 Sep 2015 12:29:01 -0700 (PDT)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 A45111B3499 for ; Mon, 21 Sep 2015 12:29:00 -0700 (PDT)
Received: by lbpo4 with SMTP id o4so56872952lbp.2 for ; Mon, 21 Sep 2015 12:28:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lO5b9ddVPR60UaPpq42XeFkcAx8HvXioG3IEYWaygPo=; b=EHHvuuu5MztBBa2PR2pjBBSebhEAAjt0W2LvAk1mdAE3bFO3V/sJnsOKnttgGeMc7z StlkynzdYb+tZYyNFrioYZjxyroV5lfXGrZ5nYGwkjgHTmEhQapl4loJiPRrS+dYSdFG gliH3RGZtF6UFRK/cnBuFfE98z1i8CKzBfI2pWL9/PimggMo1M6/Z0HvFG6/K9TDzuz6 E+blc45gRGUFA/SqJ70CbnF5qa6azyhm05fZY3zts8ZCDV5RHQbjT4jugbm548q/fEDd 1QfnOsfcyM98R+GFGX9m7UUMLvkjPwcfKt8O6k/jG5YHaq81PTT/aL6LwpQ74HXnLr6z cMPA==
X-Gm-Message-State: ALoCoQn3ANCzAsvf1CdRlMpG3jSNilgb8ntR7sNKkgZoH11F0lwosiTLWIthrzFyYXy4Ur7CvZHI
MIME-Version: 1.0
X-Received: by 10.25.218.205 with SMTP id r196mr1686358lfg.82.1442863738941; Mon, 21 Sep 2015 12:28:58 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 21 Sep 2015 12:28:58 -0700 (PDT)
In-Reply-To: 
References:  <55FFCF2F.5010902@cisco.com> 
Date: Mon, 21 Sep 2015 12:28:58 -0700
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=001a114021549e9671052046e452
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 19:29:03 -0000

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

Hi,

I do not think the issue of scope is being considered very carefully.

IMO the solutions being proposed are extremely router-centric.
(e.g., most NETCONF servers DO NOT have any virtual servers within them).

The larger the scope, the more concern I have that
the IETF will be pushing expensive solutions on platforms
that don't have any of the "problems" in the first place.


Andy



On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen  wrote:

>
> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
> as well?
>
> PS: I've moved this issue to the VERIFY state.
>
> Thanks,
> Kent
>
>
>
>
> On 9/21/15, 5:34 AM, "Robert Wilton"  wrote:
>
> >Hi,
> >
> >I suggest changing the wording for A and adding D:
> >
> >    7.  Ability for distinct modules to leverage a common model-structure
> >        A.  Scope is limited to providing a general model-structure only
> >        B.  Multiple domain-specific trees are okay
> >        C.  Multiple namespaces are okay
> >        D.  The model-structure may be used or extended by other
> >organizations.
> >
> >Justifications for (A):
> >  - Limiting the scope to IETF-defined modules almost implies that
> >'ietf' would end up in the path (which would be wrong/unnecessary).
> >  - Clients don't care which SDO defines the modules for the protocols
> >they use, they just want a coherent organization of modules.
> >  - General structure only to limit the scope because trying to
> >precisely place every protocol/feature is likely to be fragile in the
> >face of future changes.
> >
> >Justifications for (D):
> >  - To suggest and encourage other SDOs to use the same structure, but
> >cannot mandate what they do.
> >
> >Thanks,
> >Rob
> >
> >
> >On 18/09/2015 22:56, Kent Watsen wrote:
> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
> >>
> >>
> >>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
> >>              others are now defining YANG modules?
> >>
> >>    Benoit> Good point. We need to provide guidance for the other SDOs.
> >>
> >>
> >> Current text says:
> >>
> >>     7.  Ability for distinct modules to leverage a common
> >>model-structure
> >>         A.  Scope is limited to IETF-defined modules
> >>         B.  Multiple domain-specific trees are okay
> >>         C.  Multiple namespaces are okay
> >>
> >>
> >>
> >> Background:
> >>
> >>    I pulled 7A from Andy's message here:
> >>
> >>
> >>
> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
> >>
> >>    and put a stake in the ground so that, if nothing else, it could
> >>    be discussed...and here we are!
> >>
> >>    FWIW, I wrote 7A this way because I didn't see how it can be
> >>    enforced outside of the IETF.  But maybe that doesn't matter?
> >>    Of course, we can have 6087bis guidance for other SDOs, but
> >>    I didn't put that in the text.
> >>
> >>
> >> Thoughts on how the text should be updated?
> >>
> >>
> >> PS: Please Reply-All to the list rather than post comments to the GitHub
> >> issue tracker.
> >>
> >>
> >> Thanks,
> >> Kent
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I do not think the issue of scope i=
s being considered very carefully.

IMO the solutio=
ns being proposed are extremely router-centric.
(e.g., most NETCO=
NF servers DO NOT have any virtual servers within them).

The larger the scope, the more concern I have that
the IET=
F will be pushing expensive solutions on platforms
that don't=
 have any of the "problems" in the first place.


Andy



On Mon, Sep 21, 2015 at=
 12:09 PM, Kent Watsen <kwatsen@juniper.net> wrote:


Thanks Robert, but I think I like Benoit's edit more.=C2=A0 Are you OK =
with it

as well?



PS: I've moved this issue to the VERIFY state.



Thanks,

Kent









On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com> wrote:



>Hi,

>

>I suggest changing the wording for A and adding D:

>

>=C2=A0 =C2=A0 7.=C2=A0 Ability for distinct modules to leverage a commo=
n model-structure

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A.=C2=A0 Scope is limited to providing a ge=
neral model-structure only

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 B.=C2=A0 Multiple domain-specific trees are=
 okay

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 C.=C2=A0 Multiple namespaces are okay

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 The model-structure may be used or=
 extended by other

>organizations.

>

>Justifications for (A):

>=C2=A0 - Limiting the scope to IETF-defined modules almost implies that=


>'ietf' would end up in the path (which would be wrong/unnecessa=
ry).

>=C2=A0 - Clients don't care which SDO defines the modules for the p=
rotocols

>they use, they just want a coherent organization of modules.

>=C2=A0 - General structure only to limit the scope because trying to
>precisely place every protocol/feature is likely to be fragile in the
>face of future changes.

>

>Justifications for (D):

>=C2=A0 - To suggest and encourage other SDOs to use the same structure,=
 but

>cannot mandate what they do.

>

>Thanks,

>Rob

>

>

>On 18/09/2015 22:56, Kent Watsen wrote:

>> Regarding https://github.com/netmod-wg/op=
state-reqs/issues/7

>>

>>

>>=C2=A0 =C2=A0 Jonathan> Why does 7(A) limit the scope to IETF-de=
fined modules of

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others are now def=
ining YANG modules?

>>

>>=C2=A0 =C2=A0 Benoit> Good point. We need to provide guidance fo=
r the other SDOs.

>>

>>

>> Current text says:

>>

>>=C2=A0 =C2=A0 =C2=A07.=C2=A0 Ability for distinct modules to levera=
ge a common

>>model-structure

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A.=C2=A0 Scope is limited to IETF=
-defined modules

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.=C2=A0 Multiple domain-specific=
 trees are okay

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C.=C2=A0 Multiple namespaces are =
okay

>>

>>

>>

>> Background:

>>

>>=C2=A0 =C2=A0 I pulled 7A from Andy's message here:

>>

>>

>> https://mailarchive=
.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

>>

>>=C2=A0 =C2=A0 and put a stake in the ground so that, if nothing els=
e, it could

>>=C2=A0 =C2=A0 be discussed...and here we are!

>>

>>=C2=A0 =C2=A0 FWIW, I wrote 7A this way because I didn't see ho=
w it can be

>>=C2=A0 =C2=A0 enforced outside of the IETF.=C2=A0 But maybe that do=
esn't matter?

>>=C2=A0 =C2=A0 Of course, we can have 6087bis guidance for other SDO=
s, but

>>=C2=A0 =C2=A0 I didn't put that in the text.

>>

>>

>> Thoughts on how the text should be updated?

>>

>>

>> PS: Please Reply-All to the list rather than post comments to the =
GitHub

>> issue tracker.

>>

>>

>> Thanks,

>> Kent

>>

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

>> https://www.ietf.org/mailman/listinfo/netmod

>>

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a114021549e9671052046e452--


From nobody Mon Sep 21 13:08:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158041A028A for ; Mon, 21 Sep 2015 13:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlTWvJQQt1An for ; Mon, 21 Sep 2015 13:08:14 -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 043451A01E2 for ; Mon, 21 Sep 2015 13:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7370; q=dns/txt; s=iport; t=1442866094; x=1444075694; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=U6sRlFVl6NqCQ4Wlap5RjdBi3dFJJqYhFdZKLJVtjPs=; b=VmCeEV1ZQkYinZ/WPhjT8euA1bvCuatpivWZkGXfK3BmbMYQq796tk5g CE8ewJ8WY+c/6sLl5kKHp8ZjP2ErwTBtkL38p/XnMKHwQoDa8stICMzOh z2PUJOrrz7aV84NEnVpaZv4dt3gvZAnmplFov8YyDuxpcYhaV9dDnfiIx A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaBAAjYwBW/xbLJq1dhGHFSwKCBQEBAQEBAYELhCUBAQQjVhAsHgMCAg8CNQcKBg0GAgEBF4gTuAKUAgEBAQEBAQEBAgEBAQEBAQEBARmGc4R9hCoRAVEHgmmBQwWVZI0HgU2ENYJ+ji2DbWOCERyBVjwziC6BPwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,569,1437436800";  d="scan'208,217";a="605263250"
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; 21 Sep 2015 20:08:09 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8LK88SV018737; Mon, 21 Sep 2015 20:08:09 GMT
References: 
From: Benoit Claise 
To: NETMOD Working Group 
X-Forwarded-Message-Id: 
Message-ID: <560063A8.10406@cisco.com>
Date: Mon, 21 Sep 2015 22:08:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040907020007060100090506"
Archived-At: 
Subject: [netmod] Fwd: Re: Openconfig protocol(s)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 20:08:16 -0000

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

Forwarded Anees Shaikh's email, with permission.
Thanks Anees. I believe it's useful info for NETMOD.

Regards, Benoit
-------- Forwarded Message --------

    hi Benoit, we will be publishing the primitives after we complete
    our internal review -- it's in progress.  There's nothing secret
    about it, or any intention on our part to not 'put our cards on the
    table.'

    As we've said publicly, at Google we are planning to use gRPC for
    example, while others in OpenConfig have expressed their intention
    to use protocols such as Thrift, and still others will use NETCONF,
    or their own REST-based protocol.  OpenConfig is not prescribing or
    endorsing any specific protocol -- we only insist that the data
    models be common.

...


    On Mon, Sep 14, 2015 at 8:00 AM, Benoit Claise > wrote:



         From the preliminary meeting minutes

            Benoit: The two suggested solutions. They are based on
            NETCONF/RESTCONF. Are they using it for other protocols?
            Aneesh: We are using other protocols. Will share primitives.
            Benoit: If the solution is for NETCONF/RESTCONF, will it
            work for other protocols.
            Rob: If the solution is mappable for NETCONF/RESTCONF, would
            it be mappable for another protocol.
            Benoit: YANG is currently not protocol agnostic. Currently,
            it is tied to NETCONF/RESTCONF.
            Benoit: If the solution is for NETCONF/RESTCONF, is that
            acceptable?
            Rob: No. The solution has to be more general.
            Christian: Is the intersection of NETCONF/RESTCONF good
            enough for the other protocols.

        Rob mentioned during the call something such as: "we would share
        the expectations of the protocol".
        Please follow up and share the primitives or those expectations.
        However, in the end, I believe it would be favorable to
        everybody if you would play all your cards on the table, and
        directly share the protocols you plan on using.

        Regards, Benoit (OPS AD)











--------------040907020007060100090506
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Forwarded Anees Shaikh's email, with permission. 

    Thanks Anees. I believe it's useful info for NETMOD.

    


      Regards, Benoit

      -------- Forwarded Message --------

      


        

          

            
hi Benoit, we will be publishing the
              primitives after we complete our internal review -- it's
              in progress.  There's nothing secret about it, or any
              intention on our part to not 'put our cards on the table.'
              


              

              
As we've said publicly, at Google we are planning to
                use gRPC for example, while others in OpenConfig have
                expressed their intention to use protocols such as
                Thrift, and still others will use NETCONF, or their own
                REST-based protocol.  OpenConfig is not prescribing or
                endorsing any specific protocol -- we only insist that
                the data models be common.

            

            

          

        

        

        ...

        


        

        

          

            


              
On Mon, Sep 14, 2015 at 8:00 AM,
                Benoit Claise <bclaise@cisco.com>
                wrote:

                

                  
 

                    

                    From the preliminary meeting minutes

                    
Benoit: The two suggested solutions.
                      They are based on NETCONF/RESTCONF. Are they using
                      it for other protocols?

                      Aneesh: We are using other protocols. Will share
                      primitives.

                      Benoit: If the solution is for NETCONF/RESTCONF,
                      will it work for other protocols.

                      Rob: If the solution is mappable for
                      NETCONF/RESTCONF, would it be mappable for another
                      protocol.

                      Benoit: YANG is currently not protocol agnostic.
                      Currently, it is tied to NETCONF/RESTCONF.

                      Benoit: If the solution is for NETCONF/RESTCONF,
                      is that acceptable?

                      Rob: No. The solution has to be more general.

                      Christian: Is the intersection of NETCONF/RESTCONF
                      good enough for the other protocols.

                    

                    Rob mentioned during the call something such as: "we
                    would share the expectations of the protocol".

                    Please follow up and share the primitives or those
                    expectations. However, in the end, I believe it
                    would be favorable to everybody if you would play
                    all your cards on the table, and directly share the
                    protocols you plan on using.

                    

                    Regards, Benoit (OPS AD)

                    

                    

                    

                  

                

              

              

            

            

          

        

        
 

        

        

          
 

            

          

        

      

      

    

    

  


--------------040907020007060100090506--


From nobody Mon Sep 21 13:17:09 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2CC1A1B05 for ; Mon, 21 Sep 2015 13:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVG_hahAa34l for ; Mon, 21 Sep 2015 13:17:06 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9F71A1AE6 for ; Mon, 21 Sep 2015 13:17:05 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 21 Sep 2015 20:17:02 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Mon, 21 Sep 2015 20:17:02 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
Thread-Index: AQHQ9Kp6ej2qDxNmDkaZhs2wPs4thg==
Date: Mon, 21 Sep 2015 20:17:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:EfQDai2Kk6GeraBj9yn9/1OnzScmOaMaQ8bRRXzWx1U3ujUGQjncVKzvqRg0d79QjyjqBF6VJZi2PNwo49zxaCV6dxljahdE1w4i+C73nOODKtG8kkxGUGgX53cPGrU3WVLeFlbXbDn8sxSeDcwX6g==; 24:5XfWBwC5602BkG2YpRrAxPCUZRfpED0ugPcYYU+LYaRK6PA4nJyOaWjkM9KHajLht0Rsl2jLHC8yKZVqbiGd6x4DRyq4W2sq50xr7Bsww4s=; 20:5si02YNTi/4B20aMcloYxvuT+Uy7ywcoATw9DBQ/8sYZswu17hACvOH4PB2bp8Ix388hDgWaZ8kH0d60UmH2lw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 07063A0A30
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5423002)(164054003)(189002)(199003)(105586002)(5001960100002)(62966003)(4001350100001)(2900100001)(230783001)(5002640100001)(50986999)(19580395003)(5007970100001)(11100500001)(92566002)(46102003)(54356999)(4001540100001)(189998001)(5004730100002)(107886002)(5001860100001)(68736005)(36756003)(97736004)(106356001)(10400500002)(15975445007)(77156002)(450100001)(66066001)(229853001)(122556002)(102836002)(5001830100001)(81156007)(2351001)(40100003)(110136002)(86362001)(99286002)(2501003)(87936001)(64706001)(83506001)(106116001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2015 20:17:02.7419 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 20:17:07 -0000

This is a notice to start a NETMOD WG last call for the document "JSON
Encoding of Data Modeled with YANG":

	https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05

Please indicate your support by Monday October 5, 2015 at 9PM EDT.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

This is the second Last Call for this document.

Thanks,
Kent



From nobody Mon Sep 21 13:34:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F481A6F03 for ; Mon, 21 Sep 2015 13:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36S5D9xdfoi1 for ; Mon, 21 Sep 2015 13:34:47 -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 E9EF31A6EFB for ; Mon, 21 Sep 2015 13:34:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 67CE974E; Mon, 21 Sep 2015 22:34:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vr0ponYWMg3x; Mon, 21 Sep 2015 22:34:43 +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; Mon, 21 Sep 2015 22:34:43 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C53820054; Mon, 21 Sep 2015 22:34:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fr_ZnugwRn9k; Mon, 21 Sep 2015 22:34:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C2432004E; Mon, 21 Sep 2015 22:34:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 36E4737552B4; Mon, 21 Sep 2015 22:34:39 +0200 (CEST)
Date: Mon, 21 Sep 2015 22:34:39 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150921203439.GB96806@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 20:34:50 -0000

On Wed, Sep 16, 2015 at 08:29:16PM +0200, Ladislav Lhotka wrote:
> 
> > On 16 Sep 2015, at 18:00, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder  wrote:
> > On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
> > > On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
> > > randy_presuhn@mindspring.com> wrote:
> > >
> > > > Hi -
> > > >
> > > > >From: Juergen Schoenwaelder 
> > > > >Sent: Sep 14, 2015 11:41 PM
> > > > >To: Ladislav Lhotka 
> > > > >Cc: NETMOD Working Group 
> > > > >Subject: Re: [netmod] Fwd: New Version Notification for
> > > > draft-ietf-netmod-yang-json-05.txt
> > > > ...
> > > > >My question is why the text is silent about the case where the data
> > > > >model is present. Should it not say that if the data model is present,
> > > > >the data encoded inside the anydata node must follow the rules of this
> > > > >document? Perhaps this is the implicit assumption but I think it will
> > > > >be useful to say this explicitly (if we agree on this).
> > > > >
> > > > >If the data model is not present, then I think an implementation is
> > > > >still expected to produce an encoding that follows the rules of this
> > > > >document as much as possible except that things that requires data
> > > > >model knowledge may be encoded differently (e.g., numbers appearing as
> > > > >strings or namespace names being different). I am thinking along the
> > > > >lines of this proposed new text:
> > > > >
> > > > >   An anydata data node can contain an unknown set of nodes that can
> > > > >   be modelled by YANG. A data model for anydata content may or may
> > > > >   not exist at run time.  If the data model for anydata content is
> > > > >   available, then the anydata content MUST be encoded according to
> > > > >   the rules of this specification. If the data model for anydata
> > > > >   content is not available, the encoding MUST follow the rules of
> > > > >   this specification except for rules that require data model
> > > > >   knowledge (and as a consequence, numbers may appear as strings or
> > > > >   namespace qualifiers may not match module names).
> > > >
> > > > This leaves me wondering what it means for the data model for
> > > > anydata content to be "available".  In the case of ASN.1's
> > > > "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> > > > unambiguously identify the grammar (and associated semantics)
> > > > to be used to understand the content, so tools can, if needed,
> > > > scurry off to obtain the parsing instructions for those
> > > > particular bits.  How does an implementation know in the case
> > > > of "anydata" which datamodel to use?
> > > >
> > > >
> > > Good questions....
> > > The text "If the data model for anydata content is available" gives a hint
> > > of just
> > > what a hack anydata is in YANG.  The definition of anydata is that there is
> > > no data model for the specified subtree.  The mere mention of an out-of-band
> > > data mode is inappropriate and confusing.
> > >
> > > I understand this is intended to support usage like in YANG Patch, where the
> > > description-stmt of 'value' says that the child node must follow the schema
> > > for the node in the target leaf.  More hacks to get YANG to work.
> > 
> > You are welcome to provide fixes.
> > 
> > 
> > OLD:
> > 
> > 
> >   An anydata data node can contain an unknown set of nodes that can
> >   be modelled by YANG. A data model for anydata content may or may
> >    not exist at run time.  If the data model for anydata content is
> >    available, then the anydata content MUST be encoded according to
> >   the rules of this specification. If the data model for anydata
> >   content is not available, the encoding MUST follow the rules of
> >   this specification except for rules that require data model
> >    knowledge (and as a consequence, numbers may appear as strings or
> >   namespace qualifiers may not match module names).
> > 
> > 
> > NEW:
> > 
> >   An anydata data node can contain an unknown set of nodes that can
> >   be modelled by YANG.
> 
> This text is essentially in 6020bis, I see no need to repeat it. 
> 
> >  
> > 
> >  The YANG RFC itself should be silent about data-model specific
> > semantics that are added to an anydata subtree.  The text "if available"
> > is especially non-enforceable and therefore pointless.
> > 
> 
> I must admit I am getting lost in these discussions. It seems to me there is a lot of hand-waving and hidden assumptions that moreover differ from one person to another. As I already said in Prague, both anyxml and anydata are IMO constructs of marginal utility and it is frustrating we spend so much effort on them.
>

I agree that anyxml is of marginal utility, anydata however is needed
for any rpc/action/notification or future language construct that can
work with generic YANG content and hence I think its behaviour and
encoding should be well defined.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 21 13:40:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81B31A6FA0 for ; Mon, 21 Sep 2015 13:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmUgiOoZytaM for ; Mon, 21 Sep 2015 13:40:33 -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 5F8631A6F92 for ; Mon, 21 Sep 2015 13:40:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 02EA1879; Mon, 21 Sep 2015 22:40:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ml4lZ7W3_-03; Mon, 21 Sep 2015 22:40:31 +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; Mon, 21 Sep 2015 22:40:31 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FE4C20054; Mon, 21 Sep 2015 22:40:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iabiqz4zR57w; Mon, 21 Sep 2015 22:40:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 881E52004E; Mon, 21 Sep 2015 22:40:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7EBBD37552F8; Mon, 21 Sep 2015 22:40:29 +0200 (CEST)
Date: Mon, 21 Sep 2015 22:40:29 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20150921204029.GC96806@elstar.local>
Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 20:40:34 -0000

On Wed, Sep 16, 2015 at 11:25:25AM -0700, Andy Bierman wrote:
> 
> The "anyxml" node allows XML-specific details like processing instructions.
> It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> This is academic, because the vast majority of servers do not support anyxml
> at all.  None. Zero.  Not allowed in the server.  The few that do treat
> anyxml
> as if it were anydata.
> 
> The "anydata" node is a blob of YANG data nodes.  It is not XML.
> It is not JSON. This too will likely not be implemented in the vast majority
> of servers.
>

Even very basic things like  need something like anyxml or
anydata. Right now, we write anyxml but usually mean anydata. YANG 1.1
aims at fixing this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 21 13:44:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FBB1A6F65 for ; Mon, 21 Sep 2015 13:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtVDN8gXR7KW for ; Mon, 21 Sep 2015 13:44:09 -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 3444A1A7034 for ; Mon, 21 Sep 2015 13:44:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F1E5874E; Mon, 21 Sep 2015 22:44:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tIz5ViDZPAbY; Mon, 21 Sep 2015 22:44:07 +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; Mon, 21 Sep 2015 22:44:07 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13B8E20053; Mon, 21 Sep 2015 22:44:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fKFxPdd74vPq; Mon, 21 Sep 2015 22:44:06 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD2082004E; Mon, 21 Sep 2015 22:44:05 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C36533755340; Mon, 21 Sep 2015 22:44:05 +0200 (CEST)
Date: Mon, 21 Sep 2015 22:44:05 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150921204405.GD96806@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>     <12FD6338-67B0-4549-9D66-2C69FF0D739F@nic.cz>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 20:44:10 -0000

On Thu, Sep 17, 2015 at 08:24:28AM +0200, Ladislav Lhotka wrote:
> 
> Yes, but the same thing can be done with anyxml, right? It has been
> demonstrated in RFC 6241, ietf-yang-patch and probably elsewhere, too,
> and it does the job.
> 
> The use case of passing around literally "any XML" is really only
> theoretical, I think some kind of schema is always assumed.
> 
> So I believe we don't need two data node types for this purpose. And an
> advantage of anyxml is that its definition (from YANG point of view) is
> clear and unambiguous, whereas for anydata the phrase "can be modelled
> with YANG" may be interpreted in different ways. We are introducing a
> dubious new concept in YANG 1.1 with no apparent gain.
>

I do not think we are going to repeat that debate. I think we
concluded that anyxml does not mean any JSON.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 21 13:53:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21621A902D for ; Mon, 21 Sep 2015 13:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Nw2nzyYxh-H for ; Mon, 21 Sep 2015 13:53:03 -0700 (PDT)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597031A8F4C for ; Mon, 21 Sep 2015 13:53:03 -0700 (PDT)
Received: by lamp12 with SMTP id p12so74807574lam.0 for ; Mon, 21 Sep 2015 13:53:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CteeyFC+6BgTjwcdm7bu3C/vzU3UYkB52GlKHrmtydg=; b=DqTaaalCniS5DvC+vqOb6n7cJNSbvGsIZ+azgP51NdrQA9ExIvHJZflsd17eDmN9CK bPm7IjjIQCBPDOZ7Aci+853lGL+53deHGsKCLEfsfChOqaZKcb9HvduOMNmzltWQTtkS g3pq4GVoGD3WrKK8POYenmX6E7fez08Z0ubgirnGzrZzWj2N9Anoey4lAGwnhlWs5gqe nCrGs07O5/RfwPWbEzrYrnktYsDBMs6/pK8coPdLXuEfzr8b7582RvvAJUmE4miWfMqd eB+2LsOsOJeHVSCepbBEvv1hQGwCawgL9B9NFqeGx48O72WVHBRKIrl72ma6O2rTUrhK snYQ==
X-Gm-Message-State: ALoCoQljbN72lDDptO3nV41FjgqyEsKi1bXimc6TTEszQPFNpeixlLsEtuLqZ7A16Ws6oV+Or8mQ
MIME-Version: 1.0
X-Received: by 10.112.156.167 with SMTP id wf7mr8347850lbb.88.1442868781547; Mon, 21 Sep 2015 13:53:01 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Mon, 21 Sep 2015 13:53:01 -0700 (PDT)
In-Reply-To: <20150921204029.GC96806@elstar.local>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151942.GC76960@elstar.local>   <20150921204029.GC96806@elstar.local>
Date: Mon, 21 Sep 2015 13:53:01 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  Ladislav Lhotka , Randy Presuhn ,  NETMOD Working Group 
Content-Type: multipart/alternative; boundary=001a11c27b262ea0160520481170
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 20:53:05 -0000

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

Hi,

I agree that anydata is much better than anyxml because it represents
how this "schema replacement" is actually being used.

I don't worry about anyxml too much.
It would be better to just rename anyxml, or declare it really
means anydata, but that would not be backward-compatible.

If anyxml "XML semantics" were actually important, then YANG designers would
ask toolkit developers to support it correctly.  Since that has never
happened, it seems clear that anyxml never meant "any XML".


Andy


On Mon, Sep 21, 2015 at 1:40 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Sep 16, 2015 at 11:25:25AM -0700, Andy Bierman wrote:
> >
> > The "anyxml" node allows XML-specific details like processing
> instructions.
> > It is a blob of XML.  It is not JSON.  It is not YANG.  It is XML.
> > This is academic, because the vast majority of servers do not support
> anyxml
> > at all.  None. Zero.  Not allowed in the server.  The few that do treat
> > anyxml
> > as if it were anydata.
> >
> > The "anydata" node is a blob of YANG data nodes.  It is not XML.
> > It is not JSON. This too will likely not be implemented in the vast
> majority
> > of servers.
> >
>
> Even very basic things like  need something like anyxml or
> anydata. Right now, we write anyxml but usually mean anydata. YANG 1.1
> aims at fixing this.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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


Hi,

I agree that anydata is much better=
 than anyxml because it represents
how this "schema replacem=
ent" is actually being used.

I don't worr=
y about anyxml too much.
It would be better to just rename anyxml=
, or declare it really
means anydata, but that would not be backw=
ard-compatible.

If anyxml "XML semantics"=
; were actually important, then YANG designers would
ask toolkit =
developers to support it correctly.=C2=A0 Since that has never
ha=
ppened, it seems clear that anyxml never meant "any XML".


Andy


On Mon, Sep 21, 2015 at 1:4=
0 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni=
versity.de> wrote:
On Wed, =
Sep 16, 2015 at 11:25:25AM -0700, Andy Bierman wrote:

>

> The "anyxml" node allows XML-specific details like processin=
g instructions.

> It is a blob of XML.=C2=A0 It is not JSON.=C2=A0 It is not YANG.=C2=A0=
 It is XML.

> This is academic, because the vast majority of servers do not support =
anyxml

> at all.=C2=A0 None. Zero.=C2=A0 Not allowed in the server.=C2=A0 The f=
ew that do treat

> anyxml

> as if it were anydata.

>

> The "anydata" node is a blob of YANG data nodes.=C2=A0 It is=
 not XML.

> It is not JSON. This too will likely not be implemented in the vast ma=
jority

> of servers.

>



Even very basic things like <get-config> need something like anyxml o=
r

anydata. Right now, we write anyxml but usually mean anydata. YANG 1.1

aims at fixing this.



/js



--

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/>





--001a11c27b262ea0160520481170--


From nobody Mon Sep 21 15:43:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110871ACD86 for ; Mon, 21 Sep 2015 15:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNiv-gq8IQPp for ; Mon, 21 Sep 2015 15:43:02 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 DB4901ACD81 for ; Mon, 21 Sep 2015 15:43:01 -0700 (PDT)
Received: by oixx17 with SMTP id x17so67034328oix.0 for ; Mon, 21 Sep 2015 15:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QRCmTYQCoNF4yWYuFfBDcmFJRYSqbmBvjCfrXLzJ/uU=; b=r8WzZyXmzK5YylMlDxJnd20CBsmiC48kx8XkBgBX1pPrcs+1NNMz/7Dlax/qiKZDKU pZ7VFMcA/ewB2Glb6oxt9guQfEPAdoM1qmjkxh6c1hR9hGsihtGsEBGTh4z3Ed4diYIM vecigG9EzG791uOpC0/tqE+YXzk+1T/hPpW/M1Em+ewDHdr5d9BfWMW5m74CQH8iHEPe HG546InHce7RM4MK0tutYLCxic49eIvWBzrYS+FFAgFkOjr7ReNq8s1Nfnc0oJSAJZIV 0AHYjEi3rX4ETKgQpgeNV6nJqWAXFXdEHniP275oWdEIwU3VzWsI9Bn+QfzPr4ii4O1S J+Gg==
MIME-Version: 1.0
X-Received: by 10.202.175.88 with SMTP id y85mr12972319oie.22.1442875381282; Mon, 21 Sep 2015 15:43:01 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Mon, 21 Sep 2015 15:43:01 -0700 (PDT)
In-Reply-To: 
References:  <20150901164711.GA25138@elstar.local>  <20150901173054.GA25214@elstar.local>  <20150901175824.GA25324@elstar.local> 
Date: Mon, 21 Sep 2015 18:43:01 -0400
Message-ID: 
From: Alia Atlas 
To: "Alexander Clemm (alex)" 
Content-Type: multipart/alternative; boundary=001a113ce4c88e7c1a0520499a01
Archived-At: 
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] tracking new YANG language issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Sep 2015 22:43:04 -0000

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

On Tue, Sep 1, 2015 at 4:52 PM, Alexander Clemm (alex) 
wrote:

> FWIW, I prefer I-D as well.  This is a very well established and very wel=
l
> understood process.  One advantage is that things are very easy to find
> (from the documents page).  Regardless which way is chosen, having the IE=
TF
> datatracker page as an entry point from where to find stuff is IMHO a mus=
t.
>

Just on this point, it is possible to add a URI pointer on a WG's charter
page on the datatracker.  Currently an AD needs to do this.
I've done this for wikis for some RTG working groups.

Regards,
Alia


> --- Alex
>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, September 01, 2015 10:58 AM
> To: Giles Heron 
> Cc: Randy Presuhn ; netmod@ietf.org
> Subject: Re: [netmod] tracking new YANG language issues
>
> On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote:
> > On 1 Sep 2015, at 18:30, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:
> > >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >>>
> > >>> I suggest people write I-Ds if they have any far reaching ideas.
> > >>
> > >> I think GitHub would be better.  The overhead is much lower than
> writing a draft.
> > >>
> > >
> > > IETF processes usually starts with ideas presented in I-Ds. I do not
> > > care much which tools people use to produce I-Ds.
> >
> > sure, that is the process in general.  But I=E2=80=99m unconvinced that=
 it=E2=80=99s the
> right way to proceed with YANG.  E.g. we used a numbered of issues for YA=
NG
> 1.1.  So why not a numbered list of suggestions for YANG 2.0?
> >
>
> The formal answer is that the WG is charted to do YANG 1.1 and not 2.0.
> The other answer is that (a) collecting issues is easy, (b) finding
> agreement on issues is difficult, (c) getting the final text written and
> _all the details that pop up worked out_ is very hard work. Unfortunately=
,
> you see many people working on (a), less people on (b) and finally very f=
ew
> doing (c).
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


On T=
ue, Sep 1, 2015 at 4:52 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:
FWIW, I prefer I-D as well.=
=C2=A0 This is a very well established and very well understood process.=C2=
=A0 One advantage is that things are very easy to find (from the documents =
page).=C2=A0 Regardless which way is chosen, having the IETF datatracker pa=
ge as an entry point from where to find stuff is IMHO a must.

Just on this point, it is possible to add a URI poin=
ter on a WG's charter page on the datatracker.=C2=A0 Currently an AD ne=
eds to do this.
I've done this for wikis for some RTG working=
 groups.

Regards,
Alia
=C2=A0<=
/div>

--- Alex




-----Original Message-----

From: netmod [mailto:netmod-boun=
ces@ietf.org] On Behalf Of Juergen Schoenwaelder

Sent: Tuesday, September 01, 2015 10:58 AM

To: Giles Heron <giles.heron@gm=
ail.com>

Cc: Randy Presuhn <randy=
_presuhn@mindspring.com>; netmod@=
ietf.org

Subject: Re: [netmod] tracking new YANG language issues



On Tue, Sep 01, 2015 at 06:45:55PM +0100, Giles Heron wrote:

> On 1 Sep 2015, at 18:30, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> >

> > On Tue, Sep 01, 2015 at 05:58:59PM +0100, Giles Heron wrote:

> >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univer=
sity.de> wrote:

> >>>

> >>> I suggest people write I-Ds if they have any far reaching=
 ideas.

> >>

> >> I think GitHub would be better.=C2=A0 The overhead is much lo=
wer than writing a draft.

> >>

> >

> > IETF processes usually starts with ideas presented in I-Ds. I do =
not

> > care much which tools people use to produce I-Ds.

>

> sure, that is the process in general.=C2=A0 But I=E2=80=99m unconvince=
d that it=E2=80=99s the right way to proceed with YANG.=C2=A0 E.g. we used =
a numbered of issues for YANG 1.1.=C2=A0 So why not a numbered list of sugg=
estions for YANG 2.0?

>



The formal answer is that the WG is charted to do YANG 1.1 and not 2.0. The=
 other answer is that (a) collecting issues is easy, (b) finding agreement =
on issues is difficult, (c) getting the final text written and _all the det=
ails that pop up worked out_ is very hard work. Unfortunately, you see many=
 people working on (a), less people on (b) and finally very few doing (c).<=
br>


/js



--

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/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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

_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a113ce4c88e7c1a0520499a01--


From nobody Tue Sep 22 02:23:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092EA1A1A54 for ; Tue, 22 Sep 2015 02:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJLuOUEnZZtj for ; Tue, 22 Sep 2015 02:23:15 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D141A1A92 for ; Tue, 22 Sep 2015 02:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3200; q=dns/txt; s=iport; t=1442913787; x=1444123387; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=XHtwiT8qks4b9twA7QjEb+WiABtWrtCEaUmFLF9KvCQ=; b=SEtVUPiAzctNTwphuxTDU3eM8jjiimahuW0/yf9zwOMuOrTG3qGkgUW9 g93A1wVL9n3SsIVSnBJPrry3aszf71TOYVPkfaW4U5kka5uDVOV01Wxxo fLRnj9TeMCuLRCv7K/4Dtte6vccCGVfqdQRmKEozIuVviipVB1l+rHtIK I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQANHQFW/xbLJq1dg3hpvVQBDYFxDIUtSgKBdRQBAQEBAQEBgQqEJAEBAQMBAQEBNTYKEQsOCgkWDwkDAgECARUwBgEMBgIBAYgiCA0DyxoBAQEBAQEBAQEBAQEBAQEBAQEBARQEhnOEfYI+gXYBX4QsAQSVZYURh3iBTYQ1gn6SHR8BAUKEAj0ziCUBH4EoAQEB
X-IronPort-AV: E=Sophos;i="5.17,572,1437436800"; d="scan'208";a="629881025"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 22 Sep 2015 09:23:03 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8M9N3sO007967; Tue, 22 Sep 2015 09:23:03 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:  <55FFCF2F.5010902@cisco.com> 
From: Robert Wilton 
Message-ID: <56011DF7.9020400@cisco.com>
Date: Tue, 22 Sep 2015 10:23:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 09:23:17 -0000

Hi Kent,

Yes, fine with me.

BTW, please can I check that I correctly understand B and C.

Am I right in understanding that B means that multiple top level trees 
would be acceptable, and C means that having the structure defined in 
multiple modules would be acceptable?

Thanks,
Rob


On 21/09/2015 20:09, Kent Watsen wrote:
> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
> as well?
>
> PS: I've moved this issue to the VERIFY state.
>
> Thanks,
> Kent
>
>
>
>
> On 9/21/15, 5:34 AM, "Robert Wilton"  wrote:
>
>> Hi,
>>
>> I suggest changing the wording for A and adding D:
>>
>>     7.  Ability for distinct modules to leverage a common model-structure
>>         A.  Scope is limited to providing a general model-structure only
>>         B.  Multiple domain-specific trees are okay
>>         C.  Multiple namespaces are okay
>>         D.  The model-structure may be used or extended by other
>> organizations.
>>
>> Justifications for (A):
>>   - Limiting the scope to IETF-defined modules almost implies that
>> 'ietf' would end up in the path (which would be wrong/unnecessary).
>>   - Clients don't care which SDO defines the modules for the protocols
>> they use, they just want a coherent organization of modules.
>>   - General structure only to limit the scope because trying to
>> precisely place every protocol/feature is likely to be fragile in the
>> face of future changes.
>>
>> Justifications for (D):
>>   - To suggest and encourage other SDOs to use the same structure, but
>> cannot mandate what they do.
>>
>> Thanks,
>> Rob
>>
>>
>> On 18/09/2015 22:56, Kent Watsen wrote:
>>> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>>>
>>>
>>>     Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>>>               others are now defining YANG modules?
>>>
>>>     Benoit> Good point. We need to provide guidance for the other SDOs.
>>>
>>>
>>> Current text says:
>>>
>>>      7.  Ability for distinct modules to leverage a common
>>> model-structure
>>>          A.  Scope is limited to IETF-defined modules
>>>          B.  Multiple domain-specific trees are okay
>>>          C.  Multiple namespaces are okay
>>>
>>>
>>>
>>> Background:
>>>
>>>     I pulled 7A from Andy's message here:
>>>
>>>       
>>> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>>>
>>>     and put a stake in the ground so that, if nothing else, it could
>>>     be discussed...and here we are!
>>>
>>>     FWIW, I wrote 7A this way because I didn't see how it can be
>>>     enforced outside of the IETF.  But maybe that doesn't matter?
>>>     Of course, we can have 6087bis guidance for other SDOs, but
>>>     I didn't put that in the text.
>>>
>>>
>>> Thoughts on how the text should be updated?
>>>
>>>
>>> PS: Please Reply-All to the list rather than post comments to the GitHub
>>> issue tracker.
>>>
>>>
>>> Thanks,
>>> Kent
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>


From nobody Tue Sep 22 03:00:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367D91A1B5A for ; Tue, 22 Sep 2015 03:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SetWdKwe6NDf for ; Tue, 22 Sep 2015 03:00:11 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33DD1A1B4B for ; Tue, 22 Sep 2015 03:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14018; q=dns/txt; s=iport; t=1442916011; x=1444125611; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ruvWcfkcE5kW8NgO1HalWu+6O5VEboJiF+Py1iPaiFY=; b=V22djARLDQsYhdGRheG5kMMJiUor3ObnKJTlko67vFsZ20yeRExKEcu8 Ru75FmwJcO99Vgnr0oQoMEMdloH+33YXcj1n9mWDZ7oWpI67FLu87V7bh yO6TnHjhD5p+Drx6Nt7jJLtk2xRLESFPMFswMHtEghLau/I/D+vu3TC2O A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CiBAD7JQFW/xbLJq1dgleBIWm/UwELhS1KAoF6EQEBAQEBAQGBCoQlAQEEAQEBIEsKARAJAhgJFggDAgIJAwIBAgEVHxEGDQYCAQEXiBMNA5k+nSuUMQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOEfYI+gXYBWAeCaYFDBZVnhRGHeIFOhDaCfo40g203LIQCPTOIJQEfgSgBAQE
X-IronPort-AV: E=Sophos;i="5.17,572,1437436800";  d="scan'208,217";a="611761544"
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; 22 Sep 2015 10:00:08 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8MA080r027422; Tue, 22 Sep 2015 10:00:08 GMT
To: Andy Bierman 
References:  <55FFCF2F.5010902@cisco.com>  
From: Robert Wilton 
Message-ID: <560126A7.6060307@cisco.com>
Date: Tue, 22 Sep 2015 11:00:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090608030403020801010404"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 10:00:14 -0000

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

Hi Andy,

Please can you clarify. Is your concern specifically with requirement 
7?  Or the full set of requirements in 
draft-chairs-netmod-opstate-reqs-00?

Thanks,
Rob


On 21/09/2015 20:28, Andy Bierman wrote:
> Hi,
>
> I do not think the issue of scope is being considered very carefully.
>
> IMO the solutions being proposed are extremely router-centric.
> (e.g., most NETCONF servers DO NOT have any virtual servers within them).
>
> The larger the scope, the more concern I have that
> the IETF will be pushing expensive solutions on platforms
> that don't have any of the "problems" in the first place.
>
>
> Andy
>
>
>
> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen  > wrote:
>
>
>     Thanks Robert, but I think I like Benoit's edit more.  Are you OK
>     with it
>     as well?
>
>     PS: I've moved this issue to the VERIFY state.
>
>     Thanks,
>     Kent
>
>
>
>
>     On 9/21/15, 5:34 AM, "Robert Wilton"      > wrote:
>
>     >Hi,
>     >
>     >I suggest changing the wording for A and adding D:
>     >
>     >    7.  Ability for distinct modules to leverage a common
>     model-structure
>     >        A.  Scope is limited to providing a general
>     model-structure only
>     >        B.  Multiple domain-specific trees are okay
>     >        C.  Multiple namespaces are okay
>     >        D.  The model-structure may be used or extended by other
>     >organizations.
>     >
>     >Justifications for (A):
>     >  - Limiting the scope to IETF-defined modules almost implies that
>     >'ietf' would end up in the path (which would be wrong/unnecessary).
>     >  - Clients don't care which SDO defines the modules for the
>     protocols
>     >they use, they just want a coherent organization of modules.
>     >  - General structure only to limit the scope because trying to
>     >precisely place every protocol/feature is likely to be fragile in the
>     >face of future changes.
>     >
>     >Justifications for (D):
>     >  - To suggest and encourage other SDOs to use the same
>     structure, but
>     >cannot mandate what they do.
>     >
>     >Thanks,
>     >Rob
>     >
>     >
>     >On 18/09/2015 22:56, Kent Watsen wrote:
>     >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>     >>
>     >>
>     >>    Jonathan> Why does 7(A) limit the scope to IETF-defined
>     modules of
>     >>              others are now defining YANG modules?
>     >>
>     >>    Benoit> Good point. We need to provide guidance for the
>     other SDOs.
>     >>
>     >>
>     >> Current text says:
>     >>
>     >>     7.  Ability for distinct modules to leverage a common
>     >>model-structure
>     >>         A.  Scope is limited to IETF-defined modules
>     >>         B.  Multiple domain-specific trees are okay
>     >>         C.  Multiple namespaces are okay
>     >>
>     >>
>     >>
>     >> Background:
>     >>
>     >>    I pulled 7A from Andy's message here:
>     >>
>     >>
>     >>
>     https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>     >>
>     >>    and put a stake in the ground so that, if nothing else, it could
>     >>    be discussed...and here we are!
>     >>
>     >>    FWIW, I wrote 7A this way because I didn't see how it can be
>     >>    enforced outside of the IETF.  But maybe that doesn't matter?
>     >>    Of course, we can have 6087bis guidance for other SDOs, but
>     >>    I didn't put that in the text.
>     >>
>     >>
>     >> Thoughts on how the text should be updated?
>     >>
>     >>
>     >> PS: Please Reply-All to the list rather than post comments to
>     the GitHub
>     >> issue tracker.
>     >>
>     >>
>     >> Thanks,
>     >> Kent
>     >>
>     >> _______________________________________________
>     >> netmod mailing list
>     >> netmod@ietf.org 
>     >> https://www.ietf.org/mailman/listinfo/netmod
>     >>
>     >
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>


--------------090608030403020801010404
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    Please can you clarify. Is your concern specifically with
    requirement 7?  Or the full set of requirements in
    draft-chairs-netmod-opstate-reqs-00?

    

    Thanks,

    Rob

    

    

    
On 21/09/2015 20:28, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I do not think the issue of scope is being considered very
          carefully.

        


        

        
IMO the solutions being proposed are extremely
          router-centric.

        
(e.g., most NETCONF servers DO NOT have any virtual servers
          within them).

        


        

        
The larger the scope, the more concern I have that

        
the IETF will be pushing expensive solutions on platforms

        
that don't have any of the "problems" in the first place.

        


        

        


        

        
Andy

        


        

        


        

      

      


        
On Mon, Sep 21, 2015 at 12:09 PM, Kent
          Watsen <kwatsen@juniper.net>
          wrote:

          


            Thanks Robert, but I think I like Benoit's edit more.  Are
            you OK with it

            as well?

            

            PS: I've moved this issue to the VERIFY state.

            

            Thanks,

            Kent

            

            

            

            

            On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com>
            wrote:

            

            >Hi,

            >

            >I suggest changing the wording for A and adding D:

            >

            >    7.  Ability for distinct modules to leverage a
            common model-structure

            >        A.  Scope is limited to providing a general
            model-structure only

            >        B.  Multiple domain-specific trees are okay

            >        C.  Multiple namespaces are okay

            >        D.  The model-structure may be used or extended
            by other

            >organizations.

            >

            >Justifications for (A):

            >  - Limiting the scope to IETF-defined modules almost
            implies that

            >'ietf' would end up in the path (which would be
            wrong/unnecessary).

            >  - Clients don't care which SDO defines the modules for
            the protocols

            >they use, they just want a coherent organization of
            modules.

            >  - General structure only to limit the scope because
            trying to

            >precisely place every protocol/feature is likely to be
            fragile in the

            >face of future changes.

            >

            >Justifications for (D):

            >  - To suggest and encourage other SDOs to use the same
            structure, but

            >cannot mandate what they do.

            >

            >Thanks,

            >Rob

            >

            >

            >On 18/09/2015 22:56, Kent Watsen wrote:

            >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7

            >>

            >>

            >>    Jonathan> Why does 7(A) limit the scope to
            IETF-defined modules of

            >>              others are now defining YANG modules?

            >>

            >>    Benoit> Good point. We need to provide
            guidance for the other SDOs.

            >>

            >>

            >> Current text says:

            >>

            >>     7.  Ability for distinct modules to leverage a
            common

            >>model-structure

            >>         A.  Scope is limited to IETF-defined
            modules

            >>         B.  Multiple domain-specific trees are okay

            >>         C.  Multiple namespaces are okay

            >>

            >>

            >>

            >> Background:

            >>

            >>    I pulled 7A from Andy's message here:

            >>

            >>

            >> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

            >>

            >>    and put a stake in the ground so that, if
            nothing else, it could

            >>    be discussed...and here we are!

            >>

            >>    FWIW, I wrote 7A this way because I didn't see
            how it can be

            >>    enforced outside of the IETF.  But maybe that
            doesn't matter?

            >>    Of course, we can have 6087bis guidance for
            other SDOs, but

            >>    I didn't put that in the text.

            >>

            >>

            >> Thoughts on how the text should be updated?

            >>

            >>

            >> PS: Please Reply-All to the list rather than post
            comments to the GitHub

            >> issue tracker.

            >>

            >>

            >> Thanks,

            >> Kent

            >>

            >> _______________________________________________

            >> netmod mailing list

            >> netmod@ietf.org

            >> https://www.ietf.org/mailman/listinfo/netmod

            >>

            >

            

            _______________________________________________

            netmod mailing list

            netmod@ietf.org

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

          

        

        

      

    

    

  


--------------090608030403020801010404--


From nobody Tue Sep 22 05:45:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733621A6FC2 for ; Tue, 22 Sep 2015 05:45:30 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE0Tllh2FsZD for ; Tue, 22 Sep 2015 05:45:26 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF141A6FC3 for ; Tue, 22 Sep 2015 05:45:26 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.274.16; Tue, 22 Sep 2015 12:45:03 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Tue, 22 Sep 2015 12:45:03 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
Thread-Index: AQHQ8lzThTAvqjhhWUW821rJF43C855GvL+AgABdlQCAATGCgP//9VcA
Date: Tue, 22 Sep 2015 12:45:02 +0000
Message-ID: 
References:  <55FFCF2F.5010902@cisco.com>  <56011DF7.9020400@cisco.com>
In-Reply-To: <56011DF7.9020400@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.11]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:AwW2Zhe2FkkxzBBrZ8zRVeb3CdqOu/NhLBWqSJ5AcSq9bmBx9gW+DY39zKCqvcaWSqaSjgeKbgU7shxNQRQrCW12XuejyYYnkoqhIkpsDAI79J3DKTKKDZo7OzEFvg5z+m3OPTO3IkUSvOG3EYhRqA==; 24:OBI5Jsr6Rr6tj3/0bFtCUA0Wdv7PIUiYIGTSiVR+eXxMiLUbxFG2rC26OFtmspy+hKh7x5KX8K/V91hblVgWMSRTRmWLynlLwODwtKbz0bo=; 20:F7uq4IFbPQIbG6jmpm2NYOVoa/ZNhFyyqG01Wb8F6oEheDOGeBw/mond4YiUM7YgHXf8wn/G4+0iOaxKQmgEHQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0707248B64
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(62966003)(87936001)(93886004)(77156002)(46102003)(4001350100001)(4001540100001)(2501003)(10400500002)(11100500001)(66066001)(64706001)(97736004)(5001770100001)(81156007)(36756003)(5004730100002)(5007970100001)(5001860100001)(5001830100001)(2900100001)(122556002)(40100003)(107886002)(5001920100001)(2950100001)(92566002)(5001960100002)(86362001)(106116001)(76176999)(105586002)(106356001)(54356999)(99286002)(83506001)(68736005)(189998001)(5002640100001)(101416001)(50986999)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <95EB5F8369164E47A4CA70EDFE98E0C9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2015 12:45:02.6300 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 12:45:30 -0000

>Yes, fine with me.

Excellent!


>BTW, please can I check that I correctly understand B and C.
>
>Am I right in understanding that B means that multiple top level trees
>would be acceptable, and C means that having the structure defined in
>multiple modules would be acceptable?

Yes, this is what is intended, do you think the text needs to be clarified?


Thanks,
Kent


From nobody Tue Sep 22 06:25:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA91B1A86F0 for ; Tue, 22 Sep 2015 06:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4piJd18OpzvR for ; Tue, 22 Sep 2015 06:25:19 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DE01A86EE for ; Tue, 22 Sep 2015 06:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1442928319; x=1444137919; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tuCpeQ0e/BTnXpSiDV+YjXd/wqY3cUXbb2k8YYqny8w=; b=Am8Uq2QUQ38clHVeEqa+RgGlggwZAxVc4haHqDgQqgna+FaBC6VM5C4O 1qQGSzMBb24YhsZyqH7OTBAtsxPAFf+AahKIUwnNdYhLgwdM3iIoc9bzU clvl0h8xT09K2DRy8Ewpqs8uc5gNVKV+Slbzm8CF6qkr6sLk729Z0q2cL o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbBACGVQFW/xbLJq1dx2GCVgKCDgEBAQEBAYELhCQBAQEDAThAEQsOCgkWDwkDAgECAUUGAQwIAQGIIgjLKwEBAQEBAQEBAQEBAQEBAQEBARqGc4R9hDVfhCwBBJVnjQmBToQ2gn6SIWOEAj2IWYFHAQEB
X-IronPort-AV: E=Sophos;i="5.17,573,1437436800"; d="scan'208";a="607165857"
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; 22 Sep 2015 13:25:16 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8MDPGRY000521; Tue, 22 Sep 2015 13:25:16 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:  <55FFCF2F.5010902@cisco.com>  <56011DF7.9020400@cisco.com> 
From: Robert Wilton 
Message-ID: <560156BB.7050804@cisco.com>
Date: Tue, 22 Sep 2015 14:25:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 13:25:20 -0000

On 22/09/2015 13:45, Kent Watsen wrote:
>
>> Yes, fine with me.
> Excellent!
>
>
>> BTW, please can I check that I correctly understand B and C.
>>
>> Am I right in understanding that B means that multiple top level trees
>> would be acceptable, and C means that having the structure defined in
>> multiple modules would be acceptable?
> Yes, this is what is intended, do you think the text needs to be clarified?
Personally, I don't mind.

For B, I presume that it is both multiple top level trees domain 
specific trees that are being considered, and also potentially multiple 
domain specific trees lower down the hierarchy (e.g. under 
if:interfaces).  If so I think that the current text for B is reasonable.

For C, possibly the following text helps clarify?

OLD:

   7.  Ability for distinct modules to leverage a common model-structure
        A.  Focus on the IETF-defined modules, and ideally provides guidance to other SDOs
        B.  Multiple domain-specific trees are okay
        C.  Multiple namespaces are okay

NEW:

   7.  Ability for distinct modules to leverage a common model-structure
        A.  Focus on the IETF-defined modules, and ideally provides guidance to other SDOs
        B.  Multiple domain-specific trees are okay
        C.  Model-structure may be defined in multiple modules with distinct namespaces.

Thanks,
Rob


>
>
> Thanks,
> Kent
>
>


From nobody Tue Sep 22 06:38:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA381A86F2 for ; Tue, 22 Sep 2015 06:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DGr3MsZgpWE for ; Tue, 22 Sep 2015 06:38:47 -0700 (PDT)
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C04E1A86F3 for ; Tue, 22 Sep 2015 06:38:46 -0700 (PDT)
Received: by lahg1 with SMTP id g1so12732314lah.1 for ; Tue, 22 Sep 2015 06:38:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rns3WHnRWe9sz+oBvLlZG6MNuqWYMMsoer6JEX1//xo=; b=TetNCG4A2Z8qHKTuVp7MCoCD5bc9aW8pa0vr1Rqy6O7/s5AWwnTBUF5LYlWcMf47zy VIaPljQBL00Wxzn29ikO84qfyAPe/0ltCMQVbMdcJZxuT7CwtHjUOnkwjLuiY29VWaX9 ReiE+NR6uvWiU4lSVLbzx8OR2UxRkC1m3CmDAAG5xaulw1yL/wnPT3dDhLItJvn0sp3f HFBzLIlVPvdKtCIUgqpw6Ulg8bDT9GeJxBaxfVeP1iasuoEueZsm6IRF6Qc49bADz5yt kLa4K/WPXFp5O+Z/TRM4Urt7OLz0l75THMfOm03CFH6tjLFkvhJPP+j0p5/TrOdvG8vN P1cQ==
X-Gm-Message-State: ALoCoQnQrQvLyuKpnF1xZI+aBmmz3/AuZmm84I7dit8uvyEQSSq+HG6sin629fkdARPqy71pjfce
MIME-Version: 1.0
X-Received: by 10.112.200.229 with SMTP id jv5mr9654209lbc.123.1442929124472;  Tue, 22 Sep 2015 06:38:44 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 22 Sep 2015 06:38:44 -0700 (PDT)
In-Reply-To: <560126A7.6060307@cisco.com>
References:  <55FFCF2F.5010902@cisco.com>   <560126A7.6060307@cisco.com>
Date: Tue, 22 Sep 2015 06:38:44 -0700
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11c26650e691ec0520561daf
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 13:38:50 -0000

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

On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Please can you clarify. Is your concern specifically with requirement 7?
> Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00
> ?
>
>

My concern is the impact on implementations that do not contain virtual
servers
or do not even contain routers. If the scope of a solution is only routers,
then
it does not matter how router-centric the solution.  But if the scope is
every
device that uses YANG, then it does matter.

To be quite specific:
   - most devices do not require long time intervals  to apply
configuration so any solution
     to identify intended vs. applied config is a waste of resources

  - most devices do not contain virtual servers so placing the data models
in a framework
    for virtualization is a waste of resources

A good engineering solution would only use engineering resources, device
resources,
and/or network resources on platforms that actually have these problems.
It's the  difference between MAY leverage a common model-structure and MUST
leverage
a common model-structure. (Something IETFers should understand).

If the solution really is MAY, then I have no concerns, but I know YANG does
not actually support that, and it probably never will.  Relocatable YANG
would
be rather complicated, so that is not an option at this time.


Thanks,
> Rob
>


Andy


>
>
> On 21/09/2015 20:28, Andy Bierman wrote:
>
> Hi,
>
> I do not think the issue of scope is being considered very carefully.
>
> IMO the solutions being proposed are extremely router-centric.
> (e.g., most NETCONF servers DO NOT have any virtual servers within them).
>
> The larger the scope, the more concern I have that
> the IETF will be pushing expensive solutions on platforms
> that don't have any of the "problems" in the first place.
>
>
> Andy
>
>
>
> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen  wrote:
>
>>
>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
>> as well?
>>
>> PS: I've moved this issue to the VERIFY state.
>>
>> Thanks,
>> Kent
>>
>>
>>
>>
>> On 9/21/15, 5:34 AM, "Robert Wilton" < 
>> rwilton@cisco.com> wrote:
>>
>> >Hi,
>> >
>> >I suggest changing the wording for A and adding D:
>> >
>> >    7.  Ability for distinct modules to leverage a common model-structure
>> >        A.  Scope is limited to providing a general model-structure only
>> >        B.  Multiple domain-specific trees are okay
>> >        C.  Multiple namespaces are okay
>> >        D.  The model-structure may be used or extended by other
>> >organizations.
>> >
>> >Justifications for (A):
>> >  - Limiting the scope to IETF-defined modules almost implies that
>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>> >  - Clients don't care which SDO defines the modules for the protocols
>> >they use, they just want a coherent organization of modules.
>> >  - General structure only to limit the scope because trying to
>> >precisely place every protocol/feature is likely to be fragile in the
>> >face of future changes.
>> >
>> >Justifications for (D):
>> >  - To suggest and encourage other SDOs to use the same structure, but
>> >cannot mandate what they do.
>> >
>> >Thanks,
>> >Rob
>> >
>> >
>> >On 18/09/2015 22:56, Kent Watsen wrote:
>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>> >>
>> >>
>> >>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>> >>              others are now defining YANG modules?
>> >>
>> >>    Benoit> Good point. We need to provide guidance for the other SDOs.
>> >>
>> >>
>> >> Current text says:
>> >>
>> >>     7.  Ability for distinct modules to leverage a common
>> >>model-structure
>> >>         A.  Scope is limited to IETF-defined modules
>> >>         B.  Multiple domain-specific trees are okay
>> >>         C.  Multiple namespaces are okay
>> >>
>> >>
>> >>
>> >> Background:
>> >>
>> >>    I pulled 7A from Andy's message here:
>> >>
>> >>
>> >>
>> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>> >>
>> >>    and put a stake in the ground so that, if nothing else, it could
>> >>    be discussed...and here we are!
>> >>
>> >>    FWIW, I wrote 7A this way because I didn't see how it can be
>> >>    enforced outside of the IETF.  But maybe that doesn't matter?
>> >>    Of course, we can have 6087bis guidance for other SDOs, but
>> >>    I didn't put that in the text.
>> >>
>> >>
>> >> Thoughts on how the text should be updated?
>> >>
>> >>
>> >> PS: Please Reply-All to the list rather than post comments to the
>> GitHub
>> >> issue tracker.
>> >>
>> >>
>> >> Thanks,
>> >> Kent
>> >>
>> >> _______________________________________________
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>> >
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>

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




On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you clarify. Is your concern specifically with
    requirement 7?=C2=A0 Or the full set of requirements in
    draft-chairs-netmod-opstate-reqs-00<=
/span>?

    


My concern is=
 the impact on implementations that do not contain virtual servers
or do not even contain routers. If the scope of a solution is only router=
s, then
it does not matter how router-centric the solution.=C2=A0=
 But if the scope is every
device that uses YANG, then it does ma=
tter.

To be quite specific:
=C2=A0 =C2=
=A0- most devices do not require long time intervals =C2=A0to apply configu=
ration so any solution
=C2=A0 =C2=A0 =C2=A0to identify intended v=
s. applied config is a waste of resources

=C2=A0 -=
 most devices do not contain virtual servers so placing the data models in =
a framework
=C2=A0 =C2=A0 for virtualization is a waste of resour=
ces

A good engineering solution would only use eng=
ineering resources, device resources,
and/or network resources on=
 platforms that actually have these problems.
It's the =C2=A0=
difference between MAY leverage a common model-structure and MUST leverage<=
/div>
a common model-structure. (Something IETFers should understand).<=
/div>

If the solution really is MAY, then I have no conc=
erns, but I know YANG does
not actually support that, and it prob=
ably never will.=C2=A0 Relocatable YANG would
be rather complicat=
ed, so that is not an option at this time.



    Thanks,

    Rob


Andy
=

=C2=A0

    

    

    
On 21/09/2015 20:28, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I do not think the issue of scope is being considered very
          carefully.

        


        

        
IMO the solutions being proposed are extremely
          router-centric.

        
(e.g., most NETCONF servers DO NOT have any virtual servers
          within them).

        


        

        
The larger the scope, the more concern I have that

        
the IETF will be pushing expensive solutions on platforms
        
that don't have any of the "problems" in the fir=
st place.

        


        

        


        

        
Andy

        


        

        


        

      

      


        
On Mon, Sep 21, 2015 at 12:09 PM, Kent
          Watsen <kwatsen@juniper.net>
          wrote:

          


            Thanks Robert, but I think I like Benoit's edit more.=C2=A0=
 Are
            you OK with it

            as well?

            

            PS: I've moved this issue to the VERIFY state.

            

            Thanks,

            Kent

            

            

            

            

            On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com>
            wrote:

            

            >Hi,

            >

            >I suggest changing the wording for A and adding D:

            >

            >=C2=A0 =C2=A0 7.=C2=A0 Ability for distinct modules to leve=
rage a
            common model-structure

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 A.=C2=A0 Scope is limited to pr=
oviding a general
            model-structure only

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 B.=C2=A0 Multiple domain-specif=
ic trees are okay

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 C.=C2=A0 Multiple namespaces ar=
e okay

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 The model-structure ma=
y be used or extended
            by other

            >organizations.

            >

            >Justifications for (A):

            >=C2=A0 - Limiting the scope to IETF-defined modules almost
            implies that

            >'ietf' would end up in the path (which would be
            wrong/unnecessary).

            >=C2=A0 - Clients don't care which SDO defines the modul=
es for
            the protocols

            >they use, they just want a coherent organization of
            modules.

            >=C2=A0 - General structure only to limit the scope because
            trying to

            >precisely place every protocol/feature is likely to be
            fragile in the

            >face of future changes.

            >

            >Justifications for (D):

            >=C2=A0 - To suggest and encourage other SDOs to use the sam=
e
            structure, but

            >cannot mandate what they do.

            >

            >Thanks,

            >Rob

            >

            >

            >On 18/09/2015 22:56, Kent Watsen wrote:

            >> Regarding https://github.com/=
netmod-wg/opstate-reqs/issues/7

            >>

            >>

            >>=C2=A0 =C2=A0 Jonathan> Why does 7(A) limit the scop=
e to
            IETF-defined modules of

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others=
 are now defining YANG modules?

            >>

            >>=C2=A0 =C2=A0 Benoit> Good point. We need to provide
            guidance for the other SDOs.

            >>

            >>

            >> Current text says:

            >>

            >>=C2=A0 =C2=A0 =C2=A07.=C2=A0 Ability for distinct modul=
es to leverage a
            common

            >>model-structure

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A.=C2=A0 Scope is lim=
ited to IETF-defined
            modules

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.=C2=A0 Multiple dom=
ain-specific trees are okay

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C.=C2=A0 Multiple nam=
espaces are okay

            >>

            >>

            >>

            >> Background:

            >>

            >>=C2=A0 =C2=A0 I pulled 7A from Andy's message here:=


            >>

            >>

            >> https:/=
/mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

            >>

            >>=C2=A0 =C2=A0 and put a stake in the ground so that, if
            nothing else, it could

            >>=C2=A0 =C2=A0 be discussed...and here we are!

            >>

            >>=C2=A0 =C2=A0 FWIW, I wrote 7A this way because I didn&=
#39;t see
            how it can be

            >>=C2=A0 =C2=A0 enforced outside of the IETF.=C2=A0 But m=
aybe that
            doesn't matter?

            >>=C2=A0 =C2=A0 Of course, we can have 6087bis guidance f=
or
            other SDOs, but

            >>=C2=A0 =C2=A0 I didn't put that in the text.

            >>

            >>

            >> Thoughts on how the text should be updated?

            >>

            >>

            >> PS: Please Reply-All to the list rather than post
            comments to the GitHub

            >> issue tracker.

            >>

            >>

            >> Thanks,

            >> Kent

            >>

            >> _______________________________________________

            >> netmod mailing list

            >> n=
etmod@ietf.org

            >> https://www.ietf.org/mailman/listin=
fo/netmod

            >>

            >

            

            _______________________________________________

            netmod mailing list

            netmod@iet=
f.org

            https://www.ietf.org/mailman/listinfo/netmod=


          

        

        

      

    

    

  






--001a11c26650e691ec0520561daf--


From nobody Tue Sep 22 07:04:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88F11A8773 for ; Tue, 22 Sep 2015 07:04:41 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huPOZa1e_W-6 for ; Tue, 22 Sep 2015 07:04:37 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0601A876F for ; Tue, 22 Sep 2015 07:04:36 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.274.16; Tue, 22 Sep 2015 14:04:17 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Tue, 22 Sep 2015 14:04:17 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDg==
Date: Tue, 22 Sep 2015 14:04:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.16]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:l3R5Fe8QLeeVwhy86EFAkKi+kuZY7lIHgov7pCiJMYRQ3Hc1qDs+UT/M+xEJXxwaKNOVNOjKHMxMAkZDg2gSTX/b9bZiKDkPXbthtsglKxEQtAdd4IZtkpxf812yhoW2NWM16ZscVzsPWxBb2YVjjQ==; 24:Yv3nliSjYj23QRXt3LJAX5mKdwO/oOFOECXUc/CEnnSzy6/Sg7krLpNiV0A/LKyiE80WPP6NYmQK25meb3B5ugM+GzU47vo90SnDK1KLadY=; 20:SOZVx1iEHQkGKAoqBJ7U22rUx53gwjwdZGNtBxST5qoiSNKII/BEbFB676MAeRJRhFuE/fg6VTDtI8FVLujP9Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0707248B64
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(64706001)(62966003)(83506001)(66066001)(86362001)(46102003)(10400500002)(11100500001)(107886002)(5001960100002)(5004730100002)(102836002)(92566002)(40100003)(5007970100001)(122556002)(5001860100001)(2900100001)(4001350100001)(68736005)(81156007)(5001830100001)(110136002)(5002640100001)(50986999)(189998001)(54356999)(2501003)(101416001)(87936001)(97736004)(4001540100001)(5001920100001)(2351001)(99286002)(229853001)(450100001)(105586002)(106116001)(36756003)(106356001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2015 14:04:16.9853 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 14:04:42 -0000

OK, how about another (hopefully) easy one.

Robert Wilton writes: "It wasn't clear to me where the requirement 3 (A)
came from. I'm not necessarily opposed to it, only that it doesn't appear
to be obviously specified in the openconfig-netmod-opstate draft."


For convenience, Requirement 3 is reproduced below in its entirety:

   3.  Support for both transactional, synchronous management systems as
       well as distributed, asynchronous management systems

       A.  For asynchronous systems, the ability to request a protocol
           operation to not return (i.e. block) until the intended
           configuration has been fully synchronized.

       B.  The protocol operation's response would indicate the result
           of the operation (success, failure, partial, etc.)




Regarding where requirement 3A came from, as the Appendix shows, the
entire requirement #3 is derived from draft-openconfig-netmod-opstate-01,
Section 4.2, which says:

   In a synchronous system, configuration changes are transactional and
   committed as an atomic unit.  This implies that the management system
   knows the success or failure of the configuration change based on the
   return value, and hence knows that the intended configuration matches
   what is on the system (i..e, what has been applied).




Given that we only have asynchronous systems today with NETCONF and
RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
synchronous with a blocking call.   This may have been a bad assumption on
my part, as Anees has since clarified that the solution may not even use
the NETCONF or RESTCONF protocols. Further, rather than assuming we need
to make an asynchronous system synchronous, it could be instead that we
merely just need to accept that synchronous systems may exist somewhere in
the world outside NETCONF/RESTCONF.  To that end, there may not be an
actionable requirement here and we should just remove Requirement #3
altogether.  Thoughts?


PS: please Reply-All to this thread, rather than post comments on the
GitHub issue tracker.

Thanks,
Kent




From nobody Tue Sep 22 07:08:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717E41A87D1 for ; Tue, 22 Sep 2015 07:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.067
X-Spam-Level: 
X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU-V4EwrXMmh for ; Tue, 22 Sep 2015 07:08:42 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 400751A87C7 for ; Tue, 22 Sep 2015 07:08:40 -0700 (PDT)
Received: (qmail 30418 invoked by uid 0); 22 Sep 2015 14:08:38 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 22 Sep 2015 14:08:38 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id LE8R1r00r2SSUrH01E8UWQ; Tue, 22 Sep 2015 08:08:37 -0600
X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=48vgC7mUAAAA:8 a=vxtsQUyxHT8Nuch2A6IA:9 a=vlsxDSXjpfLvvhHQ:21 a=sHwyBUHtkwsvRTjl:21 a=pILNOxqGKmIA:10 a=jO5m9I1TzjoA:10 a=jM_x9b4JT8QA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Cc:From:To:References:Subject; bh=/EWumPC9dUY0GM43PihILFoSamAXx/mQcDR5/O/uJ8o=;  b=dzmEvdL3Rbn8hBbl1uGGBBkrwiO2Ew40JYLEI/GaNzCjKtZ4jPLJWKhuZdURukpNpXyCo2bhtgMxG9ocpYFz0J1Yqe6xm/r+NakCOsxqFPM4VixKf6knMfojBDnPBXfe;
Received: from box313.bluehost.com ([69.89.31.113]:38011 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZeOF8-0007o6-95; Tue, 22 Sep 2015 08:08:26 -0600
References: <20150922004039.18935.56070.idtracker@ietfa.amsl.com>
To: Routing WG , Netmod WG 
From: Lou Berger 
X-Enigmail-Draft-Status: N1110
X-Forwarded-Message-Id: <20150922004039.18935.56070.idtracker@ietfa.amsl.com>
Message-ID: <560160D4.4080006@labn.net>
Date: Tue, 22 Sep 2015 10:08:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150922004039.18935.56070.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: "draft-rtgyangdt-rtgwg-device-model@ietf.org" 
Subject: [netmod] Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 14:08:43 -0000

FYI we've updated the DT draft based on the following:

1) No single /device root 

This has been a topic of major discussion both publicly and within the
DT.  It's our hope that by making this change (okay, compromise),
discussion can now move on to the rest of the proposed structure.

2) The additions to if:interfaces are now shown as augmentations

There seemed to be confusion on the point of what exactly we were
proposing and we hope that this change clarifies the proposal. 

3)  identityref s are now used to identify different types of protocols
within the overall model. 

This approach was based on feedback from Mahesh Jethanandani, as a YANG Dr..

4) We've identified an open discussion/issue on an alternate approach 
to supporting logical network
elements using an enhanced version of draft-clemm-netmod-mount and plan
to explore this with the draft authors.

As always, feedback would be appreciated.

Lou (and co-authors)

-------- Forwarded Message --------
Subject: 	I-D Action: draft-rtgyangdt-rtgwg-device-model-01.txt
Date: 	Mon, 21 Sep 2015 17:40:39 -0700
From: 	internet-drafts@ietf.org
Reply-To: 	internet-drafts@ietf.org
To: 	i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Network Device YANG Organizational Model
        Authors         : Acee Lindem
                          Lou Berger
                          Dean Bogdanovic
                          Christian Hopps
	Filename        : draft-rtgyangdt-rtgwg-device-model-01.txt
	Pages           : 33
	Date            : 2015-09-21

Abstract:
   This document presents an approach for organizing YANG models in a
   comprehensive structure that defines how individual models may be
   composed to configure and operate network infrastructure and
   services.  The structure is itself represented as a YANG model,
   with all of the related component models logically
   organized in a way that is operationally intuitive. This document is
   derived from work submitted to the IETF by members of the informal
   OpenConfig working group of network operators and is a product of the
   Routing Area YANG Architecture design team.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-01


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 Sep 22 07:23:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603D81A88DF for ; Tue, 22 Sep 2015 07:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4Dg0gEAAODV for ; Tue, 22 Sep 2015 07:22:59 -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 E163C1A88DC for ; Tue, 22 Sep 2015 07:22:58 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 60964879; Tue, 22 Sep 2015 16:22:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pSxsViwWPHyK; Tue, 22 Sep 2015 16:22: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; Tue, 22 Sep 2015 16:22:56 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 486B120054; Tue, 22 Sep 2015 16:22:56 +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 VvUyI6Ulg39v; Tue, 22 Sep 2015 16:22: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 1F63720053; Tue, 22 Sep 2015 16:22:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0F83637560E0; Tue, 22 Sep 2015 16:22:54 +0200 (CEST)
Date: Tue, 22 Sep 2015 16:22:54 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150922142254.GB99134@elstar.local>
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 14:23:01 -0000

On Tue, Sep 22, 2015 at 02:04:16PM +0000, Kent Watsen wrote:
> 
> Given that we only have asynchronous systems today with NETCONF and
> RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
> synchronous with a blocking call.   This may have been a bad assumption on
> my part, as Anees has since clarified that the solution may not even use
> the NETCONF or RESTCONF protocols. Further, rather than assuming we need
> to make an asynchronous system synchronous, it could be instead that we
> merely just need to accept that synchronous systems may exist somewhere in
> the world outside NETCONF/RESTCONF.  To that end, there may not be an
> actionable requirement here and we should just remove Requirement #3
> altogether.  Thoughts?
>

Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
Did you messes up the terms throughout this paragraph? If I swap all
of them, the text starts to make sense to me.

/js 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Sep 22 09:02:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA611B2B0C for ; Tue, 22 Sep 2015 09:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v68QJZToX8Cy for ; Tue, 22 Sep 2015 09:02:00 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7531B2B39 for ; Tue, 22 Sep 2015 09:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1442937720; x=1444147320; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=zkkKWaAtRYysFhAR6Cyya+2u3RC3lUVArxskRGDK12k=; b=U5QzPM6i26n9B9AEiW6hJpJ2BSPlg1yArSWCw1pvma8A6NpV3sdaDsIq O8R4NigvuU9t/hh/UJoQBBM+kZGUe4g+6zNYvEJJ9HLMvabxNXao5huTI N3EKHLeOzEX+3OTCTe+YSwXjcwq5X0keeazMSeDtrGAlZOn+/CVrWeTK/ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DIAQCeegFW/xbLJq1dwjwBDYUdglYCgX0UAQEBAQEBAYEKhCUBAQQ4QBELDgoJFgQLCQMCAQIBRQYBDAgBAReIE8sxAQEBAQEBAQEBAQEBAQEBAQEBGoZzhH2EQlKELAEElWeNCYFOhzQjiUOIOx8BAUKCERwWgT89iiABAQE
X-IronPort-AV: E=Sophos;i="5.17,573,1437436800"; d="scan'208";a="611770952"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Sep 2015 16:01:58 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8MG1vJZ011049; Tue, 22 Sep 2015 16:01:58 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:  <20150922142254.GB99134@elstar.local>
From: Robert Wilton 
Message-ID: <56017B76.1040307@cisco.com>
Date: Tue, 22 Sep 2015 17:01:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150922142254.GB99134@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 16:02:02 -0000

On 22/09/2015 15:22, Juergen Schoenwaelder wrote:
> On Tue, Sep 22, 2015 at 02:04:16PM +0000, Kent Watsen wrote:
>> Given that we only have asynchronous systems today with NETCONF and
>> RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
>> synchronous with a blocking call.   This may have been a bad assumption on
>> my part, as Anees has since clarified that the solution may not even use
>> the NETCONF or RESTCONF protocols. Further, rather than assuming we need
>> to make an asynchronous system synchronous, it could be instead that we
>> merely just need to accept that synchronous systems may exist somewhere in
>> the world outside NETCONF/RESTCONF.  To that end, there may not be an
>> actionable requirement here and we should just remove Requirement #3
>> altogether.  Thoughts?
>>
> Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
> Did you messes up the terms throughout this paragraph? If I swap all
> of them, the text starts to make sense to me.
I can see that they are both:
(i) They are synchronous with respect to the config operation. I.e. they 
don't send a reply until the config operation has completed.
(ii) They are asynchronous with respect to the communication.  I.e. the 
client isn't blocked while the config operation is ongoing, and a client 
may send additional requests whilst waiting for a reply.

I believe that the text in draft-openconfig-netmod-opstate-01, Section 
4.2 is mainly concerned with (i) and not (ii), but I read it as 
describing both sync vs async management systems as well as sync vs 
async YANG servers.  From my reading of the text:

The first paragraph of section 4.2 is just describing existing NETCONF 
like protocols.  Hence, no new requirement here, and so I think that 3.A 
can be deleted.

The second paragraph of section 4.2 states that async servers may reply 
early, and applied cfg state is used to check the system state (which is 
effectively already covered as a separate requirement). However, does a 
client need to be able to know that a server will process a particular 
config request, or all config requests, in an asynchronous fashion?  I 
don't think that the opstate draft states this - presumably on the 
assumption is that they can always use intended vs applied config leaves 
for both sync and async servers and so don't need to differentiate.  Is 
this assumption valid for all client/server interactions?

The third paragraph only provides justification and doesn't introduce 
any new requirements.

Thanks,
Rob


>
> /js
>


From nobody Tue Sep 22 09:06:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1142E1B2B62 for ; Tue, 22 Sep 2015 09:06:52 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZKsS_roHXc4 for ; Tue, 22 Sep 2015 09:06:48 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B511B2B61 for ; Tue, 22 Sep 2015 09:06:48 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.274.16; Tue, 22 Sep 2015 16:06:28 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Tue, 22 Sep 2015 16:06:28 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8Cc=
Date: Tue, 22 Sep 2015 16:06:27 +0000
Message-ID: 
References: , <20150922142254.GB99134@elstar.local>
In-Reply-To: <20150922142254.GB99134@elstar.local>
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=kwatsen@juniper.net; 
x-originating-ip: [70.208.135.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:FZIALBtGvJcbCgANfpRfSXhFyXC34InD9HaFtDTb5jOLyUYRqQnqD/T4QGc42TwAtzOm/74CcNjB5S7nW3BpxcJ3Fu71zyCDOFHZu5HIH1u6/cTIOv1NEfy7OVLdtxD8of+mysB0JnGb75GqwwoRtw==; 24:OiY59kPBvK5C9uSkXqp2/xVT5CIlY+LDN3OrvWMC1k1dXtS7ulXKDQX1kLMLI3RkcpXSvdIZrlyorWWwVqN4GtvJqbVo8+Z02hg9LIH7UEM=; 20:tHlnFLUFbpjAUIg/fUV/dgmJpprsNs6LDUK8IqBq8rDZnoRmY1BkWj/dNu+blgNgpElCGhx5EsanVzKpztsqbw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0707248B64
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(40100003)(86362001)(122556002)(82746002)(83716003)(50986999)(87936001)(76176999)(101416001)(54356999)(33656002)(64706001)(92566002)(2950100001)(5007970100001)(2900100001)(11100500001)(5004730100002)(36756003)(66066001)(5002640100001)(10400500002)(81156007)(110136002)(5001960100002)(62966003)(106116001)(102836002)(97736004)(68736005)(46102003)(105586002)(99286002)(77156002)(5001830100001)(189998001)(106356001)(5001860100001)(4001540100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2015 16:06:27.8875 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 16:06:52 -0000

> Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
> Did you messes up the terms throughout this paragraph? If I swap all
> of them, the text starts to make sense to me.

Nope, but I grant you there are terminology issues here.  What I mean, and =
have said before, is that NETCONF/RESTCONF make no assertions with regard t=
o the applied configuration when the RPC-reply or HTTP response is provided=
.   In my experience, only the control plane is updated and sometime later =
the changes are propagated to dataplane.=20

Kent=


From nobody Tue Sep 22 09:20:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4B1B2BBC for ; Tue, 22 Sep 2015 09:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd5gyqOu1wfG for ; Tue, 22 Sep 2015 09:20:21 -0700 (PDT)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 14A321B2BB5 for ; Tue, 22 Sep 2015 09:20:21 -0700 (PDT)
Received: by lagj9 with SMTP id j9so19324434lag.2 for ; Tue, 22 Sep 2015 09:20:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KBzOwa2PFsUzLW8IcO0MQdNdpD2E/kda7AiF/mnjHv4=; b=NY/iqGiAQOPxotrvG5crnBBJmtZjWsZQblGPKV67el+EqHZ45k30oxPEDPA0TQRSun qwDaKO+ZOffMfTc3TrV7eKggvVpFfiKFJw2j3DXY1NDYHO8rZTwxIXycM/9077ujUsVb 0IKZXTgc+3aRfOyUpI/X0Hkrer6DAuxRbtemj99PysC2B5mR7FJecjB2laXWX6fxJJ4K eZkcfu9sHNZe96TRiMFPm0N/xVi6DGVuo20ov/s1/qMake51k7MxwUJtg7P0p2Kg1y08 WMzxNzRdx6ckNVLxKeIhEP7T4IoYpg1MF0xARKCTd2RQkYO7VtUlVa3au+/41PC9RM9s CNyA==
X-Gm-Message-State: ALoCoQnyFY0msR3WORGoqSOOKppTiWQ364DGHTl+bQLzqwps3bCwLMT+Fy84bE9FDFJh6eSvl4EO
MIME-Version: 1.0
X-Received: by 10.152.6.230 with SMTP id e6mr9959638laa.82.1442938819086; Tue, 22 Sep 2015 09:20:19 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 22 Sep 2015 09:20:18 -0700 (PDT)
In-Reply-To: 
References:  <20150922142254.GB99134@elstar.local> 
Date: Tue, 22 Sep 2015 09:20:18 -0700
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=089e013d170ebea5a50520585f87
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 16:20:23 -0000

--089e013d170ebea5a50520585f87
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen  wrote:

>
>
>
> > Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
> > Did you messes up the terms throughout this paragraph? If I swap all
> > of them, the text starts to make sense to me.
>
> Nope, but I grant you there are terminology issues here.  What I mean, and
> have said before, is that NETCONF/RESTCONF make no assertions with regard
> to the applied configuration when the RPC-reply or HTTP response is
> provided.   In my experience, only the control plane is updated and
> sometime later the changes are propagated to dataplane.
>
>

NETCONF and RESTCONF are asynchronous, meaning the client and server
run in separate processes and communication between client and server can
occur at any time.

If the server returns  to an edit request, that means it is accepted in
the intended config.


Kent
>


Andy


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

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




On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen <kwatsen@juniper.net> wrote:






> Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.<=
br>
> Did you messes up the terms throughout this paragraph? If I swap all
> of them, the text starts to make sense to me.



Nope, but I grant you there are terminology issues here.=C2=A0 What I mean,=
 and have said before, is that NETCONF/RESTCONF make no assertions with reg=
ard to the applied configuration when the RPC-reply or HTTP response is pro=
vided.=C2=A0 =C2=A0In my experience, only the control plane is updated and =
sometime later the changes are propagated to dataplane.




NETCONF and RESTCONF ar=
e asynchronous, meaning the client and server
run in separate pro=
cesses and communication between client and server can
occur at a=
ny time.

If the server returns <ok/> to an e=
dit request, that means it is accepted in



--089e013d170ebea5a50520585f87--


From nobody Tue Sep 22 09:38:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0F1B2BF5 for ; Tue, 22 Sep 2015 09:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn8DCRfp-XPY for ; Tue, 22 Sep 2015 09:38:15 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93A41B2BF4 for ; Tue, 22 Sep 2015 09:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6819; q=dns/txt; s=iport; t=1442939896; x=1444149496; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=wtjcWDpOsACsOixdyz3arZewe46RHio55Tc8hHgIBaY=; b=EwgIlrsXzt6UMaRgVTs8HlsqdnlYlUpnXqZMvFcIxLk5H9/ICO+VnhRD C2HgDkqXbMJN3f/CT8vgacV3Bz1jyITB0No/oSX9p2CV9kv+5YmXol8fJ wbQ4hIhS7OL+T6YtD94a31KLFcbrhn3vZk4UQh+rBlJONOqu2UNiq9Iry 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKAQBEgwFW/xbLJq1dg3hpvVoBDYFwAQmFL0oCgX8UAQEBAQEBAYEKhCQBAQEDAQEBAWsKAQULCxgJFgQEBwkDAgECARUfEQYNBgIBAYgiCA3LIQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnOEfYRCSweELAWSPoMpjQmBToc0iWaIOx8BAUKCERwWgT89M4ltAQEB
X-IronPort-AV: E=Sophos;i="5.17,574,1437436800";  d="scan'208,217";a="629891588"
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; 22 Sep 2015 16:38:14 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8MGcCVA010081; Tue, 22 Sep 2015 16:38:12 GMT
To: Andy Bierman 
References:  <20150922142254.GB99134@elstar.local>  
From: Robert Wilton 
Message-ID: <560183F5.5010905@cisco.com>
Date: Tue, 22 Sep 2015 17:38:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090308030505040200070308"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 16:38:21 -0000

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



On 22/09/2015 17:20, Andy Bierman wrote:
>
>
> On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen  > wrote:
>
>
>
>
>     > Big confusion here. NETCONF/RESTCONF is synchronous not
>     asynchronous.
>     > Did you messes up the terms throughout this paragraph? If I swap all
>     > of them, the text starts to make sense to me.
>
>     Nope, but I grant you there are terminology issues here. What I
>     mean, and have said before, is that NETCONF/RESTCONF make no
>     assertions with regard to the applied configuration when the
>     RPC-reply or HTTP response is provided.   In my experience, only
>     the control plane is updated and sometime later the changes are
>     propagated to dataplane.
>
>
>
> NETCONF and RESTCONF are asynchronous, meaning the client and server
> run in separate processes and communication between client and server can
> occur at any time.
>
> If the server returns  to an edit request, that means it is 
> accepted in
> the intended config.

I would expect that if a normal NETCONF server returned  from an 
edit request, then that means that it is accepted in both the intended 
and applied config. I.e. it is what you would get back if you made a 
get-config request.

A server behaving in an async fashion would reply immediately the 
intended config was updated, and the applied config would be updated later.

Thanks,
Rob

>
>
>     Kent
>
>
>
> Andy
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    

    

    
On 22/09/2015 17:20, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Sep 22, 2015 at 9:06 AM, Kent
            Watsen <kwatsen@juniper.net>
            wrote:

            


              

              

              > Big confusion here. NETCONF/RESTCONF is synchronous
              not asynchronous.

              > Did you messes up the terms throughout this
              paragraph? If I swap all

              > of them, the text starts to make sense to me.

              

              Nope, but I grant you there are terminology issues here.
              What I mean, and have said before, is that
              NETCONF/RESTCONF make no assertions with regard to the
              applied configuration when the RPC-reply or HTTP response
              is provided. In my experience, only the control plane is
              updated and sometime later the changes are propagated to
              dataplane.

              

            

            


            

            


            

            
NETCONF and RESTCONF are asynchronous, meaning the
              client and server

            
run in separate processes and communication between
              client and server can

            
occur at any time.

            


            

            
If the server returns <ok/> to an edit request,
              that means it is accepted in

            
the intended config.

          

        

      

    

    

    I would expect that if a normal NETCONF server returned <ok/>
    from an edit request, then that means that it is accepted in both
    the intended and applied config. I.e. it is what you would get back
    if you made a get-config request.

    

    A server behaving in an async fashion would reply immediately the
    intended config was updated, and the applied config would be updated
    later.

    

    Thanks,

    Rob

    

    

      

        

          

            


            

            


            

            

              Kent

            

            


            

            


            

            
Andy

            

            

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

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

            

          

          

        

      

      

      

      

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


    

    

  


--------------090308030505040200070308--


From nobody Tue Sep 22 10:00:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F21B2C11 for ; Tue, 22 Sep 2015 10:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yrlq2Yp7pc5 for ; Tue, 22 Sep 2015 10:00:19 -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 4B19B1B2C10 for ; Tue, 22 Sep 2015 10:00:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5B546A8C; Tue, 22 Sep 2015 19:00:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 17W7IXqZCdDA; Tue, 22 Sep 2015 19:00:16 +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, 22 Sep 2015 19:00:16 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBDB720053; Tue, 22 Sep 2015 19:00:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id S9yqB9rU5HcQ; Tue, 22 Sep 2015 19:00:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E5782004E; Tue, 22 Sep 2015 19:00:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 898753756231; Tue, 22 Sep 2015 19:00:13 +0200 (CEST)
Date: Tue, 22 Sep 2015 19:00:13 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20150922170012.GA99454@elstar.local>
Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod@ietf.org" 
References:  <20150922142254.GB99134@elstar.local>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 17:00:21 -0000

On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:
> 
> NETCONF and RESTCONF are asynchronous, meaning the client and server
> run in separate processes and communication between client and server can
> occur at any time.
>

I thought the openconfig discussion was centered around the server
side...

> If the server returns  to an edit request, that means it is accepted in
> the intended config.

I think we need to use precise terminology otherwise we keep talking
past each other. An  to an  means the edit got
'accepted' (not sure what this term means) in the configuration
datastore being edited, such as  or .

Perhaps  === intended configuration datastore. But I think
it is important to not forget that there are multiple configuration
datastores in NETCONF.

My understanding is that the  operation is synchronous
with respect to the change of the configuration datastore. The
propagation of the data from the  configuration datastore to
the internal pieces of hardware and software being configured may be
asynchronous and is usually considered an implementation detail. The
protocol itself allows asynchronous clients to be written that can
talk to multiple servers and in principle the protocol supports
pipelining of requests from a single client to a single server but all
requests are executed serially. I think the same applies to RESTCONF
but I am a bit less confident.

/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 Sep 22 10:59:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027F81A9153 for ; Tue, 22 Sep 2015 10:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.512
X-Spam-Level: 
X-Spam-Status: No, score=-9.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FU_LOTSOFCOLONS=4.999, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1C5cSCyk8o5 for ; Tue, 22 Sep 2015 10:59:03 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041731A9054 for ; Tue, 22 Sep 2015 10:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5230; q=dns/txt; s=iport; t=1442944743; x=1444154343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tXw28JuhEjkiqXx8lWQYdOtiWc7Je02TiR6jVpOscsU=; b=eoo+OT1KOV4/+6N+OA/WeFBE5Ew6hR6A/Yh5pyJpsA7ND13HBkG/eWm/ KmaEJEeZxuYNkxDZruY3q3ShRMiaNglkV5ZT60zNcAEjjyTR8J9Qh6c+C iw4bNBS7X+JjYTf+3IRZa0XGZFj3WrYldbsdcRz0nhY8ihAXNlYzuuG/0 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DwAQAzlgFW/4ENJK1VCIMkVGkGvVQBDYFwBYU0SgKBSjgUAQEBAQEBAYEKhCQBAQEDAQEBATc0CwUHBAIBCBUhECcLJQEBBAENBQgRAogLCA3LGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9hDYMSweELAWMfAGIagGFEId0gVJGlSKDbAEfAQFCghEcFoE+cQEBiGaBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,574,1437436800"; d="scan'208";a="190614145"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 22 Sep 2015 17:59:02 +0000
Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8MHx2LJ024897 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Sep 2015 17:59:02 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Sep 2015 12:59:01 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Tue, 22 Sep 2015 12:59:00 -0500
From: "Eric Voit (evoit)" 
To: Ladislav Lhotka , Randy Presuhn , "netmod@ietf.org" , "Rob Shakir" 
Thread-Topic: YANG Mount = Alias Mount + Peer Mount    (was RE: [netmod] Motivations for Structuring Models)
Thread-Index: AdDvyhrI2wLjsCf6TN+s18UjF8BE5QEqBWqAADJHufA=
Date: Tue, 22 Sep 2015 17:59:00 +0000
Message-ID: 
References:  
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.229]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Sander Mertens 
Subject: Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 17:59:05 -0000

Hi Lada,

Thanks for your feedback.   I do think that there is value in an integrated=
 technology solution.   OpenDaylight combines (1) and (2) usefully.  For ex=
ample there are examples on the page:
http://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:N=
etconf
such as:
http://localhost:8080/restconf/operations/network-topology:network-topology=
/topology/topology-netconf/node//yang-ext:mount/=20
which enables a server to reference remote device info embedded within a ne=
twork-topology url

Beyond that, OpenDaylight has the ability to do (1) in the form of " loopba=
ck mount".  See:
http://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:T=
utorials:Netconf_Mount#Testing_against_ODL_itself_.28MD-SAL_netconf_northbo=
und_loopback_mount.29
While this is used mostly for testing, aliasing is also viable.

Eric

-----Original Message-----
From: Ladislav Lhotka, September 21, 2015 4:34 AM

Hi Eric,

we are dealing with two rather different problems:

1. A pull-type method for combining YANG schemas as a complement to
   "augment".

2. A proxy function that mediates access to data that are located
   elsewhere.

I believe the recent thread on structuring YANG models has been about #1 wh=
ile both this draft and draft-clemm-netmod-mount-03 mainly address #2. Each=
 problem has its share of issues to solve but the issues don't overlap, so =
I believe it would be useful to keep both problems separate.

Lada

"Eric Voit (evoit)"  writes:

> There was a recent thread on structuring YANG models so that application =
developers might be able to reference alternative local hierarchies/tree st=
ructures for certain objects.  This thread motivated Alex, Sander, and I to=
 rework the YANG Mount requirements draft.  v03 is posted at:
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requireme
> nts/
>
> This draft has been retitled to "Requirements for mounting of local and r=
emote YANG subtrees".  This retitling was done because we have separated th=
e thinking on what it takes to Mount objects from remote devices (Peer Moun=
t) from what it takes to Mount within the same device (Alias Mount).
>
> We would be interested in your thoughts.  =20
>
> Eric
>
> -----Original Message-----
> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>
> Randy Presuhn  writes:
>
>> Hi -
>>
>> It is with no little amusement that I watch this thread struggling=20
>> with questions that were solved fairly neatly a quarter century ago=20
>> in GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would=20
>> like to offer an observation about modeling that might help.
>>
>> The organization of instance data in SNMP is a direct mirror of the=20
>> "object" definitions.  Simple at first, but quickly becoming baroque=20
>> as various minds of "multiplexing" are added to compensate for post=20
>> hoc deficiencies in the index structures.
>>
>> Life is such that once a resource has been modeled, it will be=20
>> used/re-used/embedded in systems in ways in which its designers=20
>> couldn't be expected to imagine.  A consequence of this is that if=20
>> instance naming is completely locked down when the management=20
>> interface for a resource is first defined (as it is in SNMP) then all=20
>> sorts of peculiar hacks will be needed to deal with, for example,=20
>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so=20
>> pervasive that folks seem to overlook that there are other ways to=20
>> deal with this situation.
>>
>> What GDMO did was to use a separate "NAME BINDING" construct to=20
>> specify contexts in which instances might show up, allowing instances=20
>> to be put in places that weren't even imagined when the original=20
>> class definition was written.  Name bindings could be standardized,=20
>> or be vendor or even product-specific, allowing the simplicity or=20
>> complexity of a given system's instance tree to reflect the actual=20
>> simplicity or complexity of that system, rather than requiring all=20
>> systems to be structured for the worst case.
>
> How could this be expressed in YANG terms? (I tried to figure it out myse=
lf but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recomme=
ndation X.722).
>
> Thanks, Lada
>
>>
>> Yes, separating the specification of instance naming in large part=20
>> from class definition does have implications for how one does access=20
>> control, and how clients figure out how to ask a server to create=20
>> something, but it's not a huge deal - it's just not like VACM, and a=20
>> whole slew of hacky solutions and "wierd plumbing adapters" (to=20
>> borrow from Jeff Case) just go away.  Strangely, it makes the job of=20
>> the initial modeler and of the eventual user much easier.
>>
>> Randy
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 22 11:04:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F161A9152 for ; Tue, 22 Sep 2015 11:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sYSUyloWfMf for ; Tue, 22 Sep 2015 11:04:37 -0700 (PDT)
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 4FE171A9139 for ; Tue, 22 Sep 2015 11:04:37 -0700 (PDT)
Received: by lanb10 with SMTP id b10so22012336lan.3 for ; Tue, 22 Sep 2015 11:04:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4gEVxYtchTOFvP6ClwxroWW6YLodzf7sPp6qtDPLrdE=; b=lzi9gxS4TPMi7zwtIfG+0eMOfPbXoYmWl4xm+XgW/enAxN9h/w+TP9JrFTz5zSr5Nn QunP/lg8OJ4MZURkvfirhcBzJ4ynjsJKVR+Fl1IP1Z9BUEsh/XPxQ3CeLvee3qo2z2ag Pk2zLu68JRfF/tPnJVenFUzk1IlGumfgwpOFdoQXjNg5TR14eMUxy942/nrVXv6TXsqb HZsXbzhAjKZzGMU/G53qLhwhrrwVWWetKBXrW91JW0ObnmVy3IQ47y/odLo7JmyH5dBp se7WXqGOYzFxQzd1LKU83DFLvys6vNLIc3snPUG+7f4K89xNFhO9h5akC8LpU5FftmCP 22BQ==
X-Gm-Message-State: ALoCoQlGHOz6WgjlFNCIZV4cBgt69Ycde9ipAxMXqIFgHezQolOgCM4yJzrp9IWXkScF+EetFkfg
MIME-Version: 1.0
X-Received: by 10.112.12.165 with SMTP id z5mr10196351lbb.33.1442945075511; Tue, 22 Sep 2015 11:04:35 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 22 Sep 2015 11:04:35 -0700 (PDT)
In-Reply-To: <20150922170012.GA99454@elstar.local>
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>
Date: Tue, 22 Sep 2015 11:04:35 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  Kent Watsen , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3b830a82686052059d46b
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 18:04:39 -0000

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

On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:
> >
> > NETCONF and RESTCONF are asynchronous, meaning the client and server
> > run in separate processes and communication between client and server can
> > occur at any time.
> >
>
> I thought the openconfig discussion was centered around the server
> side...
>
> > If the server returns  to an edit request, that means it is
> accepted in
> > the intended config.
>
> I think we need to use precise terminology otherwise we keep talking
> past each other. An  to an  means the edit got
> 'accepted' (not sure what this term means) in the configuration
> datastore being edited, such as  or .
>
>

OK -- the edit is accepted as part of the  datastore.
That means is passes the YANG validation tests.
I guess our terminology is so poor that we cannot even describe that
means wrt/ the device or the network.





> Perhaps  === intended configuration datastore. But I think
> it is important to not forget that there are multiple configuration
> datastores in NETCONF.
>
> My understanding is that the  operation is synchronous
> with respect to the change of the configuration datastore. The
> propagation of the data from the  configuration datastore to
> the internal pieces of hardware and software being configured may be
> asynchronous and is usually considered an implementation detail. The
> protocol itself allows asynchronous clients to be written that can
> talk to multiple servers and in principle the protocol supports
> pipelining of requests from a single client to a single server but all
> requests are executed serially. I think the same applies to RESTCONF
> but I am a bit less confident.
>
>

I agree with Carl that there is no problem to solve wrt/ "show running"
being delayed.  I think implementations just return the intended values.

/js
>


Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bier=
man wrote:

>

> NETCONF and RESTCONF are asynchronous, meaning the client and server
> run in separate processes and communication between client and server =
can

> occur at any time.

>



I thought the openconfig discussion was centered around the server

side...



> If the server returns <ok/> to an edit request, that means it is=
 accepted in

> the intended config.



I think we need to use precise terminology otherwise we keep talking

past each other. An <ok/> to an <edit-config> means the edit go=
t

'accepted' (not sure what this term means) in the configuration

datastore being edited, such as <running/> or <candidate/>.




OK -- the edit is accep=
ted as part of the <running> datastore.
That means is passe=
s the YANG validation tests.
I guess our terminology is so poor t=
hat we cannot even describe that
means wrt/ the device or the net=
work.



=C2=A0

Perhaps <running/> =3D=3D=3D intended configuration datastore. But I =
think

it is important to not forget that there are multiple configuration

datastores in NETCONF.



My understanding is that the <edit-config/> operation is synchronous<=
br>
with respect to the change of the configuration datastore. The

propagation of the data from the <running/> configuration datastore t=
o

the internal pieces of hardware and software being configured may be

asynchronous and is usually considered an implementation detail. The

protocol itself allows asynchronous clients to be written that can

talk to multiple servers and in principle the protocol supports

pipelining of requests from a single client to a single server but all

requests are executed serially. I think the same applies to RESTCONF

but I am a bit less confident.




I agree with Carl that there is no pr=
oblem to solve wrt/ "show running"
being delayed.=C2=A0=
 I think implementations just return the intended values.


/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/>





--001a11c3b830a82686052059d46b--


From nobody Tue Sep 22 11:09:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6771A9153 for ; Tue, 22 Sep 2015 11:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.512
X-Spam-Level: 
X-Spam-Status: No, score=-9.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FU_LOTSOFCOLONS=4.999, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZMcdSEWGyN2 for ; Tue, 22 Sep 2015 11:09:04 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190C51A9132 for ; Tue, 22 Sep 2015 11:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7916; q=dns/txt; s=iport; t=1442945344; x=1444154944; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qqBN8llykV7e5gIqjCLmLDYITdqeTkVhI7tI4DUnd5s=; b=dW8Uxw7niZA871L+c7etmiF/sMJFbyefHqq78tdnY0ckulWUjRnlisT3 0rU2Lo+aOwWIsijeHJIevdoX2jJ6S8pKH9Pj3N4UVimVQkM/xgzYsTJcs FLKmjwqDu5GtEyr+FKcOohrlkhtspR1vARvdjw9fRs2SsDH4dQqvW9GlX E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAgBXmAFW/5tdJa1VCIMkVGkGvVQBDYFwDIUtSgIcgS44FAEBAQEBAQGBCoQkAQEBBAEBASAROgsMBAIBCBUFAiYCAgIlCxUQAQEEAQ0FGQKIEw23ApQaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Eiik6ENgwYGBsHgmmBQwWMfAGIagGFEId4gU5GlSKDbR8BAUKCERwWgT5xiGiBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,574,1437436800"; d="scan'208";a="190167083"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2015 18:09:01 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8MI90EW002217 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Sep 2015 18:09:00 GMT
Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Sep 2015 13:08:58 -0500
Received: from xhc-rcd-x12.cisco.com (173.37.183.86) by xch-aln-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 22 Sep 2015 13:08:58 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0248.002; Tue, 22 Sep 2015 13:08:58 -0500
From: "Acee Lindem (acee)" 
To: "Eric Voit (evoit)" , Ladislav Lhotka , Randy Presuhn , "netmod@ietf.org" , Rob Shakir 
Thread-Topic: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
Thread-Index: AdDvyhrI2wLjsCf6TN+s18UjF8BE5QEqBWqAADJHufAAC7VFAA==
Date: Tue, 22 Sep 2015 18:08:57 +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: [173.36.7.24]
Content-Type: text/plain; charset="utf-8"
Content-ID: <14BDCD4F7C4BCC4E8DC11DD5BF215D11@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Sander Mertens 
Subject: Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 18:09:06 -0000

SGkgRXJpYywgTGFkYSwgDQoNCkkgYWdyZWUgd2l0aCBFcmljIHRoYXQgdGhlIG1vdW50IHJlcXVp
cmVtZW50cyBzaG91bGQgaW5jbHVkZSBib3RoIHVzZQ0KY2FzZXMuIFdlIGhhdmUgYmVlbiBkaXNj
dXNzaW5nIHRoaXMgbWVjaGFuaXNtIGFzIHBvdGVudGlhbGx5IHByb3ZpZGluZw0Kc3VwcG9ydCBm
b3IgbWV0YSBtb2RlbCBjb21wb25lbnRzIHRoYXQgbWF5IG9yIG5vdCBiZSBwcmVzZW50IGluIGEg
bmV0d29yaw0KZGV2aWNlLiANCg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiA5LzIyLzE1LCAxOjU5IFBN
LCAibmV0bW9kIG9uIGJlaGFsZiBvZiBFcmljIFZvaXQgKGV2b2l0KSINCjxuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIExh
ZGEsDQo+DQo+VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLiAgIEkgZG8gdGhpbmsgdGhhdCB0aGVy
ZSBpcyB2YWx1ZSBpbiBhbg0KPmludGVncmF0ZWQgdGVjaG5vbG9neSBzb2x1dGlvbi4gICBPcGVu
RGF5bGlnaHQgY29tYmluZXMgKDEpIGFuZCAoMikNCj51c2VmdWxseS4gIEZvciBleGFtcGxlIHRo
ZXJlIGFyZSBleGFtcGxlcyBvbiB0aGUgcGFnZToNCj5odHRwOi8vd2lraS5vcGVuZGF5bGlnaHQu
b3JnL3ZpZXcvT3BlbkRheWxpZ2h0X0NvbnRyb2xsZXI6Q29uZmlnOkV4YW1wbGVzOg0KPk5ldGNv
bmYNCj5zdWNoIGFzOg0KPmh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9yZXN0Y29uZi9vcGVyYXRpb25z
L25ldHdvcmstdG9wb2xvZ3k6bmV0d29yay10b3BvbG9nDQo+eS90b3BvbG9neS90b3BvbG9neS1u
ZXRjb25mL25vZGUvPG5vZGVJZD4veWFuZy1leHQ6bW91bnQvPG9wZXJhdGlvbj4NCj53aGljaCBl
bmFibGVzIGEgc2VydmVyIHRvIHJlZmVyZW5jZSByZW1vdGUgZGV2aWNlIGluZm8gZW1iZWRkZWQg
d2l0aGluIGENCj5uZXR3b3JrLXRvcG9sb2d5IHVybA0KPg0KPkJleW9uZCB0aGF0LCBPcGVuRGF5
bGlnaHQgaGFzIHRoZSBhYmlsaXR5IHRvIGRvICgxKSBpbiB0aGUgZm9ybSBvZiAiDQo+bG9vcGJh
Y2sgbW91bnQiLiAgU2VlOg0KPmh0dHA6Ly93aWtpLm9wZW5kYXlsaWdodC5vcmcvdmlldy9Db250
cm9sbGVyX0NvcmVfRnVuY3Rpb25hbGl0eV9UdXRvcmlhbHM6DQo+VHV0b3JpYWxzOk5ldGNvbmZf
TW91bnQjVGVzdGluZ19hZ2FpbnN0X09ETF9pdHNlbGZfLjI4TUQtU0FMX25ldGNvbmZfbm9ydGgN
Cj5ib3VuZF9sb29wYmFja19tb3VudC4yOQ0KPldoaWxlIHRoaXMgaXMgdXNlZCBtb3N0bHkgZm9y
IHRlc3RpbmcsIGFsaWFzaW5nIGlzIGFsc28gdmlhYmxlLg0KPg0KPkVyaWMNCj4NCj4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IExhZGlzbGF2IExob3RrYSwgU2VwdGVtYmVyIDIx
LCAyMDE1IDQ6MzQgQU0NCj4NCj5IaSBFcmljLA0KPg0KPndlIGFyZSBkZWFsaW5nIHdpdGggdHdv
IHJhdGhlciBkaWZmZXJlbnQgcHJvYmxlbXM6DQo+DQo+MS4gQSBwdWxsLXR5cGUgbWV0aG9kIGZv
ciBjb21iaW5pbmcgWUFORyBzY2hlbWFzIGFzIGEgY29tcGxlbWVudCB0bw0KPiAgICJhdWdtZW50
Ii4NCj4NCj4yLiBBIHByb3h5IGZ1bmN0aW9uIHRoYXQgbWVkaWF0ZXMgYWNjZXNzIHRvIGRhdGEg
dGhhdCBhcmUgbG9jYXRlZA0KPiAgIGVsc2V3aGVyZS4NCj4NCj5JIGJlbGlldmUgdGhlIHJlY2Vu
dCB0aHJlYWQgb24gc3RydWN0dXJpbmcgWUFORyBtb2RlbHMgaGFzIGJlZW4gYWJvdXQgIzENCj53
aGlsZSBib3RoIHRoaXMgZHJhZnQgYW5kIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC0wMyBtYWlu
bHkgYWRkcmVzcyAjMi4NCj5FYWNoIHByb2JsZW0gaGFzIGl0cyBzaGFyZSBvZiBpc3N1ZXMgdG8g
c29sdmUgYnV0IHRoZSBpc3N1ZXMgZG9uJ3QNCj5vdmVybGFwLCBzbyBJIGJlbGlldmUgaXQgd291
bGQgYmUgdXNlZnVsIHRvIGtlZXAgYm90aCBwcm9ibGVtcyBzZXBhcmF0ZS4NCj4NCj5MYWRhDQo+
DQo+IkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cml0ZXM6DQo+DQo+PiBU
aGVyZSB3YXMgYSByZWNlbnQgdGhyZWFkIG9uIHN0cnVjdHVyaW5nIFlBTkcgbW9kZWxzIHNvIHRo
YXQNCj4+YXBwbGljYXRpb24gZGV2ZWxvcGVycyBtaWdodCBiZSBhYmxlIHRvIHJlZmVyZW5jZSBh
bHRlcm5hdGl2ZSBsb2NhbA0KPj5oaWVyYXJjaGllcy90cmVlIHN0cnVjdHVyZXMgZm9yIGNlcnRh
aW4gb2JqZWN0cy4gIFRoaXMgdGhyZWFkIG1vdGl2YXRlZA0KPj5BbGV4LCBTYW5kZXIsIGFuZCBJ
IHRvIHJld29yayB0aGUgWUFORyBNb3VudCByZXF1aXJlbWVudHMgZHJhZnQuICB2MDMgaXMNCj4+
cG9zdGVkIGF0Og0KPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0
LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZQ0KPj4gbnRzLw0KPj4NCj4+IFRoaXMgZHJhZnQg
aGFzIGJlZW4gcmV0aXRsZWQgdG8gIlJlcXVpcmVtZW50cyBmb3IgbW91bnRpbmcgb2YgbG9jYWwg
YW5kDQo+PnJlbW90ZSBZQU5HIHN1YnRyZWVzIi4gIFRoaXMgcmV0aXRsaW5nIHdhcyBkb25lIGJl
Y2F1c2Ugd2UgaGF2ZQ0KPj5zZXBhcmF0ZWQgdGhlIHRoaW5raW5nIG9uIHdoYXQgaXQgdGFrZXMg
dG8gTW91bnQgb2JqZWN0cyBmcm9tIHJlbW90ZQ0KPj5kZXZpY2VzIChQZWVyIE1vdW50KSBmcm9t
IHdoYXQgaXQgdGFrZXMgdG8gTW91bnQgd2l0aGluIHRoZSBzYW1lIGRldmljZQ0KPj4oQWxpYXMg
TW91bnQpLg0KPj4NCj4+IFdlIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4geW91ciB0aG91Z2h0cy4N
Cj4+DQo+PiBFcmljDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206
IExhZGlzbGF2IExob3RrYSwgQXVndXN0IDMxLCAyMDE1IDExOjA1IEFNDQo+Pg0KPj4gUmFuZHkg
UHJlc3VobiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4gd3JpdGVzOg0KPj4NCj4+PiBI
aSAtDQo+Pj4NCj4+PiBJdCBpcyB3aXRoIG5vIGxpdHRsZSBhbXVzZW1lbnQgdGhhdCBJIHdhdGNo
IHRoaXMgdGhyZWFkIHN0cnVnZ2xpbmcNCj4+PiB3aXRoIHF1ZXN0aW9ucyB0aGF0IHdlcmUgc29s
dmVkIGZhaXJseSBuZWF0bHkgYSBxdWFydGVyIGNlbnR1cnkgYWdvDQo+Pj4gaW4gR0RNTy9DTUlQ
LWxhbmQuICBJJ20gKm5vdCogc3VnZ2VzdGluZyB3ZSBnbyBiYWNrIHRoZXJlLCBidXQgd291bGQN
Cj4+PiBsaWtlIHRvIG9mZmVyIGFuIG9ic2VydmF0aW9uIGFib3V0IG1vZGVsaW5nIHRoYXQgbWln
aHQgaGVscC4NCj4+Pg0KPj4+IFRoZSBvcmdhbml6YXRpb24gb2YgaW5zdGFuY2UgZGF0YSBpbiBT
Tk1QIGlzIGEgZGlyZWN0IG1pcnJvciBvZiB0aGUNCj4+PiAib2JqZWN0IiBkZWZpbml0aW9ucy4g
IFNpbXBsZSBhdCBmaXJzdCwgYnV0IHF1aWNrbHkgYmVjb21pbmcgYmFyb3F1ZQ0KPj4+IGFzIHZh
cmlvdXMgbWluZHMgb2YgIm11bHRpcGxleGluZyIgYXJlIGFkZGVkIHRvIGNvbXBlbnNhdGUgZm9y
IHBvc3QNCj4+PiBob2MgZGVmaWNpZW5jaWVzIGluIHRoZSBpbmRleCBzdHJ1Y3R1cmVzLg0KPj4+
DQo+Pj4gTGlmZSBpcyBzdWNoIHRoYXQgb25jZSBhIHJlc291cmNlIGhhcyBiZWVuIG1vZGVsZWQs
IGl0IHdpbGwgYmUNCj4+PiB1c2VkL3JlLXVzZWQvZW1iZWRkZWQgaW4gc3lzdGVtcyBpbiB3YXlz
IGluIHdoaWNoIGl0cyBkZXNpZ25lcnMNCj4+PiBjb3VsZG4ndCBiZSBleHBlY3RlZCB0byBpbWFn
aW5lLiAgQSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgaWYNCj4+PiBpbnN0YW5jZSBuYW1p
bmcgaXMgY29tcGxldGVseSBsb2NrZWQgZG93biB3aGVuIHRoZSBtYW5hZ2VtZW50DQo+Pj4gaW50
ZXJmYWNlIGZvciBhIHJlc291cmNlIGlzIGZpcnN0IGRlZmluZWQgKGFzIGl0IGlzIGluIFNOTVAp
IHRoZW4gYWxsDQo+Pj4gc29ydHMgb2YgcGVjdWxpYXIgaGFja3Mgd2lsbCBiZSBuZWVkZWQgdG8g
ZGVhbCB3aXRoLCBmb3IgZXhhbXBsZSwNCj4+PiB2aXJ0dWFsIHJvdXRlcnMuICBVbmZvcnR1bmF0
ZWx5LCBhbiBTTk1QL1NNSS1saWtlIG1pbmRzZXQgaXMgc28NCj4+PiBwZXJ2YXNpdmUgdGhhdCBm
b2xrcyBzZWVtIHRvIG92ZXJsb29rIHRoYXQgdGhlcmUgYXJlIG90aGVyIHdheXMgdG8NCj4+PiBk
ZWFsIHdpdGggdGhpcyBzaXR1YXRpb24uDQo+Pj4NCj4+PiBXaGF0IEdETU8gZGlkIHdhcyB0byB1
c2UgYSBzZXBhcmF0ZSAiTkFNRSBCSU5ESU5HIiBjb25zdHJ1Y3QgdG8NCj4+PiBzcGVjaWZ5IGNv
bnRleHRzIGluIHdoaWNoIGluc3RhbmNlcyBtaWdodCBzaG93IHVwLCBhbGxvd2luZyBpbnN0YW5j
ZXMNCj4+PiB0byBiZSBwdXQgaW4gcGxhY2VzIHRoYXQgd2VyZW4ndCBldmVuIGltYWdpbmVkIHdo
ZW4gdGhlIG9yaWdpbmFsDQo+Pj4gY2xhc3MgZGVmaW5pdGlvbiB3YXMgd3JpdHRlbi4gIE5hbWUg
YmluZGluZ3MgY291bGQgYmUgc3RhbmRhcmRpemVkLA0KPj4+IG9yIGJlIHZlbmRvciBvciBldmVu
IHByb2R1Y3Qtc3BlY2lmaWMsIGFsbG93aW5nIHRoZSBzaW1wbGljaXR5IG9yDQo+Pj4gY29tcGxl
eGl0eSBvZiBhIGdpdmVuIHN5c3RlbSdzIGluc3RhbmNlIHRyZWUgdG8gcmVmbGVjdCB0aGUgYWN0
dWFsDQo+Pj4gc2ltcGxpY2l0eSBvciBjb21wbGV4aXR5IG9mIHRoYXQgc3lzdGVtLCByYXRoZXIg
dGhhbiByZXF1aXJpbmcgYWxsDQo+Pj4gc3lzdGVtcyB0byBiZSBzdHJ1Y3R1cmVkIGZvciB0aGUg
d29yc3QgY2FzZS4NCj4+DQo+PiBIb3cgY291bGQgdGhpcyBiZSBleHByZXNzZWQgaW4gWUFORyB0
ZXJtcz8gKEkgdHJpZWQgdG8gZmlndXJlIGl0IG91dA0KPj5teXNlbGYgYnV0IEkgdW5mb3J0dW5h
dGVseSBjb3VsZG4ndCBtYWtlIGFueSBzZW5zZSBvZiBzZWMuIDguNiBpbiBDQ0lUVA0KPj5SZWNv
bW1lbmRhdGlvbiBYLjcyMikuDQo+Pg0KPj4gVGhhbmtzLCBMYWRhDQo+Pg0KPj4+DQo+Pj4gWWVz
LCBzZXBhcmF0aW5nIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGluc3RhbmNlIG5hbWluZyBpbiBsYXJn
ZSBwYXJ0DQo+Pj4gZnJvbSBjbGFzcyBkZWZpbml0aW9uIGRvZXMgaGF2ZSBpbXBsaWNhdGlvbnMg
Zm9yIGhvdyBvbmUgZG9lcyBhY2Nlc3MNCj4+PiBjb250cm9sLCBhbmQgaG93IGNsaWVudHMgZmln
dXJlIG91dCBob3cgdG8gYXNrIGEgc2VydmVyIHRvIGNyZWF0ZQ0KPj4+IHNvbWV0aGluZywgYnV0
IGl0J3Mgbm90IGEgaHVnZSBkZWFsIC0gaXQncyBqdXN0IG5vdCBsaWtlIFZBQ00sIGFuZCBhDQo+
Pj4gd2hvbGUgc2xldyBvZiBoYWNreSBzb2x1dGlvbnMgYW5kICJ3aWVyZCBwbHVtYmluZyBhZGFw
dGVycyIgKHRvDQo+Pj4gYm9ycm93IGZyb20gSmVmZiBDYXNlKSBqdXN0IGdvIGF3YXkuICBTdHJh
bmdlbHksIGl0IG1ha2VzIHRoZSBqb2Igb2YNCj4+PiB0aGUgaW5pdGlhbCBtb2RlbGVyIGFuZCBv
ZiB0aGUgZXZlbnR1YWwgdXNlciBtdWNoIGVhc2llci4NCj4+Pg0KPj4+IFJhbmR5DQo+Pj4NCj4+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4NCj4+IC0tDQo+PiBMYWRpc2xhdiBM
aG90a2EsIENaLk5JQyBMYWJzDQo+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4NCj4NCj4tLQ0K
PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPg0K
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9k
IG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Tue Sep 22 11:39:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093081ACD3A for ; Tue, 22 Sep 2015 11:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV1r-GrMlvtH for ; Tue, 22 Sep 2015 11:39:23 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 D59571ACD46 for ; Tue, 22 Sep 2015 11:39:22 -0700 (PDT)
Received: by qkdw123 with SMTP id w123so7984449qkd.0 for ; Tue, 22 Sep 2015 11:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5GEvizdCQ89NXegGl93LztkjrzBWkSrr2Xqhs9KXr1E=; b=YVLtOyW8K8jExQKzR6pYynFwlffA9UrXHQaYhRpjUUPGRPFE/8j1IPfY5u6dwW4U4Q oxX0BrO3Cp/yaiHLsslxdiuCbNOBpcpUiUT/iCYX9uLgdlj8XsLrUW2PM2pzDS8hhecc 74f/AWU7dVmvjXgKcs8+dcUr/4uI6w6cBQXmdmfiod4xk5exWsN+XBEx7CWVaz1C6K5o yB+uwk76DO2ebgVO4hSRM2gjCcDgwnDdo6ZSp7ifTDPoRRGJ3wIMZKqzykgSUZTA+Nmk 55XVwuZgWCkwCZc1qFKfreWWYhktjDmGrgWxd2W2PeiK1zJuhEaMZ8UnXPvtYP9RwRTR FarQ==
X-Received: by 10.55.49.75 with SMTP id x72mr32734019qkx.45.1442947162043; Tue, 22 Sep 2015 11:39:22 -0700 (PDT)
Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id b91sm52036qge.8.2015.09.22.11.39.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Sep 2015 11:39:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2FD4A9EA-39BF-4211-B357-AE8D719FDF68"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Tue, 22 Sep 2015 14:39:20 -0400
Message-Id: <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com>
References:  <55FFCF2F.5010902@cisco.com>   <560126A7.6060307@cisco.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 18:39:26 -0000

--Apple-Mail=_2FD4A9EA-39BF-4211-B357-AE8D719FDF68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Andy,

Mobile operators are sharing infrastructure more and more. They are even =
now considering sharing spectrum. Today there are already use cases =
where Radio Access Network (RAN) is shared between multiple operators =
and they are interested in sharing core resources as well. I can see =
multiple NETCONF servers running on Mobile Switching Center (MSC), =
server per each virtual instance for tenant.

Dean

> On Sep 22, 2015, at 9:38 AM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton > wrote:
> Hi Andy,
>=20
> Please can you clarify. Is your concern specifically with requirement =
7?  Or the full set of requirements in =
draft-chairs-netmod-opstate-reqs-00 =
?
>=20
>=20
>=20
> My concern is the impact on implementations that do not contain =
virtual servers
> or do not even contain routers. If the scope of a solution is only =
routers, then
> it does not matter how router-centric the solution.  But if the scope =
is every
> device that uses YANG, then it does matter.
>=20
> To be quite specific:
>    - most devices do not require long time intervals  to apply =
configuration so any solution
>      to identify intended vs. applied config is a waste of resources
>=20
>   - most devices do not contain virtual servers so placing the data =
models in a framework
>     for virtualization is a waste of resources
>=20
> A good engineering solution would only use engineering resources, =
device resources,
> and/or network resources on platforms that actually have these =
problems.
> It's the  difference between MAY leverage a common model-structure and =
MUST leverage
> a common model-structure. (Something IETFers should understand).
>=20
> If the solution really is MAY, then I have no concerns, but I know =
YANG does
> not actually support that, and it probably never will.  Relocatable =
YANG would
> be rather complicated, so that is not an option at this time.
>=20
>=20
> Thanks,
> Rob
>=20
>=20
> Andy
> =20
>=20
>=20
> On 21/09/2015 20:28, Andy Bierman wrote:
>> Hi,
>>=20
>> I do not think the issue of scope is being considered very carefully.
>>=20
>> IMO the solutions being proposed are extremely router-centric.
>> (e.g., most NETCONF servers DO NOT have any virtual servers within =
them).
>>=20
>> The larger the scope, the more concern I have that
>> the IETF will be pushing expensive solutions on platforms
>> that don't have any of the "problems" in the first place.
>>=20
>>=20
>> Andy
>>=20
>>=20
>>=20
>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen > wrote:
>>=20
>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK =
with it
>> as well?
>>=20
>> PS: I've moved this issue to the VERIFY state.
>>=20
>> Thanks,
>> Kent
>>=20
>>=20
>>=20
>>=20
>> On 9/21/15, 5:34 AM, "Robert Wilton" < =
rwilton@cisco.com > =
wrote:
>>=20
>> >Hi,
>> >
>> >I suggest changing the wording for A and adding D:
>> >
>> >    7.  Ability for distinct modules to leverage a common =
model-structure
>> >        A.  Scope is limited to providing a general model-structure =
only
>> >        B.  Multiple domain-specific trees are okay
>> >        C.  Multiple namespaces are okay
>> >        D.  The model-structure may be used or extended by other
>> >organizations.
>> >
>> >Justifications for (A):
>> >  - Limiting the scope to IETF-defined modules almost implies that
>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>> >  - Clients don't care which SDO defines the modules for the =
protocols
>> >they use, they just want a coherent organization of modules.
>> >  - General structure only to limit the scope because trying to
>> >precisely place every protocol/feature is likely to be fragile in =
the
>> >face of future changes.
>> >
>> >Justifications for (D):
>> >  - To suggest and encourage other SDOs to use the same structure, =
but
>> >cannot mandate what they do.
>> >
>> >Thanks,
>> >Rob
>> >
>> >
>> >On 18/09/2015 22:56, Kent Watsen wrote:
>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7 =

>> >>
>> >>
>> >>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules =
of
>> >>              others are now defining YANG modules?
>> >>
>> >>    Benoit> Good point. We need to provide guidance for the other =
SDOs.
>> >>
>> >>
>> >> Current text says:
>> >>
>> >>     7.  Ability for distinct modules to leverage a common
>> >>model-structure
>> >>         A.  Scope is limited to IETF-defined modules
>> >>         B.  Multiple domain-specific trees are okay
>> >>         C.  Multiple namespaces are okay
>> >>
>> >>
>> >>
>> >> Background:
>> >>
>> >>    I pulled 7A from Andy's message here:
>> >>
>> >>
>> >> =
https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U =
=

>> >>
>> >>    and put a stake in the ground so that, if nothing else, it =
could
>> >>    be discussed...and here we are!
>> >>
>> >>    FWIW, I wrote 7A this way because I didn't see how it can be
>> >>    enforced outside of the IETF.  But maybe that doesn't matter?
>> >>    Of course, we can have 6087bis guidance for other SDOs, but
>> >>    I didn't put that in the text.
>> >>
>> >>
>> >> Thoughts on how the text should be updated?
>> >>
>> >>
>> >> PS: Please Reply-All to the list rather than post comments to the =
GitHub
>> >> issue tracker.
>> >>
>> >>
>> >> Thanks,
>> >> Kent
>> >>
>> >> _______________________________________________
>> >> netmod mailing list
>> >> netmod@ietf.org 
>> >> https://www.ietf.org/mailman/listinfo/netmod =

>> >>
>> >
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

>>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_2FD4A9EA-39BF-4211-B357-AE8D719FDF68
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Andy,

Mobile operators are sharing infrastructure more and more. =
They are even now considering sharing spectrum. Today there are already =
use cases where Radio Access Network (RAN) is shared between multiple =
operators and they are interested in sharing core resources as well. I =
can see multiple NETCONF servers running on Mobile Switching Center =
(MSC), server per each virtual instance for tenant.

Dean

On Sep 22, 2015, at 9:38 AM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Tue, Sep 22, 2015 at 3:00 AM, =
Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you clarify. Is your concern specifically with
    requirement 7?  Or the full set of requirements in
    draft-chairs-netmod-opstate-reqs-00?

    


My =
concern is the impact on implementations that do not contain virtual =
servers
or do not even contain routers. If the =
scope of a solution is only routers, then
it does =
not matter how router-centric the solution.  But if the scope is =
every
device that uses YANG, then it does =
matter.

To be =
quite specific:
   - most devices do not =
require long time intervals  to apply configuration so any =
solution
     to identify intended =
vs. applied config is a waste of resources

  - most devices do not contain =
virtual servers so placing the data models in a framework
    for virtualization is a waste of =
resources

A =
good engineering solution would only use engineering resources, device =
resources,
and/or network resources on platforms =
that actually have these problems.
It's the =
 difference between MAY leverage a common model-structure and MUST =
leverage
a common model-structure. (Something =
IETFers should understand).

If the solution really is MAY, then I have no concerns, but =
I know YANG does
not actually support that, and it =
probably never will.  Relocatable YANG would
be =
rather complicated, so that is not an option at this time.



    Thanks,

    Rob


Andy
 

    

    

    
On 21/09/2015 20:28, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I do not think the issue of scope is being =
considered very
          carefully.

        


        

        
IMO the solutions being proposed are extremely
          router-centric.

        
(e.g., most NETCONF servers DO NOT have any =
virtual servers
          within them).

        


        

        
The larger the scope, the more concern I have =
that

        
the IETF will be pushing expensive solutions on =
platforms

        
that don't have any of the "problems" in the =
first place.

        


        

        


        

        
Andy

        


        

        


        

      

      


        
On Mon, Sep 21, 2015 at 12:09 PM, =
Kent
          Watsen <kwatsen@juniper.net>
          wrote:

          


            Thanks Robert, but I think I like Benoit's edit more.  =
Are
            you OK with it

            as well?

            

            PS: I've moved this issue to the VERIFY state.

            

            Thanks,

            Kent

            

            

            

            

            On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com>
            wrote:

            

            >Hi,

            >

            >I suggest changing the wording for A and adding D:

            >

            >    7.  Ability for distinct modules to =
leverage a
            common model-structure

            >        A.  Scope is limited to =
providing a general
            model-structure only

            >        B.  Multiple =
domain-specific trees are okay

            >        C.  Multiple namespaces =
are okay

            >        D.  The model-structure =
may be used or extended
            by other

            >organizations.

            >

            >Justifications for (A):

            >  - Limiting the scope to IETF-defined modules =
almost
            implies that

            >'ietf' would end up in the path (which would be
            wrong/unnecessary).

            >  - Clients don't care which SDO defines the =
modules for
            the protocols

            >they use, they just want a coherent organization of
            modules.

            >  - General structure only to limit the scope =
because
            trying to

            >precisely place every protocol/feature is likely to be
            fragile in the

            >face of future changes.

            >

            >Justifications for (D):

            >  - To suggest and encourage other SDOs to use the =
same
            structure, but

            >cannot mandate what they do.

            >

            >Thanks,

            >Rob

            >

            >

            >On 18/09/2015 22:56, Kent Watsen wrote:

            >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7

            >>

            >>

            >>    Jonathan> Why does 7(A) limit the =
scope to
            IETF-defined modules of

            >>              =
others are now defining YANG modules?

            >>

            >>    Benoit> Good point. We need to =
provide
            guidance for the other SDOs.

            >>

            >>

            >> Current text says:

            >>

            >>     7.  Ability for distinct =
modules to leverage a
            common

            >>model-structure

            >>         A.  Scope is =
limited to IETF-defined
            modules

            >>         B.  Multiple =
domain-specific trees are okay

            >>         C.  Multiple =
namespaces are okay

            >>

            >>

            >>

            >> Background:

            >>

            >>    I pulled 7A from Andy's message =
here:

            >>

            >>

            >> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZH=
i0CKLD46U

            >>

            >>    and put a stake in the ground so that, =
if
            nothing else, it could

            >>    be discussed...and here we are!

            >>

            >>    FWIW, I wrote 7A this way because I =
didn't see
            how it can be

            >>    enforced outside of the IETF.  =
But maybe that
            doesn't matter?

            >>    Of course, we can have 6087bis =
guidance for
            other SDOs, but

            >>    I didn't put that in the text.

            >>

            >>

            >> Thoughts on how the text should be updated?

            >>

            >>

            >> PS: Please Reply-All to the list rather than post
            comments to the GitHub

            >> issue tracker.

            >>

            >>

            >> Thanks,

            >> Kent

            >>

            >> _______________________________________________

            >> netmod mailing list

            >> netmod@ietf.org

            >> https://www.ietf.org/mailman/listinfo/netmod
=

            >>

            >

            

            _______________________________________________
=

            netmod mailing list

            netmod@ietf.org

            https://www.ietf.org/mailman/listinfo/netmod
=

          

        

        

      

    

    

  





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

=

--Apple-Mail=_2FD4A9EA-39BF-4211-B357-AE8D719FDF68--


From nobody Tue Sep 22 11:46:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4C41ACD96 for ; Tue, 22 Sep 2015 11:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mv3Ik0qh2ur for ; Tue, 22 Sep 2015 11:46:41 -0700 (PDT)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 4E4661ACD93 for ; Tue, 22 Sep 2015 11:46:41 -0700 (PDT)
Received: by lagj9 with SMTP id j9so24294954lag.2 for ; Tue, 22 Sep 2015 11:46:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BkQ1ACd+gQln+wsROLR473pklU+aJfEz79E+nWUqdjw=; b=Sm5KU/Yn/eUInHZx8duRzNzF4e1UvX0ob25uromaKnTNfgLVISiiJzUP+Ht/2gWhOl 3e/seTiBbq+YkGAv/HmuF7xdlOvCFNGrdM+TZh+za2MTuuj7PlN+LySnvEdlh76wRatt QdDQjxFBaOJIEcoFfoUq4KMRgoqWzo+9N3ko8OGKaa+5ZjGvPHmsG6vMgElG70V8AM7a t1ixH5NYlFml+ULzu2kFvShNJRBj/ioHp6wgS+i/FpnSjLdimmnDbgxXMhXoXnQJjJnU FPkASRFNzyHtEPS56ZYYxY4ckEpHR3RtB9SsyP9r9kBG+qcN6PE6E5idtJIP/W+TB1O5 e2bQ==
X-Gm-Message-State: ALoCoQmYi0tOBSRVv+WkkuP3Ita91ioQsuUpuqEeTB+MXL+UbXVUzXLZ418EyGd6aFSqYspeFW1E
MIME-Version: 1.0
X-Received: by 10.25.145.132 with SMTP id t126mr3040602lfd.88.1442947599233; Tue, 22 Sep 2015 11:46:39 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 22 Sep 2015 11:46:39 -0700 (PDT)
In-Reply-To: <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com>
References:  <55FFCF2F.5010902@cisco.com>   <560126A7.6060307@cisco.com>  <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com>
Date: Tue, 22 Sep 2015 11:46:39 -0700
Message-ID: 
From: Andy Bierman 
To: Dean Bogdanovic 
Content-Type: multipart/alternative; boundary=001a1140389215117205205a6b7f
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 18:46:45 -0000

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

On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic 
wrote:

> Andy,
>
> Mobile operators are sharing infrastructure more and more. They are even
> now considering sharing spectrum. Today there are already use cases where
> Radio Access Network (RAN) is shared between multiple operators and they
> are interested in sharing core resources as well. I can see multiple
> NETCONF servers running on Mobile Switching Center (MSC), server per each
> virtual instance for tenant.
>
>
That's all fine but it does not alter my opinion at all that platforms that
do not need this feature should not be impacted by it.  If that means that
YANG will "fork" into a solution for big routers and a different solution
for not-a-routers, then that's fine.  The market can decide better than the
IETF anyway.


Dean
>

Andy


>
> On Sep 22, 2015, at 9:38 AM, Andy Bierman  wrote:
>
>
>
> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Please can you clarify. Is your concern specifically with requirement 7?
>> Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00
>> ?
>>
>>
>
> My concern is the impact on implementations that do not contain virtual
> servers
> or do not even contain routers. If the scope of a solution is only
> routers, then
> it does not matter how router-centric the solution.  But if the scope is
> every
> device that uses YANG, then it does matter.
>
> To be quite specific:
>    - most devices do not require long time intervals  to apply
> configuration so any solution
>      to identify intended vs. applied config is a waste of resources
>
>   - most devices do not contain virtual servers so placing the data models
> in a framework
>     for virtualization is a waste of resources
>
> A good engineering solution would only use engineering resources, device
> resources,
> and/or network resources on platforms that actually have these problems.
> It's the  difference between MAY leverage a common model-structure and
> MUST leverage
> a common model-structure. (Something IETFers should understand).
>
> If the solution really is MAY, then I have no concerns, but I know YANG
> does
> not actually support that, and it probably never will.  Relocatable YANG
> would
> be rather complicated, so that is not an option at this time.
>
>
> Thanks,
>> Rob
>>
>
>
> Andy
>
>
>>
>>
>> On 21/09/2015 20:28, Andy Bierman wrote:
>>
>> Hi,
>>
>> I do not think the issue of scope is being considered very carefully.
>>
>> IMO the solutions being proposed are extremely router-centric.
>> (e.g., most NETCONF servers DO NOT have any virtual servers within them).
>>
>> The larger the scope, the more concern I have that
>> the IETF will be pushing expensive solutions on platforms
>> that don't have any of the "problems" in the first place.
>>
>>
>> Andy
>>
>>
>>
>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen 
>> wrote:
>>
>>>
>>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
>>> as well?
>>>
>>> PS: I've moved this issue to the VERIFY state.
>>>
>>> Thanks,
>>> Kent
>>>
>>>
>>>
>>>
>>> On 9/21/15, 5:34 AM, "Robert Wilton" < 
>>> rwilton@cisco.com> wrote:
>>>
>>> >Hi,
>>> >
>>> >I suggest changing the wording for A and adding D:
>>> >
>>> >    7.  Ability for distinct modules to leverage a common
>>> model-structure
>>> >        A.  Scope is limited to providing a general model-structure only
>>> >        B.  Multiple domain-specific trees are okay
>>> >        C.  Multiple namespaces are okay
>>> >        D.  The model-structure may be used or extended by other
>>> >organizations.
>>> >
>>> >Justifications for (A):
>>> >  - Limiting the scope to IETF-defined modules almost implies that
>>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>>> >  - Clients don't care which SDO defines the modules for the protocols
>>> >they use, they just want a coherent organization of modules.
>>> >  - General structure only to limit the scope because trying to
>>> >precisely place every protocol/feature is likely to be fragile in the
>>> >face of future changes.
>>> >
>>> >Justifications for (D):
>>> >  - To suggest and encourage other SDOs to use the same structure, but
>>> >cannot mandate what they do.
>>> >
>>> >Thanks,
>>> >Rob
>>> >
>>> >
>>> >On 18/09/2015 22:56, Kent Watsen wrote:
>>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>>> >>
>>> >>
>>> >>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>>> >>              others are now defining YANG modules?
>>> >>
>>> >>    Benoit> Good point. We need to provide guidance for the other SDOs.
>>> >>
>>> >>
>>> >> Current text says:
>>> >>
>>> >>     7.  Ability for distinct modules to leverage a common
>>> >>model-structure
>>> >>         A.  Scope is limited to IETF-defined modules
>>> >>         B.  Multiple domain-specific trees are okay
>>> >>         C.  Multiple namespaces are okay
>>> >>
>>> >>
>>> >>
>>> >> Background:
>>> >>
>>> >>    I pulled 7A from Andy's message here:
>>> >>
>>> >>
>>> >>
>>> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>>> >>
>>> >>    and put a stake in the ground so that, if nothing else, it could
>>> >>    be discussed...and here we are!
>>> >>
>>> >>    FWIW, I wrote 7A this way because I didn't see how it can be
>>> >>    enforced outside of the IETF.  But maybe that doesn't matter?
>>> >>    Of course, we can have 6087bis guidance for other SDOs, but
>>> >>    I didn't put that in the text.
>>> >>
>>> >>
>>> >> Thoughts on how the text should be updated?
>>> >>
>>> >>
>>> >> PS: Please Reply-All to the list rather than post comments to the
>>> GitHub
>>> >> issue tracker.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Kent
>>> >>
>>> >> _______________________________________________
>>> >> netmod mailing list
>>> >> netmod@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/netmod
>>> >>
>>> >
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>

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




On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic <=
;ivandean@gmail.com=
> wrote:
Andy,

Mobile operators are sharing inf=
rastructure more and more. They are even now considering sharing spectrum. =
Today there are already use cases where Radio Access Network (RAN) is share=
d between multiple operators and they are interested in sharing core resour=
ces as well. I can see multiple NETCONF servers running on Mobile Switching=
 Center (MSC), server per each virtual instance for tenant.

<=
/div>

That's all fine but it does=
 not alter my opinion at all that platforms that
do not need this=
 feature should not be impacted by it.=C2=A0 If that means that
Y=
ANG will "fork" into a solution for big routers and a different s=
olution
for not-a-routers, then that's fine.=C2=A0 The market=
 can decide better than the IETF anyway.


Dean

Andy
=
=C2=A0

On Sep 22, 2015, at 9:38 A=
M, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Sep 22, 2015 a=
t 3:00 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you clarify. Is your concern specifically with
    requirement 7?=C2=A0 Or the full set of requirements in
    draft-chairs-netmod-opstate-reqs-00<=
/span>?

    


My concern is=
 the impact on implementations that do not contain virtual servers
or do not even contain routers. If the scope of a solution is only router=
s, then
it does not matter how router-centric the solution.=C2=A0=
 But if the scope is every
device that uses YANG, then it does ma=
tter.

To be quite specific:
=C2=A0 =C2=
=A0- most devices do not require long time intervals =C2=A0to apply configu=
ration so any solution
=C2=A0 =C2=A0 =C2=A0to identify intended v=
s. applied config is a waste of resources

=C2=A0 -=
 most devices do not contain virtual servers so placing the data models in =
a framework
=C2=A0 =C2=A0 for virtualization is a waste of resour=
ces

A good engineering solution would only use eng=
ineering resources, device resources,
and/or network resources on=
 platforms that actually have these problems.
It's the =C2=A0=
difference between MAY leverage a common model-structure and MUST leverage<=
/div>
a common model-structure. (Something IETFers should understand).<=
/div>

If the solution really is MAY, then I have no conc=
erns, but I know YANG does
not actually support that, and it prob=
ably never will.=C2=A0 Relocatable YANG would
be rather complicat=
ed, so that is not an option at this time.



    Thanks,

    Rob


Andy
=

=C2=A0

    

    

    
On 21/09/2015 20:28, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I do not think the issue of scope is being considered very
          carefully.

        


        

        
IMO the solutions being proposed are extremely
          router-centric.

        
(e.g., most NETCONF servers DO NOT have any virtual servers
          within them).

        


        

        
The larger the scope, the more concern I have that

        
the IETF will be pushing expensive solutions on platforms
        
that don't have any of the "problems" in the fir=
st place.

        


        

        


        

        
Andy

        


        

        


        

      

      


        
On Mon, Sep 21, 2015 at 12:09 PM, Kent
          Watsen <kwatsen@juniper.net>
          wrote:

          


            Thanks Robert, but I think I like Benoit's edit more.=C2=A0=
 Are
            you OK with it

            as well?

            

            PS: I've moved this issue to the VERIFY state.

            

            Thanks,

            Kent

            

            

            

            

            On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com>
            wrote:

            

            >Hi,

            >

            >I suggest changing the wording for A and adding D:

            >

            >=C2=A0 =C2=A0 7.=C2=A0 Ability for distinct modules to leve=
rage a
            common model-structure

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 A.=C2=A0 Scope is limited to pr=
oviding a general
            model-structure only

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 B.=C2=A0 Multiple domain-specif=
ic trees are okay

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 C.=C2=A0 Multiple namespaces ar=
e okay

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 The model-structure ma=
y be used or extended
            by other

            >organizations.

            >

            >Justifications for (A):

            >=C2=A0 - Limiting the scope to IETF-defined modules almost
            implies that

            >'ietf' would end up in the path (which would be
            wrong/unnecessary).

            >=C2=A0 - Clients don't care which SDO defines the modul=
es for
            the protocols

            >they use, they just want a coherent organization of
            modules.

            >=C2=A0 - General structure only to limit the scope because
            trying to

            >precisely place every protocol/feature is likely to be
            fragile in the

            >face of future changes.

            >

            >Justifications for (D):

            >=C2=A0 - To suggest and encourage other SDOs to use the sam=
e
            structure, but

            >cannot mandate what they do.

            >

            >Thanks,

            >Rob

            >

            >

            >On 18/09/2015 22:56, Kent Watsen wrote:

            >> Regarding https://github.com/=
netmod-wg/opstate-reqs/issues/7

            >>

            >>

            >>=C2=A0 =C2=A0 Jonathan> Why does 7(A) limit the scop=
e to
            IETF-defined modules of

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others=
 are now defining YANG modules?

            >>

            >>=C2=A0 =C2=A0 Benoit> Good point. We need to provide
            guidance for the other SDOs.

            >>

            >>

            >> Current text says:

            >>

            >>=C2=A0 =C2=A0 =C2=A07.=C2=A0 Ability for distinct modul=
es to leverage a
            common

            >>model-structure

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A.=C2=A0 Scope is lim=
ited to IETF-defined
            modules

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.=C2=A0 Multiple dom=
ain-specific trees are okay

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C.=C2=A0 Multiple nam=
espaces are okay

            >>

            >>

            >>

            >> Background:

            >>

            >>=C2=A0 =C2=A0 I pulled 7A from Andy's message here:=


            >>

            >>

            >> https:/=
/mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

            >>

            >>=C2=A0 =C2=A0 and put a stake in the ground so that, if
            nothing else, it could

            >>=C2=A0 =C2=A0 be discussed...and here we are!

            >>

            >>=C2=A0 =C2=A0 FWIW, I wrote 7A this way because I didn&=
#39;t see
            how it can be

            >>=C2=A0 =C2=A0 enforced outside of the IETF.=C2=A0 But m=
aybe that
            doesn't matter?

            >>=C2=A0 =C2=A0 Of course, we can have 6087bis guidance f=
or
            other SDOs, but

            >>=C2=A0 =C2=A0 I didn't put that in the text.

            >>

            >>

            >> Thoughts on how the text should be updated?

            >>

            >>

            >> PS: Please Reply-All to the list rather than post
            comments to the GitHub

            >> issue tracker.

            >>

            >>

            >> Thanks,

            >> Kent

            >>

            >> _______________________________________________

            >> netmod mailing list

            >> n=
etmod@ietf.org

            >> https://www.ietf.org/mailman/listin=
fo/netmod

            >>

            >

            

            _______________________________________________

            netmod mailing list

            netmod@iet=
f.org

            https://www.ietf.org/mailman/listinfo/netmod=


          

        

        

      

    

    

  





_______________________________________________
netmod mailing list
<=
a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
=
=
https://www.ietf.org/mailman/listinfo/netmod




--001a1140389215117205205a6b7f--


From nobody Tue Sep 22 11:53:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEB01ACD8E for ; Tue, 22 Sep 2015 11:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siSjqa6oeHrq for ; Tue, 22 Sep 2015 11:53:52 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 5FB791AC3A7 for ; Tue, 22 Sep 2015 11:53:52 -0700 (PDT)
Received: by qgez77 with SMTP id z77so1503247qge.1 for ; Tue, 22 Sep 2015 11:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=sh5wTBU92zvP9vn2X5HO9nwm37UE3Tbq5y9quzT6HQo=; b=G3NFkbgzZBQqQXA9sPCGVLItwIispr+i40EameRL+L76xQ3O7xXdLOt+ViHt1gmFWJ CqcaXVHSckWnNYm6tN7m3APRihrjjggu7+ANFF6qDC6pgzbZhSbIGuzXThF3SFF8Mk7G xnTNZX5Nty/xBByGP1tmokqVZdEYS8qyAeRQiNsdr/hLSYkSH+x6tVezw4TLMd51/Guc +WvUuHKWlrNyKKSfNSMDl4ZE/6xChb8nN0mBkbmH7IzoKIXM5Tg8Am+lof6qzV4MLcUt q46JYjbJ/RY7dn59+4ryvQTGOCuTsm82BHBFmqaSgv+GUpLVWWbj3TnVg0FY5nN2ntuZ fKsQ==
X-Received: by 10.140.27.161 with SMTP id 30mr31298553qgx.4.1442948031554; Tue, 22 Sep 2015 11:53:51 -0700 (PDT)
Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id 80sm1114299qhy.6.2015.09.22.11.53.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Sep 2015 11:53:51 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3796B18C-DF78-4B5F-9B52-9A9393927C0C"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Tue, 22 Sep 2015 14:53:49 -0400
Message-Id: <4E27FAA2-977C-4306-9776-5A5CD4EB01E7@gmail.com>
References:  <55FFCF2F.5010902@cisco.com>   <560126A7.6060307@cisco.com>  <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 18:53:56 -0000

--Apple-Mail=_3796B18C-DF78-4B5F-9B52-9A9393927C0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Sep 22, 2015, at 2:46 PM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic > wrote:
> Andy,
>=20
> Mobile operators are sharing infrastructure more and more. They are =
even now considering sharing spectrum. Today there are already use cases =
where Radio Access Network (RAN) is shared between multiple operators =
and they are interested in sharing core resources as well. I can see =
multiple NETCONF servers running on Mobile Switching Center (MSC), =
server per each virtual instance for tenant.
>=20
>=20
> That's all fine but it does not alter my opinion at all that platforms =
that
> do not need this feature should not be impacted by it.  If that means =
that
> YANG will "fork" into a solution for big routers and a different =
solution
> for not-a-routers, then that's fine.  The market can decide better =
than the IETF anyway.

To certain extent agree with your comment. But when you are talking =
about forking YANG for different domains, shouldn=E2=80=99t we try to =
have features in YANG and then implementers can decide which features =
they want to use? And then market can decide, which implementations they =
like the best?

Dean

>=20
>=20
> Dean
>=20
> Andy
> =20
>=20
>> On Sep 22, 2015, at 9:38 AM, Andy Bierman > wrote:
>>=20
>>=20
>>=20
>> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton > wrote:
>> Hi Andy,
>>=20
>> Please can you clarify. Is your concern specifically with requirement =
7?  Or the full set of requirements in =
draft-chairs-netmod-opstate-reqs-00 =
?
>>=20
>>=20
>>=20
>> My concern is the impact on implementations that do not contain =
virtual servers
>> or do not even contain routers. If the scope of a solution is only =
routers, then
>> it does not matter how router-centric the solution.  But if the scope =
is every
>> device that uses YANG, then it does matter.
>>=20
>> To be quite specific:
>>    - most devices do not require long time intervals  to apply =
configuration so any solution
>>      to identify intended vs. applied config is a waste of resources
>>=20
>>   - most devices do not contain virtual servers so placing the data =
models in a framework
>>     for virtualization is a waste of resources
>>=20
>> A good engineering solution would only use engineering resources, =
device resources,
>> and/or network resources on platforms that actually have these =
problems.
>> It's the  difference between MAY leverage a common model-structure =
and MUST leverage
>> a common model-structure. (Something IETFers should understand).
>>=20
>> If the solution really is MAY, then I have no concerns, but I know =
YANG does
>> not actually support that, and it probably never will.  Relocatable =
YANG would
>> be rather complicated, so that is not an option at this time.
>>=20
>>=20
>> Thanks,
>> Rob
>>=20
>>=20
>> Andy
>> =20
>>=20
>>=20
>> On 21/09/2015 20:28, Andy Bierman wrote:
>>> Hi,
>>>=20
>>> I do not think the issue of scope is being considered very =
carefully.
>>>=20
>>> IMO the solutions being proposed are extremely router-centric.
>>> (e.g., most NETCONF servers DO NOT have any virtual servers within =
them).
>>>=20
>>> The larger the scope, the more concern I have that
>>> the IETF will be pushing expensive solutions on platforms
>>> that don't have any of the "problems" in the first place.
>>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>>>=20
>>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen > wrote:
>>>=20
>>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK =
with it
>>> as well?
>>>=20
>>> PS: I've moved this issue to the VERIFY state.
>>>=20
>>> Thanks,
>>> Kent
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 9/21/15, 5:34 AM, "Robert Wilton" < =
rwilton@cisco.com > =
wrote:
>>>=20
>>> >Hi,
>>> >
>>> >I suggest changing the wording for A and adding D:
>>> >
>>> >    7.  Ability for distinct modules to leverage a common =
model-structure
>>> >        A.  Scope is limited to providing a general model-structure =
only
>>> >        B.  Multiple domain-specific trees are okay
>>> >        C.  Multiple namespaces are okay
>>> >        D.  The model-structure may be used or extended by other
>>> >organizations.
>>> >
>>> >Justifications for (A):
>>> >  - Limiting the scope to IETF-defined modules almost implies that
>>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>>> >  - Clients don't care which SDO defines the modules for the =
protocols
>>> >they use, they just want a coherent organization of modules.
>>> >  - General structure only to limit the scope because trying to
>>> >precisely place every protocol/feature is likely to be fragile in =
the
>>> >face of future changes.
>>> >
>>> >Justifications for (D):
>>> >  - To suggest and encourage other SDOs to use the same structure, =
but
>>> >cannot mandate what they do.
>>> >
>>> >Thanks,
>>> >Rob
>>> >
>>> >
>>> >On 18/09/2015 22:56, Kent Watsen wrote:
>>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7 =

>>> >>
>>> >>
>>> >>    Jonathan> Why does 7(A) limit the scope to IETF-defined =
modules of
>>> >>              others are now defining YANG modules?
>>> >>
>>> >>    Benoit> Good point. We need to provide guidance for the other =
SDOs.
>>> >>
>>> >>
>>> >> Current text says:
>>> >>
>>> >>     7.  Ability for distinct modules to leverage a common
>>> >>model-structure
>>> >>         A.  Scope is limited to IETF-defined modules
>>> >>         B.  Multiple domain-specific trees are okay
>>> >>         C.  Multiple namespaces are okay
>>> >>
>>> >>
>>> >>
>>> >> Background:
>>> >>
>>> >>    I pulled 7A from Andy's message here:
>>> >>
>>> >>
>>> >> =
https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U =
=

>>> >>
>>> >>    and put a stake in the ground so that, if nothing else, it =
could
>>> >>    be discussed...and here we are!
>>> >>
>>> >>    FWIW, I wrote 7A this way because I didn't see how it can be
>>> >>    enforced outside of the IETF.  But maybe that doesn't matter?
>>> >>    Of course, we can have 6087bis guidance for other SDOs, but
>>> >>    I didn't put that in the text.
>>> >>
>>> >>
>>> >> Thoughts on how the text should be updated?
>>> >>
>>> >>
>>> >> PS: Please Reply-All to the list rather than post comments to the =
GitHub
>>> >> issue tracker.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Kent
>>> >>
>>> >> _______________________________________________
>>> >> netmod mailing list
>>> >> netmod@ietf.org 
>>> >> https://www.ietf.org/mailman/listinfo/netmod =

>>> >>
>>> >
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod =

>>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

>=20
>=20


--Apple-Mail=_3796B18C-DF78-4B5F-9B52-9A9393927C0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Sep 22, 2015, at 2:46 PM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Tue, Sep 22, 2015 at 11:39 AM, =
Dean Bogdanovic <ivandean@gmail.com> wrote:
Andy,

Mobile operators are sharing =
infrastructure more and more. They are even now considering sharing =
spectrum. Today there are already use cases where Radio Access Network =
(RAN) is shared between multiple operators and they are interested in =
sharing core resources as well. I can see multiple NETCONF servers =
running on Mobile Switching Center (MSC), server per each virtual =
instance for tenant.


That's all fine but it does not alter =
my opinion at all that platforms that
do not need =
this feature should not be impacted by it.  If that means =
that
YANG will "fork" into a solution for big =
routers and a different solution
for not-a-routers, =
then that's fine.  The market can decide better than the IETF =
anyway.

To certain extent agree with your comment. But when you =
are talking about forking YANG for different domains, shouldn=E2=80=99t =
we try to have features in YANG and then implementers can decide which =
features they want to use? And then market can decide, which =
implementations they like the best?

Dean



Dean

Andy
 

On Sep 22, 2015, at 9:38 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, =
Sep 22, 2015 at 3:00 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you clarify. Is your concern specifically with
    requirement 7?  Or the full set of requirements in
    draft-chairs-netmod-opstate-reqs-00?

    


My =
concern is the impact on implementations that do not contain virtual =
servers
or do not even contain routers. If the =
scope of a solution is only routers, then
it does =
not matter how router-centric the solution.  But if the scope is =
every
device that uses YANG, then it does =
matter.

To be =
quite specific:
   - most devices do not =
require long time intervals  to apply configuration so any =
solution
     to identify intended =
vs. applied config is a waste of resources

  - most devices do not contain =
virtual servers so placing the data models in a framework
    for virtualization is a waste of =
resources

A =
good engineering solution would only use engineering resources, device =
resources,
and/or network resources on platforms =
that actually have these problems.
It's the =
 difference between MAY leverage a common model-structure and MUST =
leverage
a common model-structure. (Something =
IETFers should understand).

If the solution really is MAY, then I have no concerns, but =
I know YANG does
not actually support that, and it =
probably never will.  Relocatable YANG would
be =
rather complicated, so that is not an option at this time.



    Thanks,

    Rob


Andy
 

    

    

    
On 21/09/2015 20:28, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I do not think the issue of scope is being =
considered very
          carefully.

        


        

        
IMO the solutions being proposed are extremely
          router-centric.

        
(e.g., most NETCONF servers DO NOT have any =
virtual servers
          within them).

        


        

        
The larger the scope, the more concern I have =
that

        
the IETF will be pushing expensive solutions on =
platforms

        
that don't have any of the "problems" in the =
first place.

        


        

        


        

        
Andy

        


        

        


        

      

      


        
On Mon, Sep 21, 2015 at 12:09 PM, =
Kent
          Watsen <kwatsen@juniper.net>
          wrote:

          


            Thanks Robert, but I think I like Benoit's edit more.  =
Are
            you OK with it

            as well?

            

            PS: I've moved this issue to the VERIFY state.

            

            Thanks,

            Kent

            

            

            

            

            On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com>
            wrote:

            

            >Hi,

            >

            >I suggest changing the wording for A and adding D:

            >

            >    7.  Ability for distinct modules to =
leverage a
            common model-structure

            >        A.  Scope is limited to =
providing a general
            model-structure only

            >        B.  Multiple =
domain-specific trees are okay

            >        C.  Multiple namespaces =
are okay

            >        D.  The model-structure =
may be used or extended
            by other

            >organizations.

            >

            >Justifications for (A):

            >  - Limiting the scope to IETF-defined modules =
almost
            implies that

            >'ietf' would end up in the path (which would be
            wrong/unnecessary).

            >  - Clients don't care which SDO defines the =
modules for
            the protocols

            >they use, they just want a coherent organization of
            modules.

            >  - General structure only to limit the scope =
because
            trying to

            >precisely place every protocol/feature is likely to be
            fragile in the

            >face of future changes.

            >

            >Justifications for (D):

            >  - To suggest and encourage other SDOs to use the =
same
            structure, but

            >cannot mandate what they do.

            >

            >Thanks,

            >Rob

            >

            >

            >On 18/09/2015 22:56, Kent Watsen wrote:

            >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7

            >>

            >>

            >>    Jonathan> Why does 7(A) limit the =
scope to
            IETF-defined modules of

            >>              =
others are now defining YANG modules?

            >>

            >>    Benoit> Good point. We need to =
provide
            guidance for the other SDOs.

            >>

            >>

            >> Current text says:

            >>

            >>     7.  Ability for distinct =
modules to leverage a
            common

            >>model-structure

            >>         A.  Scope is =
limited to IETF-defined
            modules

            >>         B.  Multiple =
domain-specific trees are okay

            >>         C.  Multiple =
namespaces are okay

            >>

            >>

            >>

            >> Background:

            >>

            >>    I pulled 7A from Andy's message =
here:

            >>

            >>

            >> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZH=
i0CKLD46U

            >>

            >>    and put a stake in the ground so that, =
if
            nothing else, it could

            >>    be discussed...and here we are!

            >>

            >>    FWIW, I wrote 7A this way because I =
didn't see
            how it can be

            >>    enforced outside of the IETF.  =
But maybe that
            doesn't matter?

            >>    Of course, we can have 6087bis =
guidance for
            other SDOs, but

            >>    I didn't put that in the text.

            >>

            >>

            >> Thoughts on how the text should be updated?

            >>

            >>

            >> PS: Please Reply-All to the list rather than post
            comments to the GitHub

            >> issue tracker.

            >>

            >>

            >> Thanks,

            >> Kent

            >>

            >> _______________________________________________

            >> netmod mailing list

            >> netmod@ietf.org

            >> https://www.ietf.org/mailman/listinfo/netmod
=

            >>

            >

            

            _______________________________________________
=

            netmod mailing list

            netmod@ietf.org

            https://www.ietf.org/mailman/listinfo/netmod
=

          

        

        

      

    

    

  





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





=

--Apple-Mail=_3796B18C-DF78-4B5F-9B52-9A9393927C0C--


From nobody Tue Sep 22 12:40:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1DB1B2C83 for ; Tue, 22 Sep 2015 12:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAby-DhF-F0q for ; Tue, 22 Sep 2015 12:40:24 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 BC8141A92F7 for ; Tue, 22 Sep 2015 12:40:23 -0700 (PDT)
Received: by lahg1 with SMTP id g1so26111466lah.1 for ; Tue, 22 Sep 2015 12:40:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Uad6koPXtdlw+x2WNYwaw5ZAy2Lmzc5B07KwPe9/Yx8=; b=DMRoqEUMjDDfwe6KHr/rDie+kXQXC0LWoceHlWRvuL1Yo1r0RzKF0qwhOL1UEgjfal lO3lrBFJjfQYRmtfcWFLm3aKtcQH1lONJWiYAzDnIcDIJHSVhomLX8eTICfW3+Em5wna rDFTkizgBCoqLQ1CFTfoSVVzJ7NKfa/U8lRAL0MGtx19TxUPcxNPuHdMcjHuiYNW8HGO NIkPKGeiwfbErtfiLmY7IFJaf+RsUDFLkWYIRaW+iuLNZJfnTkt9fiQ1Fd/SyY3SPrR0 kM9Q28stk9j/UqJoSIjxHOPrBM7DNKApKGcKZy1VRGgS78y+F1rZLo5mZoOhswPtG5Hk A/EQ==
X-Gm-Message-State: ALoCoQn3tyeZJiGq4GijW3dZzNCAsu2+g+9VHUU7y6+pFXv2uPdaGcfwwMrnFW+1Vmju7EckLyOA
MIME-Version: 1.0
X-Received: by 10.112.156.167 with SMTP id wf7mr10333682lbb.88.1442950821423;  Tue, 22 Sep 2015 12:40:21 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Tue, 22 Sep 2015 12:40:21 -0700 (PDT)
In-Reply-To: <4E27FAA2-977C-4306-9776-5A5CD4EB01E7@gmail.com>
References:  <55FFCF2F.5010902@cisco.com>   <560126A7.6060307@cisco.com>  <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com>  <4E27FAA2-977C-4306-9776-5A5CD4EB01E7@gmail.com>
Date: Tue, 22 Sep 2015 12:40:21 -0700
Message-ID: 
From: Andy Bierman 
To: Dean Bogdanovic 
Content-Type: multipart/alternative; boundary=001a11c27b2623c64e05205b2b6a
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Sep 2015 19:40:27 -0000

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

On Tue, Sep 22, 2015 at 11:53 AM, Dean Bogdanovic 
wrote:

>
> On Sep 22, 2015, at 2:46 PM, Andy Bierman  wrote:
>
>
>
> On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic 
> wrote:
>
>> Andy,
>>
>> Mobile operators are sharing infrastructure more and more. They are even
>> now considering sharing spectrum. Today there are already use cases wher=
e
>> Radio Access Network (RAN) is shared between multiple operators and they
>> are interested in sharing core resources as well. I can see multiple
>> NETCONF servers running on Mobile Switching Center (MSC), server per eac=
h
>> virtual instance for tenant.
>>
>>
> That's all fine but it does not alter my opinion at all that platforms th=
at
> do not need this feature should not be impacted by it.  If that means tha=
t
> YANG will "fork" into a solution for big routers and a different solution
> for not-a-routers, then that's fine.  The market can decide better than
> the IETF anyway.
>
>
> To certain extent agree with your comment. But when you are talking about
> forking YANG for different domains, shouldn=E2=80=99t we try to have feat=
ures in
> YANG and then implementers can decide which features they want to use? An=
d
> then market can decide, which implementations they like the best?
>
>
OK - I guess we are in agreement.

There is nothing particularly difficult about extracting text from a YANG
module
and pasting it into a different YANG module.  In my experience, vendors
are not willing to spend unlimited resources to comply to a standard.
If the standard does not fit, they will use the parts that do fit and figur=
e
something else out for the rest.

E.g., if a YANG module is deemed too heavy-weight because it assumes
a set of use-cases that do not apply to a platform, it will be quite easy
to use a different YANG module.  Market forces will not sustain false
commonality.


Dean
>
>
Andy


>
>
> Dean
>>
>
> Andy
>
>
>>
>> On Sep 22, 2015, at 9:38 AM, Andy Bierman  wrote:
>>
>>
>>
>> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton  wrote=
:
>>
>>> Hi Andy,
>>>
>>> Please can you clarify. Is your concern specifically with requirement
>>> 7?  Or the full set of requirements in draft-chairs-netmod-opstate-reqs=
-00
>>> ?
>>>
>>>
>>
>> My concern is the impact on implementations that do not contain virtual
>> servers
>> or do not even contain routers. If the scope of a solution is only
>> routers, then
>> it does not matter how router-centric the solution.  But if the scope is
>> every
>> device that uses YANG, then it does matter.
>>
>> To be quite specific:
>>    - most devices do not require long time intervals  to apply
>> configuration so any solution
>>      to identify intended vs. applied config is a waste of resources
>>
>>   - most devices do not contain virtual servers so placing the data
>> models in a framework
>>     for virtualization is a waste of resources
>>
>> A good engineering solution would only use engineering resources, device
>> resources,
>> and/or network resources on platforms that actually have these problems.
>> It's the  difference between MAY leverage a common model-structure and
>> MUST leverage
>> a common model-structure. (Something IETFers should understand).
>>
>> If the solution really is MAY, then I have no concerns, but I know YANG
>> does
>> not actually support that, and it probably never will.  Relocatable YANG
>> would
>> be rather complicated, so that is not an option at this time.
>>
>>
>> Thanks,
>>> Rob
>>>
>>
>>
>> Andy
>>
>>
>>>
>>>
>>> On 21/09/2015 20:28, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I do not think the issue of scope is being considered very carefully.
>>>
>>> IMO the solutions being proposed are extremely router-centric.
>>> (e.g., most NETCONF servers DO NOT have any virtual servers within them=
).
>>>
>>> The larger the scope, the more concern I have that
>>> the IETF will be pushing expensive solutions on platforms
>>> that don't have any of the "problems" in the first place.
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen 
>>> wrote:
>>>
>>>>
>>>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with
>>>> it
>>>> as well?
>>>>
>>>> PS: I've moved this issue to the VERIFY state.
>>>>
>>>> Thanks,
>>>> Kent
>>>>
>>>>
>>>>
>>>>
>>>> On 9/21/15, 5:34 AM, "Robert Wilton" < 
>>>> rwilton@cisco.com> wrote:
>>>>
>>>> >Hi,
>>>> >
>>>> >I suggest changing the wording for A and adding D:
>>>> >
>>>> >    7.  Ability for distinct modules to leverage a common
>>>> model-structure
>>>> >        A.  Scope is limited to providing a general model-structure
>>>> only
>>>> >        B.  Multiple domain-specific trees are okay
>>>> >        C.  Multiple namespaces are okay
>>>> >        D.  The model-structure may be used or extended by other
>>>> >organizations.
>>>> >
>>>> >Justifications for (A):
>>>> >  - Limiting the scope to IETF-defined modules almost implies that
>>>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>>>> >  - Clients don't care which SDO defines the modules for the protocol=
s
>>>> >they use, they just want a coherent organization of modules.
>>>> >  - General structure only to limit the scope because trying to
>>>> >precisely place every protocol/feature is likely to be fragile in the
>>>> >face of future changes.
>>>> >
>>>> >Justifications for (D):
>>>> >  - To suggest and encourage other SDOs to use the same structure, bu=
t
>>>> >cannot mandate what they do.
>>>> >
>>>> >Thanks,
>>>> >Rob
>>>> >
>>>> >
>>>> >On 18/09/2015 22:56, Kent Watsen wrote:
>>>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>>>> >>
>>>> >>
>>>> >>    Jonathan> Why does 7(A) limit the scope to IETF-defined modules =
of
>>>> >>              others are now defining YANG modules?
>>>> >>
>>>> >>    Benoit> Good point. We need to provide guidance for the other
>>>> SDOs.
>>>> >>
>>>> >>
>>>> >> Current text says:
>>>> >>
>>>> >>     7.  Ability for distinct modules to leverage a common
>>>> >>model-structure
>>>> >>         A.  Scope is limited to IETF-defined modules
>>>> >>         B.  Multiple domain-specific trees are okay
>>>> >>         C.  Multiple namespaces are okay
>>>> >>
>>>> >>
>>>> >>
>>>> >> Background:
>>>> >>
>>>> >>    I pulled 7A from Andy's message here:
>>>> >>
>>>> >>
>>>> >>
>>>> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD4=
6U
>>>> >>
>>>> >>    and put a stake in the ground so that, if nothing else, it could
>>>> >>    be discussed...and here we are!
>>>> >>
>>>> >>    FWIW, I wrote 7A this way because I didn't see how it can be
>>>> >>    enforced outside of the IETF.  But maybe that doesn't matter?
>>>> >>    Of course, we can have 6087bis guidance for other SDOs, but
>>>> >>    I didn't put that in the text.
>>>> >>
>>>> >>
>>>> >> Thoughts on how the text should be updated?
>>>> >>
>>>> >>
>>>> >> PS: Please Reply-All to the list rather than post comments to the
>>>> GitHub
>>>> >> issue tracker.
>>>> >>
>>>> >>
>>>> >> Thanks,
>>>> >> Kent
>>>> >>
>>>> >> _______________________________________________
>>>> >> netmod mailing list
>>>> >> netmod@ietf.org
>>>> >> https://www.ietf.org/mailman/listinfo/netmod
>>>> >>
>>>> >
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>
>

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




On Tue, Sep 22, 2015 at 11:53 AM, Dean Bogdanovic <=
;ivandean@gmail.com=
> wrote:

On Sep 22, 2015, =
at 2:46 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Sep=
 22, 2015 at 11:39 AM, Dean Bogdanovic <ivandean@gmail.com>=
 wrote:
Andy,

Mobile operators are sharing infrastructure mor=
e and more. They are even now considering sharing spectrum. Today there are=
 already use cases where Radio Access Network (RAN) is shared between multi=
ple operators and they are interested in sharing core resources as well. I =
can see multiple NETCONF servers running on Mobile Switching Center (MSC), =
server per each virtual instance for tenant.


That's all fine but it does not alter my o=
pinion at all that platforms that
do not need this feature should=
 not be impacted by it.=C2=A0 If that means that
YANG will "=
fork" into a solution for big routers and a different solution
for not-a-routers, then that's fine.=C2=A0 The market can decide bet=
ter than the IETF anyway.
To certain extent agree with your comment. But when you are talking=
 about forking YANG for different domains, shouldn=E2=80=99t we try to have=
 features in YANG and then implementers can decide which features they want=
 to use? And then market can decide, which implementations they like the be=
st?


OK - I guess=
 we are in agreement.

There is nothing particularl=
y difficult about extracting text from a YANG module
and pasting =
it into a different YANG module.=C2=A0 In my experience, vendors
=
are not willing to spend unlimited resources to comply to a standard.
=

If the standard does not fit, they will use the parts that do fit and =
figure
something else out for the rest.

=
E.g., if a YANG module is deemed too heavy-weight because it assumes
<=
div>a set of use-cases that do not apply to a platform, it will be quite ea=
sy
to use a different YANG module.=C2=A0 Market forces will not s=
ustain false commonality.


Dean


Andy
=
=C2=A0


D=
ean

Andy
=C2=A0
=

On Sep 22, 2015, at 9:38 AM, Andy Bier=
man <andy@yumawo=
rks.com> wrote:



On Tue, Sep 22, 2015 at 3:00 AM, R=
obert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you clarify. Is your concern specifically with
    requirement 7?=C2=A0 Or the full set of requirements in
    draft-chairs-netmod-opstate-reqs-00<=
/span>?

    


My concern is=
 the impact on implementations that do not contain virtual servers
or do not even contain routers. If the scope of a solution is only router=
s, then
it does not matter how router-centric the solution.=C2=A0=
 But if the scope is every
device that uses YANG, then it does ma=
tter.

To be quite specific:
=C2=A0 =C2=
=A0- most devices do not require long time intervals =C2=A0to apply configu=
ration so any solution
=C2=A0 =C2=A0 =C2=A0to identify intended v=
s. applied config is a waste of resources

=C2=A0 -=
 most devices do not contain virtual servers so placing the data models in =
a framework
=C2=A0 =C2=A0 for virtualization is a waste of resour=
ces

A good engineering solution would only use eng=
ineering resources, device resources,
and/or network resources on=
 platforms that actually have these problems.
It's the =C2=A0=
difference between MAY leverage a common model-structure and MUST leverage<=
/div>
a common model-structure. (Something IETFers should understand).<=
/div>

If the solution really is MAY, then I have no conc=
erns, but I know YANG does
not actually support that, and it prob=
ably never will.=C2=A0 Relocatable YANG would
be rather complicat=
ed, so that is not an option at this time.



    Thanks,

    Rob


Andy
=

=C2=A0

    

    

    
On 21/09/2015 20:28, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I do not think the issue of scope is being considered very
          carefully.

        


        

        
IMO the solutions being proposed are extremely
          router-centric.

        
(e.g., most NETCONF servers DO NOT have any virtual servers
          within them).

        


        

        
The larger the scope, the more concern I have that

        
the IETF will be pushing expensive solutions on platforms
        
that don't have any of the "problems" in the fir=
st place.

        


        

        


        

        
Andy

        


        

        


        

      

      


        
On Mon, Sep 21, 2015 at 12:09 PM, Kent
          Watsen <kwatsen@juniper.net>
          wrote:

          


            Thanks Robert, but I think I like Benoit's edit more.=C2=A0=
 Are
            you OK with it

            as well?

            

            PS: I've moved this issue to the VERIFY state.

            

            Thanks,

            Kent

            

            

            

            

            On 9/21/15, 5:34 AM, "Robert Wilton" <rwilton@cisco.com>
            wrote:

            

            >Hi,

            >

            >I suggest changing the wording for A and adding D:

            >

            >=C2=A0 =C2=A0 7.=C2=A0 Ability for distinct modules to leve=
rage a
            common model-structure

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 A.=C2=A0 Scope is limited to pr=
oviding a general
            model-structure only

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 B.=C2=A0 Multiple domain-specif=
ic trees are okay

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 C.=C2=A0 Multiple namespaces ar=
e okay

            >=C2=A0 =C2=A0 =C2=A0 =C2=A0 D.=C2=A0 The model-structure ma=
y be used or extended
            by other

            >organizations.

            >

            >Justifications for (A):

            >=C2=A0 - Limiting the scope to IETF-defined modules almost
            implies that

            >'ietf' would end up in the path (which would be
            wrong/unnecessary).

            >=C2=A0 - Clients don't care which SDO defines the modul=
es for
            the protocols

            >they use, they just want a coherent organization of
            modules.

            >=C2=A0 - General structure only to limit the scope because
            trying to

            >precisely place every protocol/feature is likely to be
            fragile in the

            >face of future changes.

            >

            >Justifications for (D):

            >=C2=A0 - To suggest and encourage other SDOs to use the sam=
e
            structure, but

            >cannot mandate what they do.

            >

            >Thanks,

            >Rob

            >

            >

            >On 18/09/2015 22:56, Kent Watsen wrote:

            >> Regarding https://github.com/=
netmod-wg/opstate-reqs/issues/7

            >>

            >>

            >>=C2=A0 =C2=A0 Jonathan> Why does 7(A) limit the scop=
e to
            IETF-defined modules of

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 others=
 are now defining YANG modules?

            >>

            >>=C2=A0 =C2=A0 Benoit> Good point. We need to provide
            guidance for the other SDOs.

            >>

            >>

            >> Current text says:

            >>

            >>=C2=A0 =C2=A0 =C2=A07.=C2=A0 Ability for distinct modul=
es to leverage a
            common

            >>model-structure

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A.=C2=A0 Scope is lim=
ited to IETF-defined
            modules

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.=C2=A0 Multiple dom=
ain-specific trees are okay

            >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C.=C2=A0 Multiple nam=
espaces are okay

            >>

            >>

            >>

            >> Background:

            >>

            >>=C2=A0 =C2=A0 I pulled 7A from Andy's message here:=


            >>

            >>

            >> https:/=
/mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

            >>

            >>=C2=A0 =C2=A0 and put a stake in the ground so that, if
            nothing else, it could

            >>=C2=A0 =C2=A0 be discussed...and here we are!

            >>

            >>=C2=A0 =C2=A0 FWIW, I wrote 7A this way because I didn&=
#39;t see
            how it can be

            >>=C2=A0 =C2=A0 enforced outside of the IETF.=C2=A0 But m=
aybe that
            doesn't matter?

            >>=C2=A0 =C2=A0 Of course, we can have 6087bis guidance f=
or
            other SDOs, but

            >>=C2=A0 =C2=A0 I didn't put that in the text.

            >>

            >>

            >> Thoughts on how the text should be updated?

            >>

            >>

            >> PS: Please Reply-All to the list rather than post
            comments to the GitHub

            >> issue tracker.

            >>

            >>

            >> Thanks,

            >> Kent

            >>

            >> _______________________________________________

            >> netmod mailing list

            >> n=
etmod@ietf.org

            >> https://www.ietf.org/mailman/listin=
fo/netmod

            >>

            >

            

            _______________________________________________

            netmod mailing list

            netmod@iet=
f.org

            https://www.ietf.org/mailman/listinfo/netmod=


          

        

        

      

    

    

  





_______________________________________________
netmod mailing list
<=
a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
=
=
https://www.ietf.org/mailman/listinfo/netmod








--001a11c27b2623c64e05205b2b6a--


From nobody Wed Sep 23 00:13:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF19F1A6F53; Wed, 23 Sep 2015 00:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7xDxApdYGpt; Wed, 23 Sep 2015 00:13:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A02021A6F3C; Wed, 23 Sep 2015 00:13:22 -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.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150923071322.14368.36275.idtracker@ietfa.amsl.com>
Date: Wed, 23 Sep 2015 00:13:22 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 07:13:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : The YANG 1.1 Data Modeling Language
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
	Pages           : 196
	Date            : 2015-09-23

Abstract:
   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols like the Network Configuration Protocol
   (NETCONF).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07


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 Wed Sep 23 00:16:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7006D1A6F81 for ; Wed, 23 Sep 2015 00:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP7slba73LMr for ; Wed, 23 Sep 2015 00:16:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BB1F81A6F71 for ; Wed, 23 Sep 2015 00:16:54 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 7091B1AE0454 for ; Wed, 23 Sep 2015 09:16:53 +0200 (CEST)
Date: Wed, 23 Sep 2015 09:17:41 +0200 (CEST)
Message-Id: <20150923.091741.2069354372691581083.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20150923071322.14368.36275.idtracker@ietfa.amsl.com>
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.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: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 07:16:56 -0000

Hi,

This version addresses the last open issue Y60, and contains fixes for
hopefully all WG comments so far.  I believe that this version is
ready for WGLC.


/martin

internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
> 
>         Title           : The YANG 1.1 Data Modeling Language
>         Author          : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
> 	Pages           : 196
> 	Date            : 2015-09-23
> 
> Abstract:
>    YANG is a data modeling language used to model configuration data,
>    state data, remote procedure calls, and notifications for network
>    management protocols like the Network Configuration Protocol
>    (NETCONF).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07
> 
> 
> 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/
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Sep 23 00:24:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A061A6FAA for ; Wed, 23 Sep 2015 00:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxq-oM9IIq3P for ; Wed, 23 Sep 2015 00:24:37 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07941A6F87 for ; Wed, 23 Sep 2015 00:24:36 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:b8b2:5c4a:fc72:52b1] (unknown [IPv6:2001:718:1a02:1:b8b2:5c4a:fc72:52b1]) by mail.nic.cz (Postfix) with ESMTPSA id 50253180AA4; Wed, 23 Sep 2015 09:24:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1442993075; bh=3oQz39WsErGqsat0NHh12z1Jq59dWbtjJOz81KVy1Kc=; h=From:Date:To; b=oNHBa4DGNVYzDP60ajmznCxbUtXfAbxw57K2VVu+fFoZbN6iCBmbgXOEfZQgF4YPq 0aTOcbWzA3+8kuMAfikwf3iVxTpVY5FTFAnCODNAgMLwigpW6AZVk7YsEeDL3c3QnV Bnyrc1cg2yDj56Wie/HKa2jQ5vUi+YUq2N8GUMsQ=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 23 Sep 2015 09:24:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DAEFCCA-6BA7-4BD9-B0B8-1867949209CF@nic.cz>
References: 
To: Kent Watsen 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 07:24:38 -0000

Hi,

> On 21 Sep 2015, at 22:17, Kent Watsen  wrote:
>=20
>=20
> This is a notice to start a NETMOD WG last call for the document "JSON
> Encoding of Data Modeled with YANG":
>=20
> 	https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05
>=20
> Please indicate your support by Monday October 5, 2015 at 9PM EDT.
> We are not only interested in receiving defect reports, we are equally
> interested in statements of the form:
>=20
>  "I have reviewed I-D XYZ and I found no issues"
>  "I have implemented the data model in I-D XYZ"
>  "I am implementing the data model in I-D XYZ"
>  "I am considering to implement the data model in I-D XYZ=E2=80=9D

I believe the last three item should be about implementing the encoding =
rather than =E2=80=9Cthe data model=E2=80=9D.

FWIW, in pyang I implemented schema-driven 1-1 conversions between XML =
and JSON encodings, and vice versa.

Thanks, Lada

>=20
> This is the second Last Call for this document.
>=20
> Thanks,
> Kent
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 23 01:15:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234061A9038 for ; Wed, 23 Sep 2015 01:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f702BRiiDBW for ; Wed, 23 Sep 2015 01:14:58 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 11FAD1A9027 for ; Wed, 23 Sep 2015 01:14:58 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8CCF71CC0116; Wed, 23 Sep 2015 10:15:03 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
In-Reply-To: <20150921203439.GB96806@elstar.local>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 23 Sep 2015 10:14:52 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 08:15:01 -0000

Juergen Schoenwaelder  writes:

> On Wed, Sep 16, 2015 at 08:29:16PM +0200, Ladislav Lhotka wrote:
>> 
>> > On 16 Sep 2015, at 18:00, Andy Bierman  wrote:
>> > 
>> > 
>> > 
>> > On Wed, Sep 16, 2015 at 8:17 AM, Juergen Schoenwaelder  wrote:
>> > On Tue, Sep 15, 2015 at 12:21:44PM -0700, Andy Bierman wrote:
>> > > On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
>> > > randy_presuhn@mindspring.com> wrote:
>> > >
>> > > > Hi -
>> > > >
>> > > > >From: Juergen Schoenwaelder 
>> > > > >Sent: Sep 14, 2015 11:41 PM
>> > > > >To: Ladislav Lhotka 
>> > > > >Cc: NETMOD Working Group 
>> > > > >Subject: Re: [netmod] Fwd: New Version Notification for
>> > > > draft-ietf-netmod-yang-json-05.txt
>> > > > ...
>> > > > >My question is why the text is silent about the case where the data
>> > > > >model is present. Should it not say that if the data model is present,
>> > > > >the data encoded inside the anydata node must follow the rules of this
>> > > > >document? Perhaps this is the implicit assumption but I think it will
>> > > > >be useful to say this explicitly (if we agree on this).
>> > > > >
>> > > > >If the data model is not present, then I think an implementation is
>> > > > >still expected to produce an encoding that follows the rules of this
>> > > > >document as much as possible except that things that requires data
>> > > > >model knowledge may be encoded differently (e.g., numbers appearing as
>> > > > >strings or namespace names being different). I am thinking along the
>> > > > >lines of this proposed new text:
>> > > > >
>> > > > >   An anydata data node can contain an unknown set of nodes that can
>> > > > >   be modelled by YANG. A data model for anydata content may or may
>> > > > >   not exist at run time.  If the data model for anydata content is
>> > > > >   available, then the anydata content MUST be encoded according to
>> > > > >   the rules of this specification. If the data model for anydata
>> > > > >   content is not available, the encoding MUST follow the rules of
>> > > > >   this specification except for rules that require data model
>> > > > >   knowledge (and as a consequence, numbers may appear as strings or
>> > > > >   namespace qualifiers may not match module names).
>> > > >
>> > > > This leaves me wondering what it means for the data model for
>> > > > anydata content to be "available".  In the case of ASN.1's
>> > > > "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
>> > > > unambiguously identify the grammar (and associated semantics)
>> > > > to be used to understand the content, so tools can, if needed,
>> > > > scurry off to obtain the parsing instructions for those
>> > > > particular bits.  How does an implementation know in the case
>> > > > of "anydata" which datamodel to use?
>> > > >
>> > > >
>> > > Good questions....
>> > > The text "If the data model for anydata content is available" gives a hint
>> > > of just
>> > > what a hack anydata is in YANG.  The definition of anydata is that there is
>> > > no data model for the specified subtree.  The mere mention of an out-of-band
>> > > data mode is inappropriate and confusing.
>> > >
>> > > I understand this is intended to support usage like in YANG Patch, where the
>> > > description-stmt of 'value' says that the child node must follow the schema
>> > > for the node in the target leaf.  More hacks to get YANG to work.
>> > 
>> > You are welcome to provide fixes.
>> > 
>> > 
>> > OLD:
>> > 
>> > 
>> >   An anydata data node can contain an unknown set of nodes that can
>> >   be modelled by YANG. A data model for anydata content may or may
>> >    not exist at run time.  If the data model for anydata content is
>> >    available, then the anydata content MUST be encoded according to
>> >   the rules of this specification. If the data model for anydata
>> >   content is not available, the encoding MUST follow the rules of
>> >   this specification except for rules that require data model
>> >    knowledge (and as a consequence, numbers may appear as strings or
>> >   namespace qualifiers may not match module names).
>> > 
>> > 
>> > NEW:
>> > 
>> >   An anydata data node can contain an unknown set of nodes that can
>> >   be modelled by YANG.
>> 
>> This text is essentially in 6020bis, I see no need to repeat it. 
>> 
>> >  
>> > 
>> >  The YANG RFC itself should be silent about data-model specific
>> > semantics that are added to an anydata subtree.  The text "if available"
>> > is especially non-enforceable and therefore pointless.
>> > 
>> 
>> I must admit I am getting lost in these discussions. It seems to me there is a lot of hand-waving and hidden assumptions that moreover differ from one person to another. As I already said in Prague, both anyxml and anydata are IMO constructs of marginal utility and it is frustrating we spend so much effort on them.
>>
>
> I agree that anyxml is of marginal utility, anydata however is needed
> for any rpc/action/notification or future language construct that can
> work with generic YANG content and hence I think its behaviour and
> encoding should be well defined.

But then I believe we should have stricter rules for anydata than just
"an unknown set of nodes that can be modelled with YANG" - it should be
stated that the data model for an anydata instance MUST be known at
run-time. Otherwise I think anyxml can cover all use cases you mention
as well (as it has done in the past), and there is no need to introduce
a new data node type with a definition that allows for multiple
interpretations.

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Sep 23 02:45:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC051AC430 for ; Wed, 23 Sep 2015 02:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level: 
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VERx6dUoXAR1 for ; Wed, 23 Sep 2015 02:45:27 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 284161AC428 for ; Wed, 23 Sep 2015 02:45:26 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 81175C4175C5 for ; Wed, 23 Sep 2015 11:45:23 +0200 (CEST)
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com>
Cc: netmod@ietf.org
From: Jernej Tuljak 
Message-ID: <560274AF.3060705@mg-soft.si>
Date: Wed, 23 Sep 2015 11:45:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150923071322.14368.36275.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 09:45:29 -0000

Section 7.21.5., the first bullet describing the augmentation case does 
not consider that an "augment" may specify a top-level "choice" or a 
"choice"/"case" nested within a top-level "choice" as the target node. 
There will be no initial context node for the expression in such a case.

   leaf enable-foos {
     type boolean;
   }
   choice ch1 {
     case foo {
       choice foos {
         when "enable-foos = 'true'";
         leaf foo1 {
           type string;
         }
         leaf foo2 {
           type string;
         }
       }
     }
     container meh;
   }

   augment "/ch1/foo/foos" {
     when "enable-foos = 'true'";
     leaf foo3 {
       type string;
     }
   }

OLD:

    o  If the "when" statement is a child of an "augment" statement, then
       the context node is the augment's target node in the data tree, if
       the target node is a data node.  Otherwise, the context node is
       the closest ancestor node to the target node that is also a data
       node.

NEW:

    o  If the "when" statement is a child of an "augment" statement, then
       the context node is the augment's target node in the data tree, if
       the target node is a data node.  Otherwise, the context node is
       the closest ancestor node to the target node that is also a data
       node. If no such node exists, the context node is the root node.

Jernej

internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>
>          Title           : The YANG 1.1 Data Modeling Language
>          Author          : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
> 	Pages           : 196
> 	Date            : 2015-09-23
>
> Abstract:
>     YANG is a data modeling language used to model configuration data,
>     state data, remote procedure calls, and notifications for network
>     management protocols like the Network Configuration Protocol
>     (NETCONF).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07
>
>
> 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/
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Sep 23 02:59:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE041A0155 for ; Wed, 23 Sep 2015 02:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3X4YATmXGVn for ; Wed, 23 Sep 2015 02:59:03 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262011A0151 for ; Wed, 23 Sep 2015 02:59:03 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id A587B181138; Wed, 23 Sep 2015 11:59:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443002341; bh=eRb+ASykH8maE8mJbOPSM0TZDFU5ZeaYQkOwwdtjf8k=; h=From:Date:To; b=G1e57TPs4bt11JPOF4BvF1KuhF9+2u4Uz0Mz4wAtM7y+srMqUxLCftAlNbguUGpqN 88RM/nPMu+PPqECSv+PhLVqB1omkx9ass+Jkx37pBGiw04gH1T4UdSCPsODuvXHITh EhyUGZK+wYA68toLEaHCoBe9nSBp/mffLo9x13XM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <560274AF.3060705@mg-soft.si>
Date: Wed, 23 Sep 2015 11:58:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 09:59:06 -0000

> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>=20
> Section 7.21.5., the first bullet describing the augmentation case =
does not consider that an "augment" may specify a top-level "choice" or =
a "choice"/"case" nested within a top-level "choice" as the target node. =
There will be no initial context node for the expression in such a case.
>=20
>  leaf enable-foos {
>    type boolean;
>  }
>  choice ch1 {
>    case foo {
>      choice foos {
>        when "enable-foos =3D 'true'";
>        leaf foo1 {
>          type string;
>        }
>        leaf foo2 {
>          type string;
>        }
>      }
>    }
>    container meh;
>  }
>=20
>  augment "/ch1/foo/foos" {
>    when "enable-foos =3D 'true'";
>    leaf foo3 {
>      type string;
>    }
>  }
>=20
> OLD:
>=20
>   o  If the "when" statement is a child of an "augment" statement, =
then
>      the context node is the augment's target node in the data tree, =
if
>      the target node is a data node.  Otherwise, the context node is
>      the closest ancestor node to the target node that is also a data
>      node.
>=20
> NEW:
>=20
>   o  If the "when" statement is a child of an "augment" statement, =
then
>      the context node is the augment's target node in the data tree, =
if
>      the target node is a data node.  Otherwise, the context node is
>      the closest ancestor node to the target node that is also a data
>      node. If no such node exists, the context node is the root node.
>=20

Good catch, I support this change.

Also regarding sec. 7.21.5, I think we agreed that a when expression =
must not reference nodes that are made conditional through that when =
statement. I can=E2=80=99t find this rule in the text.

Lada=20

> Jernej
>=20
> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>  This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>>=20
>>         Title           : The YANG 1.1 Data Modeling Language
>>         Author          : Martin Bjorklund
>> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
>> 	Pages           : 196
>> 	Date            : 2015-09-23
>>=20
>> Abstract:
>>    YANG is a data modeling language used to model configuration data,
>>    state data, remote procedure calls, and notifications for network
>>    management protocols like the Network Configuration Protocol
>>    (NETCONF).
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-07
>>=20
>>=20
>> 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.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 23 03:22:09 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298FF1ACDF0 for ; Wed, 23 Sep 2015 03:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpagjei-2wmc for ; Wed, 23 Sep 2015 03:22:04 -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 4398C1ACD7E for ; Wed, 23 Sep 2015 03:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14934; q=dns/txt; s=iport; t=1443003691; x=1444213291; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=piM5RJapg4t6YYdUtmSu+UBek3ubgYnBe9Hgh+8jBno=; b=lwmTqRUpmC6WT+nxpfQw5LHCDO5QWVK0ql8yFKzNCE9qhQRA7XpLvIXH za3tGdTXdFIRbEKlpDh/rr8SVkPZft6nbCQwYACI4Tv8pNoJAqbtqj6Au TLX9j1ZA2yOqfkbqaf/v3VfKSH3+xEt1cSHJcukodt1GzoZmU8BbY6MR2 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BPBQBZfAJW/xbLJq1aA4JXgSFpv0oBCYJDgmxKAoIRAQEBAQEBgQuEJAEBAQMBAQEBawoGCQILEAgJFgQEBwkDAgECAQkMHxEGAQwGAgEBiCIIDcsUAQEBAQEBAQECAQEBAQEBAQEBARgEhm+EfYRCOxcShBoFlWeHO4VQgU+HNIlriDxjgkOBPz0ziCclgSEBAQE
X-IronPort-AV: E=Sophos;i="5.17,577,1437436800";  d="scan'208,217";a="605304557"
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; 23 Sep 2015 10:21:29 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8NALS1X031521; Wed, 23 Sep 2015 10:21:29 GMT
To: Andy Bierman , Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local> 
From: Robert Wilton 
Message-ID: <56027D26.8020801@cisco.com>
Date: Wed, 23 Sep 2015 11:21:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010607030307080906090600"
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 10:22:07 -0000

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



On 22/09/2015 19:04, Andy Bierman wrote:
>
>
> On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:
>     >
>     > NETCONF and RESTCONF are asynchronous, meaning the client and server
>     > run in separate processes and communication between client and
>     server can
>     > occur at any time.
>     >
>
>     I thought the openconfig discussion was centered around the server
>     side...
>
>     > If the server returns  to an edit request, that means it is
>     accepted in
>     > the intended config.
>
>     I think we need to use precise terminology otherwise we keep talking
>     past each other. An  to an  means the edit got
>     'accepted' (not sure what this term means) in the configuration
>     datastore being edited, such as  or .
>
>
>
> OK -- the edit is accepted as part of the  datastore.
> That means is passes the YANG validation tests.
> I guess our terminology is so poor that we cannot even describe that
> means wrt/ the device or the network.
>
>
>
>     Perhaps  === intended configuration datastore. But I think
>     it is important to not forget that there are multiple configuration
>     datastores in NETCONF.
>
>     My understanding is that the  operation is synchronous
>     with respect to the change of the configuration datastore. The
>     propagation of the data from the  configuration datastore to
>     the internal pieces of hardware and software being configured may be
>     asynchronous and is usually considered an implementation detail. The
>     protocol itself allows asynchronous clients to be written that can
>     talk to multiple servers and in principle the protocol supports
>     pipelining of requests from a single client to a single server but all
>     requests are executed serially. I think the same applies to RESTCONF
>     but I am a bit less confident.
>
>
>
> I agree with Carl that there is no problem to solve wrt/ "show running"
> being delayed.  I think implementations just return the intended values.

This doesn't seem to be consistent with the rfc6241 section 5.1 that states:
"The running configuration datastore holds the complete configuration 
currently active on the network device."

Also, section 4.2 of openconfig-netmod-opstate states:

    "In a synchronous system, configuration changes are transactional and
    committed as an atomic unit.  This implies that the management system
    knows the success or failure of the configuration change based on the
    return value, and hence knows that the intended configuration matches
    what is on the system (i..e, what has been applied).  In particular,
    the value of any configuration variable should always reflect the
    (intended) configured value.  Synchronous operation is generally
    associated with a NETCONF-based system that provides transactional
    semantics for all changes."


Taken together, to me, this implies that the definition of "applied 
configuration" is such that after a successful regular (i.e. 
"synchronous") NETCONF edit-config request then the values that the 
running datastore holds is both the intended configuration and applied 
configuration.  I.e. they are the same.

Of course, I agree that this doesn't guarantee that a particular item of 
configuration has been fully programmed everywhere on the system, but 
that is what the derived state indirectly tells gives you.

It is only "asynchronous" servers that return early from an edit-config 
request for which the intended config can ever differ from the applied 
config.  Further, assuming that there are no errors when applying the 
configuration, then at the point in time that a server would have 
logically completed a normal "synchronous" config request, the value of 
the "applied configuration" leaves would be identical to the "intended 
configuration" leaves.

Rob


>
>     /js
>
>
>
> Andy
>
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103         
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    

    

    
On 22/09/2015 19:04, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Sep 22, 2015 at 10:00 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Tue,
              Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:

              >

              > NETCONF and RESTCONF are asynchronous, meaning the
              client and server

              > run in separate processes and communication between
              client and server can

              > occur at any time.

              >

              

              I thought the openconfig discussion was centered around
              the server

              side...

              

              > If the server returns <ok/> to an edit request,
              that means it is accepted in

              > the intended config.

              

              I think we need to use precise terminology otherwise we
              keep talking

              past each other. An <ok/> to an <edit-config>
              means the edit got

              'accepted' (not sure what this term means) in the
              configuration

              datastore being edited, such as <running/> or
              <candidate/>.

              

            

            


            

            


            

            
OK -- the edit is accepted as part of the
              <running> datastore.

            
That means is passes the YANG validation tests.

          

        

      

    

    

      

        

          

            
I guess our terminology is so poor that we cannot even
              describe that

            
means wrt/ the device or the network.

          

        

      

    

    

      

        

          

            


            

            


            

            


            

            

            

              Perhaps <running/> === intended configuration
              datastore. But I think

              it is important to not forget that there are multiple
              configuration

              datastores in NETCONF.

              

              My understanding is that the <edit-config/>
              operation is synchronous

              with respect to the change of the configuration datastore.
              The

              propagation of the data from the <running/>
              configuration datastore to

              the internal pieces of hardware and software being
              configured may be

              asynchronous and is usually considered an implementation
              detail. The

              protocol itself allows asynchronous clients to be written
              that can

              talk to multiple servers and in principle the protocol
              supports

              pipelining of requests from a single client to a single
              server but all

              requests are executed serially. I think the same applies
              to RESTCONF

              but I am a bit less confident.

              

                

            


            

            


            

            
I agree with Carl that there is no problem to solve
              wrt/ "show running"

            
being delayed. I think implementations just return the
              intended values.

          

        

      

    

    

    This doesn't seem to be consistent with the rfc6241 section 5.1 that
    states:

    "The running configuration datastore holds the complete
    configuration currently active on the network device."

    

    Also, section 4.2 of openconfig-netmod-opstate states:

    
   "In a synchronous system, configuration changes are transactional and
   committed as an atomic unit.  This implies that the management system
   knows the success or failure of the configuration change based on the
   return value, and hence knows that the intended configuration matches
   what is on the system (i..e, what has been applied).  In particular,
   the value of any configuration variable should always reflect the
   (intended) configured value.  Synchronous operation is generally
   associated with a NETCONF-based system that provides transactional
   semantics for all changes."

    

    Taken together, to me, this implies that the definition of "applied
    configuration" is such that after a successful regular (i.e.
    "synchronous") NETCONF edit-config request then the values that the
    running datastore holds is both the intended configuration and
    applied configuration. I.e. they are the same.

    

    Of course, I agree that this doesn't guarantee that a particular
    item of configuration has been fully programmed everywhere on the
    system, but that is what the derived state indirectly tells gives
    you.

    

    It is only "asynchronous" servers that return early from an
    edit-config request for which the intended config can ever differ
    from the applied config. Further, assuming that there are no errors
    when applying the configuration, then at the point in time that a
    server would have logically completed a normal "synchronous" config
    request, the value of the "applied configuration" leaves would be
    identical to the "intended configuration" leaves.

    

    Rob

    

    

    

      

        

          

            


            

            

                  /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/>

                

          

          

        

      

      

      

      

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


    

    

  


--------------010607030307080906090600--


From nobody Wed Sep 23 03:33:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F391ACE51 for ; Wed, 23 Sep 2015 03:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3gxRl0UmYio for ; Wed, 23 Sep 2015 03:33:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3028D1ACE54 for ; Wed, 23 Sep 2015 03:33:23 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id BB8021AE0454; Wed, 23 Sep 2015 12:33:21 +0200 (CEST)
Date: Wed, 23 Sep 2015 12:34:10 +0200 (CEST)
Message-Id: <20150923.123410.1059568972148566617.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <560274AF.3060705@mg-soft.si>
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si>
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: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 10:33:25 -0000

Jernej Tuljak  wrote:
> Section 7.21.5., the first bullet describing the augmentation case
> does not consider that an "augment" may specify a top-level "choice"
> or a "choice"/"case" nested within a top-level "choice" as the target
> node. There will be no initial context node for the expression in such
> a case.
> 
>   leaf enable-foos {
>     type boolean;
>   }
>   choice ch1 {
>     case foo {
>       choice foos {
>         when "enable-foos = 'true'";
>         leaf foo1 {
>           type string;
>         }
>         leaf foo2 {
>           type string;
>         }
>       }
>     }
>     container meh;
>   }
> 
>   augment "/ch1/foo/foos" {
>     when "enable-foos = 'true'";
>     leaf foo3 {
>       type string;
>     }
>   }
> 
> OLD:
> 
>    o  If the "when" statement is a child of an "augment" statement, then
>       the context node is the augment's target node in the data tree, if
>       the target node is a data node.  Otherwise, the context node is
>       the closest ancestor node to the target node that is also a data
>       node.
> 
> NEW:
> 
>    o  If the "when" statement is a child of an "augment" statement, then
>       the context node is the augment's target node in the data tree, if
>       the target node is a data node.  Otherwise, the context node is
>       the closest ancestor node to the target node that is also a data
>       node. If no such node exists, the context node is the root node.

Agreed.  I have updated the text with this change.  Thanks!


/martin




> 
> Jernej
> 
> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >   This draft is a work item of the NETCONF Data Modeling Language
> >   Working Group of the IETF.
> >
> >          Title           : The YANG 1.1 Data Modeling Language
> >          Author          : Martin Bjorklund
> > 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
> > 	Pages           : 196
> > 	Date            : 2015-09-23
> >
> > Abstract:
> >     YANG is a data modeling language used to model configuration data,
> >     state data, remote procedure calls, and notifications for network
> >     management protocols like the Network Configuration Protocol
> >     (NETCONF).
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07
> >
> >
> > 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/
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Sep 23 03:38:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4031ACE64 for ; Wed, 23 Sep 2015 03:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-TDoqfTHxOD for ; Wed, 23 Sep 2015 03:37:58 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4A6E1ACE5E for ; Wed, 23 Sep 2015 03:37:57 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 7EF30C4175C5; Wed, 23 Sep 2015 12:37:52 +0200 (CEST)
To: Ladislav Lhotka 
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si> 
From: Jernej Tuljak 
Message-ID: <560280FC.7080703@mg-soft.si>
Date: Wed, 23 Sep 2015 12:37:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 10:37:59 -0000

Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>
>> Section 7.21.5., the first bullet describing the augmentation case does not consider that an "augment" may specify a top-level "choice" or a "choice"/"case" nested within a top-level "choice" as the target node. There will be no initial context node for the expression in such a case.
>>
>>   leaf enable-foos {
>>     type boolean;
>>   }
>>   choice ch1 {
>>     case foo {
>>       choice foos {
>>         when "enable-foos = 'true'";
>>         leaf foo1 {
>>           type string;
>>         }
>>         leaf foo2 {
>>           type string;
>>         }
>>       }
>>     }
>>     container meh;
>>   }
>>
>>   augment "/ch1/foo/foos" {
>>     when "enable-foos = 'true'";
>>     leaf foo3 {
>>       type string;
>>     }
>>   }
>>
>> OLD:
>>
>>    o  If the "when" statement is a child of an "augment" statement, then
>>       the context node is the augment's target node in the data tree, if
>>       the target node is a data node.  Otherwise, the context node is
>>       the closest ancestor node to the target node that is also a data
>>       node.
>>
>> NEW:
>>
>>    o  If the "when" statement is a child of an "augment" statement, then
>>       the context node is the augment's target node in the data tree, if
>>       the target node is a data node.  Otherwise, the context node is
>>       the closest ancestor node to the target node that is also a data
>>       node. If no such node exists, the context node is the root node.
>>
> Good catch, I support this change.
>
> Also regarding sec. 7.21.5, I think we agreed that a when expression must not reference nodes that are made conditional through that when statement. I can’t find this rule in the text.

The "no referencing the initial context node and its descendants" text 
is currently in the guidelines draft only (6087bis).

Jernej

> Lada
>
>> Jernej
>>
>> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>   This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>>>
>>>          Title           : The YANG 1.1 Data Modeling Language
>>>          Author          : Martin Bjorklund
>>> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
>>> 	Pages           : 196
>>> 	Date            : 2015-09-23
>>>
>>> Abstract:
>>>     YANG is a data modeling language used to model configuration data,
>>>     state data, remote procedure calls, and notifications for network
>>>     management protocols like the Network Configuration Protocol
>>>     (NETCONF).
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07
>>>
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>


From nobody Wed Sep 23 03:52:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0F1ACE81 for ; Wed, 23 Sep 2015 03:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FE0UVbmVuoR for ; Wed, 23 Sep 2015 03:52:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFC91ACE7F for ; Wed, 23 Sep 2015 03:52:17 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 05D7F18180A; Wed, 23 Sep 2015 12:52:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443005536; bh=OMb2PMASuOX/UUOLp8jYa5V/3hM1Z0jYjY//Ag1iK4s=; h=From:Date:To; b=LOD7h8KMqFnh+jVftmaOcSkGeePZFsOMu4oJ86MyzlIOUIsDqY3Xiafrr+XdPp9PV ZbAyfgTvIFBTNal8l2Vcb3po8h1YgY6em5acnd8lltDWhLfweaaoW++h9JSVxAXByq 9lMZZ43vrBKxb8EEmPz8N1TbAColjjk1sh/0dAf8=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <560280FC.7080703@mg-soft.si>
Date: Wed, 23 Sep 2015 12:52:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz>
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si>  <560280FC.7080703@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 10:52:19 -0000

> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>=20
> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>=20
>>> Section 7.21.5., the first bullet describing the augmentation case =
does not consider that an "augment" may specify a top-level "choice" or =
a "choice"/"case" nested within a top-level "choice" as the target node. =
There will be no initial context node for the expression in such a case.
>>>=20
>>>  leaf enable-foos {
>>>    type boolean;
>>>  }
>>>  choice ch1 {
>>>    case foo {
>>>      choice foos {
>>>        when "enable-foos =3D 'true'";
>>>        leaf foo1 {
>>>          type string;
>>>        }
>>>        leaf foo2 {
>>>          type string;
>>>        }
>>>      }
>>>    }
>>>    container meh;
>>>  }
>>>=20
>>>  augment "/ch1/foo/foos" {
>>>    when "enable-foos =3D 'true'";
>>>    leaf foo3 {
>>>      type string;
>>>    }
>>>  }
>>>=20
>>> OLD:
>>>=20
>>>   o  If the "when" statement is a child of an "augment" statement, =
then
>>>      the context node is the augment's target node in the data tree, =
if
>>>      the target node is a data node.  Otherwise, the context node is
>>>      the closest ancestor node to the target node that is also a =
data
>>>      node.
>>>=20
>>> NEW:
>>>=20
>>>   o  If the "when" statement is a child of an "augment" statement, =
then
>>>      the context node is the augment's target node in the data tree, =
if
>>>      the target node is a data node.  Otherwise, the context node is
>>>      the closest ancestor node to the target node that is also a =
data
>>>      node. If no such node exists, the context node is the root =
node.
>>>=20
>> Good catch, I support this change.
>>=20
>> Also regarding sec. 7.21.5, I think we agreed that a when expression =
must not reference nodes that are made conditional through that when =
statement. I can=E2=80=99t find this rule in the text.
>=20
> The "no referencing the initial context node and its descendants" text =
is currently in the guidelines draft only (6087bis).

IMO this should be a hard rule in 6020bis. Such expressions are =
seriously broken and could lead to deadlocks.

Lada

>=20
> Jernej
>=20
>> Lada
>>=20
>>> Jernej
>>>=20
>>> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>>  This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>>>>=20
>>>>         Title           : The YANG 1.1 Data Modeling Language
>>>>         Author          : Martin Bjorklund
>>>> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
>>>> 	Pages           : 196
>>>> 	Date            : 2015-09-23
>>>>=20
>>>> Abstract:
>>>>    YANG is a data modeling language used to model configuration =
data,
>>>>    state data, remote procedure calls, and notifications for =
network
>>>>    management protocols like the Network Configuration Protocol
>>>>    (NETCONF).
>>>>=20
>>>>=20
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>>>=20
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>>>>=20
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-07
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 23 04:06:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F411ACE91 for ; Wed, 23 Sep 2015 04:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CL40Uadjk8Q for ; Wed, 23 Sep 2015 04:06:21 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5591ACE90 for ; Wed, 23 Sep 2015 04:06:21 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 50FE51AE0454; Wed, 23 Sep 2015 13:06:20 +0200 (CEST)
Date: Wed, 23 Sep 2015 13:07:09 +0200 (CEST)
Message-Id: <20150923.130709.926246931083333700.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz>
References:  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 11:06:23 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjMgU2Vw
IDIwMTUsIGF0IDEyOjM3LCBKZXJuZWogVHVsamFrIDxqZXJuZWp0QG1nLXNvZnQuc2k+IHdyb3Rl
Og0KPiA+IA0KPiA+IExhZGlzbGF2IExob3RrYSBqZSAyMy45LjIwMTUgb2IgMTE6NTggbmFwaXNh
bDoNCj4gPj4+IE9uIDIzIFNlcCAyMDE1LCBhdCAxMTo0NSwgSmVybmVqIFR1bGphayA8amVybmVq
dEBtZy1zb2Z0LnNpPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gU2VjdGlvbiA3LjIxLjUuLCB0aGUg
Zmlyc3QgYnVsbGV0IGRlc2NyaWJpbmcgdGhlIGF1Z21lbnRhdGlvbiBjYXNlDQo+ID4+PiBkb2Vz
IG5vdCBjb25zaWRlciB0aGF0IGFuICJhdWdtZW50IiBtYXkgc3BlY2lmeSBhIHRvcC1sZXZlbCAi
Y2hvaWNlIg0KPiA+Pj4gb3IgYSAiY2hvaWNlIi8iY2FzZSIgbmVzdGVkIHdpdGhpbiBhIHRvcC1s
ZXZlbCAiY2hvaWNlIiBhcyB0aGUgdGFyZ2V0DQo+ID4+PiBub2RlLiBUaGVyZSB3aWxsIGJlIG5v
IGluaXRpYWwgY29udGV4dCBub2RlIGZvciB0aGUgZXhwcmVzc2lvbiBpbiBzdWNoDQo+ID4+PiBh
IGNhc2UuDQo+ID4+PiANCj4gPj4+ICBsZWFmIGVuYWJsZS1mb29zIHsNCj4gPj4+ICAgIHR5cGUg
Ym9vbGVhbjsNCj4gPj4+ICB9DQo+ID4+PiAgY2hvaWNlIGNoMSB7DQo+ID4+PiAgICBjYXNlIGZv
byB7DQo+ID4+PiAgICAgIGNob2ljZSBmb29zIHsNCj4gPj4+ICAgICAgICB3aGVuICJlbmFibGUt
Zm9vcyA9ICd0cnVlJyI7DQo+ID4+PiAgICAgICAgbGVhZiBmb28xIHsNCj4gPj4+ICAgICAgICAg
IHR5cGUgc3RyaW5nOw0KPiA+Pj4gICAgICAgIH0NCj4gPj4+ICAgICAgICBsZWFmIGZvbzIgew0K
PiA+Pj4gICAgICAgICAgdHlwZSBzdHJpbmc7DQo+ID4+PiAgICAgICAgfQ0KPiA+Pj4gICAgICB9
DQo+ID4+PiAgICB9DQo+ID4+PiAgICBjb250YWluZXIgbWVoOw0KPiA+Pj4gIH0NCj4gPj4+IA0K
PiA+Pj4gIGF1Z21lbnQgIi9jaDEvZm9vL2Zvb3MiIHsNCj4gPj4+ICAgIHdoZW4gImVuYWJsZS1m
b29zID0gJ3RydWUnIjsNCj4gPj4+ICAgIGxlYWYgZm9vMyB7DQo+ID4+PiAgICAgIHR5cGUgc3Ry
aW5nOw0KPiA+Pj4gICAgfQ0KPiA+Pj4gIH0NCj4gPj4+IA0KPiA+Pj4gT0xEOg0KPiA+Pj4gDQo+
ID4+PiAgIG8gIElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21l
bnQiIHN0YXRlbWVudCwgdGhlbg0KPiA+Pj4gICAgICB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBh
dWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwgaWYNCj4gPj4+ICAgICAgdGhl
IHRhcmdldCBub2RlIGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0aGUgY29udGV4dCBub2Rl
IGlzDQo+ID4+PiAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBu
b2RlIHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gPj4+ICAgICAgbm9kZS4NCj4gPj4+IA0KPiA+Pj4g
TkVXOg0KPiA+Pj4gDQo+ID4+PiAgIG8gIElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hp
bGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVudCwgdGhlbg0KPiA+Pj4gICAgICB0aGUgY29udGV4
dCBub2RlIGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwgaWYN
Cj4gPj4+ICAgICAgdGhlIHRhcmdldCBub2RlIGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0
aGUgY29udGV4dCBub2RlIGlzDQo+ID4+PiAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUg
dG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gPj4+ICAgICAgbm9kZS4g
SWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgcm9vdCBub2Rl
Lg0KPiA+Pj4gDQo+ID4+IEdvb2QgY2F0Y2gsIEkgc3VwcG9ydCB0aGlzIGNoYW5nZS4NCj4gPj4g
DQo+ID4+IEFsc28gcmVnYXJkaW5nIHNlYy4gNy4yMS41LCBJIHRoaW5rIHdlIGFncmVlZCB0aGF0
IGEgd2hlbiBleHByZXNzaW9uDQo+ID4+IG11c3Qgbm90IHJlZmVyZW5jZSBub2RlcyB0aGF0IGFy
ZSBtYWRlIGNvbmRpdGlvbmFsIHRocm91Z2ggdGhhdCB3aGVuDQo+ID4+IHN0YXRlbWVudC4gSSBj
YW7igJl0IGZpbmQgdGhpcyBydWxlIGluIHRoZSB0ZXh0Lg0KPiA+IA0KPiA+IFRoZSAibm8gcmVm
ZXJlbmNpbmcgdGhlIGluaXRpYWwgY29udGV4dCBub2RlIGFuZCBpdHMgZGVzY2VuZGFudHMiIHRl
eHQNCj4gPiBpcyBjdXJyZW50bHkgaW4gdGhlIGd1aWRlbGluZXMgZHJhZnQgb25seSAoNjA4N2Jp
cykuDQo+IA0KPiBJTU8gdGhpcyBzaG91bGQgYmUgYSBoYXJkIHJ1bGUgaW4gNjAyMGJpcy4gU3Vj
aCBleHByZXNzaW9ucyBhcmUNCj4gc2VyaW91c2x5IGJyb2tlbiBhbmQgY291bGQgbGVhZCB0byBk
ZWFkbG9ja3MuDQoNClRoaXMgcmVtaW5kcyBtZSBvZiBKdWVyZ2VuJ3MgZ29sZGVuIHJ1bGU6ICJB
bGwgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMNCnNwZWMgTVVTVCBiZSBidWctZnJlZSIuICBXZSdk
IGhhdmUgdG8gc2F5ICJhbGwgWFBhdGggZXhwcmVzc2lvbnMgTVVTVA0KbWFrZSBzZW5zZSIuDQoN
ClJlZmVyZW5jaW5nIG5vZGVzIHRoYXQgZG9uJ3QgZXhpc3QgaXMgbGVnYWwgWFBhdGgsIGJ1dCBp
dCBwcm9iYWJseQ0KZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlLg0KDQoNCi9tYXJ0aW4NCg==


From nobody Wed Sep 23 04:15:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B279E1ACE92 for ; Wed, 23 Sep 2015 04:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR4lnOBzrmSK for ; Wed, 23 Sep 2015 04:15:50 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id A00031A1B8B for ; Wed, 23 Sep 2015 04:15:49 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 3E734C4175C5; Wed, 23 Sep 2015 13:07:02 +0200 (CEST)
To: Ladislav Lhotka 
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si>  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz>
From: Jernej Tuljak 
Message-ID: <560287D1.9050905@mg-soft.si>
Date: Wed, 23 Sep 2015 13:06:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 11:15:51 -0000

Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>
>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>
>>>> Section 7.21.5., the first bullet describing the augmentation case does not consider that an "augment" may specify a top-level "choice" or a "choice"/"case" nested within a top-level "choice" as the target node. There will be no initial context node for the expression in such a case.
>>>>
>>>>   leaf enable-foos {
>>>>     type boolean;
>>>>   }
>>>>   choice ch1 {
>>>>     case foo {
>>>>       choice foos {
>>>>         when "enable-foos = 'true'";
>>>>         leaf foo1 {
>>>>           type string;
>>>>         }
>>>>         leaf foo2 {
>>>>           type string;
>>>>         }
>>>>       }
>>>>     }
>>>>     container meh;
>>>>   }
>>>>
>>>>   augment "/ch1/foo/foos" {
>>>>     when "enable-foos = 'true'";
>>>>     leaf foo3 {
>>>>       type string;
>>>>     }
>>>>   }
>>>>
>>>> OLD:
>>>>
>>>>    o  If the "when" statement is a child of an "augment" statement, then
>>>>       the context node is the augment's target node in the data tree, if
>>>>       the target node is a data node.  Otherwise, the context node is
>>>>       the closest ancestor node to the target node that is also a data
>>>>       node.
>>>>
>>>> NEW:
>>>>
>>>>    o  If the "when" statement is a child of an "augment" statement, then
>>>>       the context node is the augment's target node in the data tree, if
>>>>       the target node is a data node.  Otherwise, the context node is
>>>>       the closest ancestor node to the target node that is also a data
>>>>       node. If no such node exists, the context node is the root node.
>>>>
>>> Good catch, I support this change.
>>>
>>> Also regarding sec. 7.21.5, I think we agreed that a when expression must not reference nodes that are made conditional through that when statement. I can’t find this rule in the text.
>> The "no referencing the initial context node and its descendants" text is currently in the guidelines draft only (6087bis).
> IMO this should be a hard rule in 6020bis. Such expressions are seriously broken and could lead to deadlocks.

I think that was the purpose of the change in 3rd bullet. A "dummy" node 
with no value and child nodes has been introduced.

    o  If the "when" statement is a child of any other data definition
       statement, the accessible tree is tentatively altered during the
       processing of the XPath expression by replacing all instances (if
       any) of the data node for which the "when" statement is defined
       with a single dummy node with the same name, but with no value and
       no children.  The context node is this dummy node.

Jernej

> Lada
>
>> Jernej
>>
>>> Lada
>>>
>>>> Jernej
>>>>
>>>> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>   This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>>>>>
>>>>>          Title           : The YANG 1.1 Data Modeling Language
>>>>>          Author          : Martin Bjorklund
>>>>> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
>>>>> 	Pages           : 196
>>>>> 	Date            : 2015-09-23
>>>>>
>>>>> Abstract:
>>>>>     YANG is a data modeling language used to model configuration data,
>>>>>     state data, remote procedure calls, and notifications for network
>>>>>     management protocols like the Network Configuration Protocol
>>>>>     (NETCONF).
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07
>>>>>
>>>>>
>>>>> 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/
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 23 05:21:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2949B1B29C3 for ; Wed, 23 Sep 2015 05:21: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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvCiLriVsVsz for ; Wed, 23 Sep 2015 05:21:13 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9A1B29B5 for ; Wed, 23 Sep 2015 05:21:12 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2582B1CC0116; Wed, 23 Sep 2015 14:21:18 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund 
In-Reply-To: <20150923.130709.926246931083333700.mbj@tail-f.com>
References:  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <20150923.130709.926246931083333700.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 23 Sep 2015 14:21:04 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 12:21:15 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>>=20
>> > On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>> >=20
>> > Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>> >>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>> >>>=20
>> >>> Section 7.21.5., the first bullet describing the augmentation case
>> >>> does not consider that an "augment" may specify a top-level "choice"
>> >>> or a "choice"/"case" nested within a top-level "choice" as the target
>> >>> node. There will be no initial context node for the expression in su=
ch
>> >>> a case.
>> >>>=20
>> >>>  leaf enable-foos {
>> >>>    type boolean;
>> >>>  }
>> >>>  choice ch1 {
>> >>>    case foo {
>> >>>      choice foos {
>> >>>        when "enable-foos =3D 'true'";
>> >>>        leaf foo1 {
>> >>>          type string;
>> >>>        }
>> >>>        leaf foo2 {
>> >>>          type string;
>> >>>        }
>> >>>      }
>> >>>    }
>> >>>    container meh;
>> >>>  }
>> >>>=20
>> >>>  augment "/ch1/foo/foos" {
>> >>>    when "enable-foos =3D 'true'";
>> >>>    leaf foo3 {
>> >>>      type string;
>> >>>    }
>> >>>  }
>> >>>=20
>> >>> OLD:
>> >>>=20
>> >>>   o  If the "when" statement is a child of an "augment" statement, t=
hen
>> >>>      the context node is the augment's target node in the data tree,=
 if
>> >>>      the target node is a data node.  Otherwise, the context node is
>> >>>      the closest ancestor node to the target node that is also a data
>> >>>      node.
>> >>>=20
>> >>> NEW:
>> >>>=20
>> >>>   o  If the "when" statement is a child of an "augment" statement, t=
hen
>> >>>      the context node is the augment's target node in the data tree,=
 if
>> >>>      the target node is a data node.  Otherwise, the context node is
>> >>>      the closest ancestor node to the target node that is also a data
>> >>>      node. If no such node exists, the context node is the root node.
>> >>>=20
>> >> Good catch, I support this change.
>> >>=20
>> >> Also regarding sec. 7.21.5, I think we agreed that a when expression
>> >> must not reference nodes that are made conditional through that when
>> >> statement. I can=E2=80=99t find this rule in the text.
>> >=20
>> > The "no referencing the initial context node and its descendants" text
>> > is currently in the guidelines draft only (6087bis).
>>=20
>> IMO this should be a hard rule in 6020bis. Such expressions are
>> seriously broken and could lead to deadlocks.
>
> This reminds me of Juergen's golden rule: "All implementations of this
> spec MUST be bug-free".  We'd have to say "all XPath expressions MUST
> make sense".

Of course this is very different. An XPath expression that doesn=E2=80=99t =
make
sense represents no problem whatsoever as long as the result can be
reliably determined.

What we (potentially) have here is this: the server evaluates an
expression, then changes the datastore schema based on the result,
deletes some instances from the datastore, but after this the XPath
expression gives a different result. This IMO indicates that it's
something rotten with the definition of "when".

>
> Referencing nodes that don't exist is legal XPath, but it probably
>does not make much sense.

It's more complicated than this because of other YANG-specific rules.

container foo {
  when "not(enabled =3D 'false')";
  leaf enabled {
    type boolean;
    default false;
  }
}

If there is no "foo" in the datastore, then the procedure from the third
bullet in sec. 7.21.5 leads to the result that the when expression is
true, so "foo" is valid and the default value for "enabled" comes into
play, which however makes the when expression evaluate to false.

Lada

>
>
> /martin

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Sep 23 05:29:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB041B29CF for ; Wed, 23 Sep 2015 05:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iLhOan2kqNF for ; Wed, 23 Sep 2015 05:29:22 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2141A6F32 for ; Wed, 23 Sep 2015 05:29:22 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 113511CC0116; Wed, 23 Sep 2015 14:29:30 +0200 (CEST)
From: Ladislav Lhotka 
To: Jernej Tuljak 
In-Reply-To: <560287D1.9050905@mg-soft.si>
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si>  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <560287D1.9050905@mg-soft.si>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 23 Sep 2015 14:29:15 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 12:29:24 -0000

Jernej Tuljak  writes:

> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>
>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>
>>>>> Section 7.21.5., the first bullet describing the augmentation case do=
es not consider that an "augment" may specify a top-level "choice" or a "ch=
oice"/"case" nested within a top-level "choice" as the target node. There w=
ill be no initial context node for the expression in such a case.
>>>>>
>>>>>   leaf enable-foos {
>>>>>     type boolean;
>>>>>   }
>>>>>   choice ch1 {
>>>>>     case foo {
>>>>>       choice foos {
>>>>>         when "enable-foos =3D 'true'";
>>>>>         leaf foo1 {
>>>>>           type string;
>>>>>         }
>>>>>         leaf foo2 {
>>>>>           type string;
>>>>>         }
>>>>>       }
>>>>>     }
>>>>>     container meh;
>>>>>   }
>>>>>
>>>>>   augment "/ch1/foo/foos" {
>>>>>     when "enable-foos =3D 'true'";
>>>>>     leaf foo3 {
>>>>>       type string;
>>>>>     }
>>>>>   }
>>>>>
>>>>> OLD:
>>>>>
>>>>>    o  If the "when" statement is a child of an "augment" statement, t=
hen
>>>>>       the context node is the augment's target node in the data tree,=
 if
>>>>>       the target node is a data node.  Otherwise, the context node is
>>>>>       the closest ancestor node to the target node that is also a data
>>>>>       node.
>>>>>
>>>>> NEW:
>>>>>
>>>>>    o  If the "when" statement is a child of an "augment" statement, t=
hen
>>>>>       the context node is the augment's target node in the data tree,=
 if
>>>>>       the target node is a data node.  Otherwise, the context node is
>>>>>       the closest ancestor node to the target node that is also a data
>>>>>       node. If no such node exists, the context node is the root node.
>>>>>
>>>> Good catch, I support this change.
>>>>
>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression m=
ust not reference nodes that are made conditional through that when stateme=
nt. I can=E2=80=99t find this rule in the text.
>>> The "no referencing the initial context node and its descendants" text =
is currently in the guidelines draft only (6087bis).
>> IMO this should be a hard rule in 6020bis. Such expressions are seriousl=
y broken and could lead to deadlocks.
>
> I think that was the purpose of the change in 3rd bullet. A "dummy" node=
=20
> with no value and child nodes has been introduced.

Not really, the dummy node solves the problem of a non-existent context
node. If the when expression refers to the value or descendants of the
dummy node, then the procedure is ill-defined, see my response to
Martin.

Lada

>
>     o  If the "when" statement is a child of any other data definition
>        statement, the accessible tree is tentatively altered during the
>        processing of the XPath expression by replacing all instances (if
>        any) of the data node for which the "when" statement is defined
>        with a single dummy node with the same name, but with no value and
>        no children.  The context node is this dummy node.
>
> Jernej
>
>> Lada
>>
>>> Jernej
>>>
>>>> Lada
>>>>
>>>>> Jernej
>>>>>
>>>>> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d=
irectories.
>>>>>>   This draft is a work item of the NETCONF Data Modeling Language Wo=
rking Group of the IETF.
>>>>>>
>>>>>>          Title           : The YANG 1.1 Data Modeling Language
>>>>>>          Author          : Martin Bjorklund
>>>>>> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
>>>>>> 	Pages           : 196
>>>>>> 	Date            : 2015-09-23
>>>>>>
>>>>>> Abstract:
>>>>>>     YANG is a data modeling language used to model configuration dat=
a,
>>>>>>     state data, remote procedure calls, and notifications for network
>>>>>>     management protocols like the Network Configuration Protocol
>>>>>>     (NETCONF).
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>>>>>
>>>>>> There's also a htmlized version available at:
>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-07
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of su=
bmission
>>>>>> 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/
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Sep 23 06:08:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB71B2E45 for ; Wed, 23 Sep 2015 06:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A4ddymXZasf for ; Wed, 23 Sep 2015 06:08:27 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4CC1B2E42 for ; Wed, 23 Sep 2015 06:08:26 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id B6A1FC4175C5; Wed, 23 Sep 2015 15:08:22 +0200 (CEST)
To: Ladislav Lhotka , Martin Bjorklund 
References:  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <20150923.130709.926246931083333700.mbj@tail-f.com> 
From: Jernej Tuljak 
Message-ID: <5602A442.9020205@mg-soft.si>
Date: Wed, 23 Sep 2015 15:08:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 13:08:29 -0000

Ladislav Lhotka je 23.9.2015 ob 14:21 napisal:
> Martin Bjorklund  writes:
>
>> Ladislav Lhotka  wrote:
>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>
>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>>
>>>>>> Section 7.21.5., the first bullet describing the augmentation case
>>>>>> does not consider that an "augment" may specify a top-level "choice"
>>>>>> or a "choice"/"case" nested within a top-level "choice" as the target
>>>>>> node. There will be no initial context node for the expression in such
>>>>>> a case.
>>>>>>
>>>>>>   leaf enable-foos {
>>>>>>     type boolean;
>>>>>>   }
>>>>>>   choice ch1 {
>>>>>>     case foo {
>>>>>>       choice foos {
>>>>>>         when "enable-foos = 'true'";
>>>>>>         leaf foo1 {
>>>>>>           type string;
>>>>>>         }
>>>>>>         leaf foo2 {
>>>>>>           type string;
>>>>>>         }
>>>>>>       }
>>>>>>     }
>>>>>>     container meh;
>>>>>>   }
>>>>>>
>>>>>>   augment "/ch1/foo/foos" {
>>>>>>     when "enable-foos = 'true'";
>>>>>>     leaf foo3 {
>>>>>>       type string;
>>>>>>     }
>>>>>>   }
>>>>>>
>>>>>> OLD:
>>>>>>
>>>>>>    o  If the "when" statement is a child of an "augment" statement, then
>>>>>>       the context node is the augment's target node in the data tree, if
>>>>>>       the target node is a data node.  Otherwise, the context node is
>>>>>>       the closest ancestor node to the target node that is also a data
>>>>>>       node.
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>>    o  If the "when" statement is a child of an "augment" statement, then
>>>>>>       the context node is the augment's target node in the data tree, if
>>>>>>       the target node is a data node.  Otherwise, the context node is
>>>>>>       the closest ancestor node to the target node that is also a data
>>>>>>       node. If no such node exists, the context node is the root node.
>>>>>>
>>>>> Good catch, I support this change.
>>>>>
>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression
>>>>> must not reference nodes that are made conditional through that when
>>>>> statement. I can’t find this rule in the text.
>>>> The "no referencing the initial context node and its descendants" text
>>>> is currently in the guidelines draft only (6087bis).
>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>> seriously broken and could lead to deadlocks.
>> This reminds me of Juergen's golden rule: "All implementations of this
>> spec MUST be bug-free".  We'd have to say "all XPath expressions MUST
>> make sense".
> Of course this is very different. An XPath expression that doesn’t make
> sense represents no problem whatsoever as long as the result can be
> reliably determined.
>
> What we (potentially) have here is this: the server evaluates an
> expression, then changes the datastore schema based on the result,
> deletes some instances from the datastore, but after this the XPath
> expression gives a different result. This IMO indicates that it's
> something rotten with the definition of "when".
>
>> Referencing nodes that don't exist is legal XPath, but it probably
>> does not make much sense.
> It's more complicated than this because of other YANG-specific rules.
>
> container foo {
>    when "not(enabled = 'false')";
>    leaf enabled {
>      type boolean;
>      default false;
>    }
> }
>
> If there is no "foo" in the datastore, then the procedure from the third
> bullet in sec. 7.21.5 leads to the result that the when expression is
> true, so "foo" is valid and the default value for "enabled" comes into
> play, which however makes the when expression evaluate to false.

This is not how I read it. 3rd bullet makes your expression _always_ 
evaluate to the same boolean value, since there is no "enabled" child 
node to "foo" during evaluation, ever. It will never be present in the 
accessible tree, since it is pruned away before evaluation 
(child::enabled always returns an empty node-set no matter what is in 
your datastore).

Jernej

>
> Lada
>
>>
>> /martin


From nobody Wed Sep 23 06:11:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1C1B2E57 for ; Wed, 23 Sep 2015 06:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvv6JBjt-dk6 for ; Wed, 23 Sep 2015 06:11:30 -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 B6DC91B2E54 for ; Wed, 23 Sep 2015 06:11:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 332CF93D; Wed, 23 Sep 2015 15:11:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6PqnLkwSrgI9; Wed, 23 Sep 2015 15:11:26 +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, 23 Sep 2015 15:11:26 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E744D20053; Wed, 23 Sep 2015 15:11:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5l6hh_mrlQvS; Wed, 23 Sep 2015 15:11:24 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10D932004E; Wed, 23 Sep 2015 15:11:23 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D63793757485; Wed, 23 Sep 2015 15:11:21 +0200 (CEST)
Date: Wed, 23 Sep 2015 15:11:20 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150923131119.GA1945@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 13:11:32 -0000

On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote:
> >> 
> >> I must admit I am getting lost in these discussions. It seems to me there is a lot of hand-waving and hidden assumptions that moreover differ from one person to another. As I already said in Prague, both anyxml and anydata are IMO constructs of marginal utility and it is frustrating we spend so much effort on them.
> >>
> >
> > I agree that anyxml is of marginal utility, anydata however is needed
> > for any rpc/action/notification or future language construct that can
> > work with generic YANG content and hence I think its behaviour and
> > encoding should be well defined.
> 
> But then I believe we should have stricter rules for anydata than just
> "an unknown set of nodes that can be modelled with YANG" - it should be
> stated that the data model for an anydata instance MUST be known at
> run-time. Otherwise I think anyxml can cover all use cases you mention
> as well (as it has done in the past), and there is no need to introduce
> a new data node type with a definition that allows for multiple
> interpretations.
>

Lada, we are not repeating the discussion. It was long and painful
enough and we finally accepted and verified Y34-05. If you have better
wording to propose, feel free to make a proposal. But I am not going
to open Y34 again just because you still do not like it.

That said, "MUST be known at run-time" may already fall apart with the
mount proposals discussed in NETCONF (or it is sufficiently unclear to
whom it MUST be known).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 23 06:13:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811251A6F0A for ; Wed, 23 Sep 2015 06:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USgQs8oIQZfR for ; Wed, 23 Sep 2015 06:13:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD5E1B2E21 for ; Wed, 23 Sep 2015 06:13:43 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id C0708181849; Wed, 23 Sep 2015 15:13:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443014021; bh=8ZyAgshOmCWlTyXhVNJjY0mmE5ihia73SR2L1uQPXeE=; h=From:Date:To; b=j+EkB8XphCjvSWJ5BUdodeY8x2tk/MTLRJWgWX+RiyFJS9jgNEgC8LxG7fqHGXGu2 0NJanetFCue6cQpSoKwGFuLVuays+hm/hTXvHQi7bEaonWSwS5xS7OTDTh/9OuC+kW KmeVsh6EezKfCIu03uv52NvNEviGoHzFyM/Hiv0w=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <5602A442.9020205@mg-soft.si>
Date: Wed, 23 Sep 2015 15:13:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7968BC66-1BEC-493B-A51B-37BCF20482C9@nic.cz>
References:  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <20150923.130709.926246931083333700.mbj@tail-f.com>  <5602A442.9020205@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 13:13:50 -0000

> On 23 Sep 2015, at 15:08, Jernej Tuljak  wrote:
>=20
> Ladislav Lhotka je 23.9.2015 ob 14:21 napisal:
>> Martin Bjorklund  writes:
>>=20
>>> Ladislav Lhotka  wrote:
>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  =
wrote:
>>>>>=20
>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  =
wrote:
>>>>>>>=20
>>>>>>> Section 7.21.5., the first bullet describing the augmentation =
case
>>>>>>> does not consider that an "augment" may specify a top-level =
"choice"
>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the =
target
>>>>>>> node. There will be no initial context node for the expression =
in such
>>>>>>> a case.
>>>>>>>=20
>>>>>>>  leaf enable-foos {
>>>>>>>    type boolean;
>>>>>>>  }
>>>>>>>  choice ch1 {
>>>>>>>    case foo {
>>>>>>>      choice foos {
>>>>>>>        when "enable-foos =3D 'true'";
>>>>>>>        leaf foo1 {
>>>>>>>          type string;
>>>>>>>        }
>>>>>>>        leaf foo2 {
>>>>>>>          type string;
>>>>>>>        }
>>>>>>>      }
>>>>>>>    }
>>>>>>>    container meh;
>>>>>>>  }
>>>>>>>=20
>>>>>>>  augment "/ch1/foo/foos" {
>>>>>>>    when "enable-foos =3D 'true'";
>>>>>>>    leaf foo3 {
>>>>>>>      type string;
>>>>>>>    }
>>>>>>>  }
>>>>>>>=20
>>>>>>> OLD:
>>>>>>>=20
>>>>>>>   o  If the "when" statement is a child of an "augment" =
statement, then
>>>>>>>      the context node is the augment's target node in the data =
tree, if
>>>>>>>      the target node is a data node.  Otherwise, the context =
node is
>>>>>>>      the closest ancestor node to the target node that is also a =
data
>>>>>>>      node.
>>>>>>>=20
>>>>>>> NEW:
>>>>>>>=20
>>>>>>>   o  If the "when" statement is a child of an "augment" =
statement, then
>>>>>>>      the context node is the augment's target node in the data =
tree, if
>>>>>>>      the target node is a data node.  Otherwise, the context =
node is
>>>>>>>      the closest ancestor node to the target node that is also a =
data
>>>>>>>      node. If no such node exists, the context node is the root =
node.
>>>>>>>=20
>>>>>> Good catch, I support this change.
>>>>>>=20
>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when =
expression
>>>>>> must not reference nodes that are made conditional through that =
when
>>>>>> statement. I can=E2=80=99t find this rule in the text.
>>>>> The "no referencing the initial context node and its descendants" =
text
>>>>> is currently in the guidelines draft only (6087bis).
>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>> seriously broken and could lead to deadlocks.
>>> This reminds me of Juergen's golden rule: "All implementations of =
this
>>> spec MUST be bug-free".  We'd have to say "all XPath expressions =
MUST
>>> make sense".
>> Of course this is very different. An XPath expression that doesn=E2=80=99=
t make
>> sense represents no problem whatsoever as long as the result can be
>> reliably determined.
>>=20
>> What we (potentially) have here is this: the server evaluates an
>> expression, then changes the datastore schema based on the result,
>> deletes some instances from the datastore, but after this the XPath
>> expression gives a different result. This IMO indicates that it's
>> something rotten with the definition of "when".
>>=20
>>> Referencing nodes that don't exist is legal XPath, but it probably
>>> does not make much sense.
>> It's more complicated than this because of other YANG-specific rules.
>>=20
>> container foo {
>>   when "not(enabled =3D 'false')";
>>   leaf enabled {
>>     type boolean;
>>     default false;
>>   }
>> }
>>=20
>> If there is no "foo" in the datastore, then the procedure from the =
third
>> bullet in sec. 7.21.5 leads to the result that the when expression is
>> true, so "foo" is valid and the default value for "enabled" comes =
into
>> play, which however makes the when expression evaluate to false.
>=20
> This is not how I read it.

Well, I significantly contributed to this formulation. :-)

> 3rd bullet makes your expression _always_ evaluate to the same boolean =
value, since there is no "enabled" child node to "foo" during =
evaluation, ever. It will never be present in the accessible tree, since =
it is pruned away before evaluation (child::enabled always returns an =
empty node-set no matter what is in your datastore).

Are you saying that the data tree

"foo": { "enabled" : false }

is valid?

Lada

>=20
> Jernej
>=20
>>=20
>> Lada
>>=20
>>>=20
>>> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 23 06:38:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233E41A86E4 for ; Wed, 23 Sep 2015 06:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level: 
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVL2-S5cyK6Z for ; Wed, 23 Sep 2015 06:38:25 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id AE2211A8547 for ; Wed, 23 Sep 2015 06:38:24 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 808ABC4175C5; Wed, 23 Sep 2015 15:38:23 +0200 (CEST)
To: Ladislav Lhotka 
References:  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <20150923.130709.926246931083333700.mbj@tail-f.com>  <5602A442.9020205@mg-soft.si> <7968BC66-1BEC-493B-A51B-37BCF20482C9@nic.cz>
From: Jernej Tuljak 
Message-ID: <5602AB4A.1080606@mg-soft.si>
Date: Wed, 23 Sep 2015 15:38:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <7968BC66-1BEC-493B-A51B-37BCF20482C9@nic.cz>
Content-Type: multipart/alternative; boundary="------------090402060802060209020507"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 13:38:27 -0000

This is a multi-part message in MIME format.
--------------090402060802060209020507
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Ladislav Lhotka je 23.9.2015 ob 15:13 napisal:
>> On 23 Sep 2015, at 15:08, Jernej Tuljak  wrote:
>>
>> Ladislav Lhotka je 23.9.2015 ob 14:21 napisal:
>>> Martin Bjorklund  writes:
>>>
>>>> Ladislav Lhotka  wrote:
>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>>>
>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>>>>
>>>>>>>> Section 7.21.5., the first bullet describing the augmentation case
>>>>>>>> does not consider that an "augment" may specify a top-level "choice"
>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the target
>>>>>>>> node. There will be no initial context node for the expression in such
>>>>>>>> a case.
>>>>>>>>
>>>>>>>>   leaf enable-foos {
>>>>>>>>     type boolean;
>>>>>>>>   }
>>>>>>>>   choice ch1 {
>>>>>>>>     case foo {
>>>>>>>>       choice foos {
>>>>>>>>         when "enable-foos = 'true'";
>>>>>>>>         leaf foo1 {
>>>>>>>>           type string;
>>>>>>>>         }
>>>>>>>>         leaf foo2 {
>>>>>>>>           type string;
>>>>>>>>         }
>>>>>>>>       }
>>>>>>>>     }
>>>>>>>>     container meh;
>>>>>>>>   }
>>>>>>>>
>>>>>>>>   augment "/ch1/foo/foos" {
>>>>>>>>     when "enable-foos = 'true'";
>>>>>>>>     leaf foo3 {
>>>>>>>>       type string;
>>>>>>>>     }
>>>>>>>>   }
>>>>>>>>
>>>>>>>> OLD:
>>>>>>>>
>>>>>>>>    o  If the "when" statement is a child of an "augment" statement, then
>>>>>>>>       the context node is the augment's target node in the data tree, if
>>>>>>>>       the target node is a data node.  Otherwise, the context node is
>>>>>>>>       the closest ancestor node to the target node that is also a data
>>>>>>>>       node.
>>>>>>>>
>>>>>>>> NEW:
>>>>>>>>
>>>>>>>>    o  If the "when" statement is a child of an "augment" statement, then
>>>>>>>>       the context node is the augment's target node in the data tree, if
>>>>>>>>       the target node is a data node.  Otherwise, the context node is
>>>>>>>>       the closest ancestor node to the target node that is also a data
>>>>>>>>       node. If no such node exists, the context node is the root node.
>>>>>>>>
>>>>>>> Good catch, I support this change.
>>>>>>>
>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression
>>>>>>> must not reference nodes that are made conditional through that when
>>>>>>> statement. I can’t find this rule in the text.
>>>>>> The "no referencing the initial context node and its descendants" text
>>>>>> is currently in the guidelines draft only (6087bis).
>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>> seriously broken and could lead to deadlocks.
>>>> This reminds me of Juergen's golden rule: "All implementations of this
>>>> spec MUST be bug-free".  We'd have to say "all XPath expressions MUST
>>>> make sense".
>>> Of course this is very different. An XPath expression that doesn’t make
>>> sense represents no problem whatsoever as long as the result can be
>>> reliably determined.
>>>
>>> What we (potentially) have here is this: the server evaluates an
>>> expression, then changes the datastore schema based on the result,
>>> deletes some instances from the datastore, but after this the XPath
>>> expression gives a different result. This IMO indicates that it's
>>> something rotten with the definition of "when".
>>>
>>>> Referencing nodes that don't exist is legal XPath, but it probably
>>>> does not make much sense.
>>> It's more complicated than this because of other YANG-specific rules.
>>>
>>> container foo {
>>>    when "not(enabled = 'false')";
>>>    leaf enabled {
>>>      type boolean;
>>>      default false;
>>>    }
>>> }
>>>
>>> If there is no "foo" in the datastore, then the procedure from the third
>>> bullet in sec. 7.21.5 leads to the result that the when expression is
>>> true, so "foo" is valid and the default value for "enabled" comes into
>>> play, which however makes the when expression evaluate to false.
>> This is not how I read it.
> Well, I significantly contributed to this formulation. :-)
>
>> 3rd bullet makes your expression _always_ evaluate to the same boolean value, since there is no "enabled" child node to "foo" during evaluation, ever. It will never be present in the accessible tree, since it is pruned away before evaluation (child::enabled always returns an empty node-set no matter what is in your datastore).
> Are you saying that the data tree
>
> "foo": { "enabled" : false }
>
> is valid?

Yes. And so would be:

"foo": { "enabled" : true }

In XPath 1.0 spec language (Section 3.4):

If one object to be compared is a node-set and the other is a string, 
then the comparison will be true if and only if there is a node in the 
node-set such that the result of performing the comparison on the 
string-value 
of the 
node and the other string is true

meaning that

enabled = 'false'

always evaluates to boolean false, since the node-set will always be 
empty, no matter what you do.

 From the expression context point of view, your expression could be 
changed to:

not(enabled1 = 'false')
not(enabled2 = 'false')
not(enabled3 = 'false')
...
not(enabledN = 'false')

but that would make no difference, since the context node (foo) will 
never have any children. You can no longer reference descendants of the 
context node, nor its value (unless it's the document root) in when 
expressions.

If you take the negation away in your example, your instance will never 
be valid, however.

Jernej

>
> Lada
>
>> Jernej
>>
>>> Lada
>>>
>>>> /martin
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>


--------------090402060802060209020507
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Ladislav Lhotka je 23.9.2015 ob
      15:13 napisal:

    

    

      

      

        
On 23 Sep 2015, at 15:08, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Ladislav Lhotka je 23.9.2015 ob 14:21 napisal:


        

          
Martin Bjorklund <mbj@tail-f.com> writes:



          

            
Ladislav Lhotka <lhotka@nic.cz> wrote:


            

              

                
On 23 Sep 2015, at 12:37, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:


                

                  

                    
On 23 Sep 2015, at 11:45, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Section 7.21.5., the first bullet describing the augmentation case
does not consider that an "augment" may specify a top-level "choice"
or a "choice"/"case" nested within a top-level "choice" as the target
node. There will be no initial context node for the expression in such
a case.

 leaf enable-foos {
   type boolean;
 }
 choice ch1 {
   case foo {
     choice foos {
       when "enable-foos = 'true'";
       leaf foo1 {
         type string;
       }
       leaf foo2 {
         type string;
       }
     }
   }
   container meh;
 }

 augment "/ch1/foo/foos" {
   when "enable-foos = 'true'";
   leaf foo3 {
     type string;
   }
 }

OLD:

  o  If the "when" statement is a child of an "augment" statement, then
     the context node is the augment's target node in the data tree, if
     the target node is a data node.  Otherwise, the context node is
     the closest ancestor node to the target node that is also a data
     node.

NEW:

  o  If the "when" statement is a child of an "augment" statement, then
     the context node is the augment's target node in the data tree, if
     the target node is a data node.  Otherwise, the context node is
     the closest ancestor node to the target node that is also a data
     node. If no such node exists, the context node is the root node.



                  

                  
Good catch, I support this change.

Also regarding sec. 7.21.5, I think we agreed that a when expression
must not reference nodes that are made conditional through that when
statement. I can’t find this rule in the text.


                

                
The "no referencing the initial context node and its descendants" text
is currently in the guidelines draft only (6087bis).


              

              
IMO this should be a hard rule in 6020bis. Such expressions are
seriously broken and could lead to deadlocks.


            

            
This reminds me of Juergen's golden rule: "All implementations of this
spec MUST be bug-free".  We'd have to say "all XPath expressions MUST
make sense".


          

          
Of course this is very different. An XPath expression that doesn’t make
sense represents no problem whatsoever as long as the result can be
reliably determined.

What we (potentially) have here is this: the server evaluates an
expression, then changes the datastore schema based on the result,
deletes some instances from the datastore, but after this the XPath
expression gives a different result. This IMO indicates that it's
something rotten with the definition of "when".



          

            
Referencing nodes that don't exist is legal XPath, but it probably
does not make much sense.


          

          
It's more complicated than this because of other YANG-specific rules.

container foo {
  when "not(enabled = 'false')";
  leaf enabled {
    type boolean;
    default false;
  }
}

If there is no "foo" in the datastore, then the procedure from the third
bullet in sec. 7.21.5 leads to the result that the when expression is
true, so "foo" is valid and the default value for "enabled" comes into
play, which however makes the when expression evaluate to false.


        

        
This is not how I read it.


      

      
Well, I significantly contributed to this formulation. :-)



      

        
3rd bullet makes your expression _always_ evaluate to the same boolean value, since there is no "enabled" child node to "foo" during evaluation, ever. It will never be present in the accessible tree, since it is pruned away before evaluation (child::enabled always returns an empty node-set no matter what is in your datastore).


      

      
Are you saying that the data tree

"foo": { "enabled" : false }

is valid?

    

    

    Yes. And so would be:

    
"foo": { "enabled" : true }


    In XPath 1.0 spec language (Section 3.4):

    

    If
      one object to be compared is a node-set and the other is a string,
      then the comparison will be true if and only if there is a node in
      the
      node-set such that the result of performing the comparison on the
    string-value
      of the node and
      the other string is true

    

    meaning that 

    
enabled = 'false'

    always evaluates to boolean false, since the node-set will always be
    empty, no matter what you do.

    

    From the expression context point of view, your expression could be
    changed to:

    
not(enabled1 = 'false')
not(enabled2 = 'false')
not(enabled3 = 'false')
...
not(enabledN = 'false')



    but that would make no difference, since the context node (foo) will
    never have any children. You can no longer reference descendants of
    the context node, nor its value (unless it's the document root) in
    when expressions.

    

    If you take the negation away in your example, your instance will
    never be valid, however.

    

    Jernej

    

    

      

Lada



      

        
Jernej



        

          
Lada



          

            
/martin


          

        

      

      
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C







    

    

  


--------------090402060802060209020507--


From nobody Wed Sep 23 06:46:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDE41B2F78 for ; Wed, 23 Sep 2015 06:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43Wtb0bdmqfh for ; Wed, 23 Sep 2015 06:46:35 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B6A1A854D for ; Wed, 23 Sep 2015 06:46:34 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 5D310181896; Wed, 23 Sep 2015 15:46:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443015993; bh=tQgp85/oPFRC30rwZlnEiM8tou7jpUSCzDqWndzlt4Q=; h=From:Date:To; b=Guc/vBtsFQQS2UN/LLY/ILi9aMk/N6TAHFowgVatigFHEX8HSvoI5W+okCMCUt812 GzObSpBZFWnC9Wrc8UOBX0OMa06z2yky2BEgDqa6jQCORsH+9dOYR/fr67S4kUYrUL q4D6E3hy60OKA++LBA31CC+jgehepiXqkQDyDNHE=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150923131119.GA1945@elstar.local>
Date: Wed, 23 Sep 2015 15:46:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local>  <20150923131119.GA1945@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 13:46:36 -0000

> On 23 Sep 2015, at 15:11, Juergen Schoenwaelder =
 wrote:
>=20
> On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote:
>>>>=20
>>>> I must admit I am getting lost in these discussions. It seems to me =
there is a lot of hand-waving and hidden assumptions that moreover =
differ from one person to another. As I already said in Prague, both =
anyxml and anydata are IMO constructs of marginal utility and it is =
frustrating we spend so much effort on them.
>>>>=20
>>>=20
>>> I agree that anyxml is of marginal utility, anydata however is =
needed
>>> for any rpc/action/notification or future language construct that =
can
>>> work with generic YANG content and hence I think its behaviour and
>>> encoding should be well defined.
>>=20
>> But then I believe we should have stricter rules for anydata than =
just
>> "an unknown set of nodes that can be modelled with YANG" - it should =
be
>> stated that the data model for an anydata instance MUST be known at
>> run-time. Otherwise I think anyxml can cover all use cases you =
mention
>> as well (as it has done in the past), and there is no need to =
introduce
>> a new data node type with a definition that allows for multiple
>> interpretations.
>>=20
>=20
> Lada, we are not repeating the discussion. It was long and painful
> enough and we finally accepted and verified Y34-05. If you have better
> wording to propose, feel free to make a proposal. But I am not going
> to open Y34 again just because you still do not like it.

Experience has shown that the current formulation is understood =
differently by different people.

Earlier in this thread, you proposed this text to be added to the =
yang-json spec:

     An anydata data node can contain an unknown set of nodes that can
     be modelled by YANG. A data model for anydata content may or may
     not exist at run time.  If the data model for anydata content is
     available, then the anydata content MUST be encoded according to
     the rules of this specification. If the data model for anydata
     content is not available, the encoding MUST follow the rules of
     this specification except for rules that require data model
     knowledge (and as a consequence, numbers may appear as strings or
     namespace qualifiers may not match module names).

So let me repeat: shouldn=E2=80=99t this text really go to 6020bis? Or =
do you think that XML encoding needn=E2=80=99t abide by the data model =
if it is known?

>=20
> That said, "MUST be known at run-time" may already fall apart with the
> mount proposals discussed in NETCONF (or it is sufficiently unclear to
> whom it MUST be known).

To the server and client so that they both work with the same data =
model. Of course, it is true that currently there are no means for =
passing this information (either way) but I guess your text above =
suffers from the same problem: how can you tell whether the data model =
for anydata content is available or not?=20

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 23 06:51:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34DA1B30E1 for ; Wed, 23 Sep 2015 06:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf4YcF3JleYY for ; Wed, 23 Sep 2015 06:50:57 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4384D1B30D1 for ; Wed, 23 Sep 2015 06:50:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5216; q=dns/txt; s=iport; t=1443016257; x=1444225857; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=2QMCIulcYwTXyBQBZHEYx0KvamWaDR/Hf5NJmiYpAj4=; b=L+6T7Eig0d6E7V5hB0Z5IPHYQG7hwWKSTxNV1VhMluWmu8o6YhQl5VAr PJNGR8RXMATn2Z+l+tY+4Ye7PAUfxzJPNSWiCtcPG0cgKwvkm4xUNnFOr ItYKAE58Ukj2pvFi+7E9cJEwJAIBDLu/eS23u5i9GJ2EvZn6le80ft5i1 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbBAD8rAJW/xbLJq1UCYRhxVQCghIBAQEBAQGBC4QkAQEBBDhAEQsQBQMJFg8JAwIBAgFFBgEMBgIBAYgqyzQBAQEBAQEBAQEBAQEBAQEBAQEahnOEfYQxEVKELAEElWeNC4kDkidjghEcgVU9M4ltAQEB
X-IronPort-AV: E=Sophos;i="5.17,577,1437436800"; d="scan'208";a="607189838"
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; 23 Sep 2015 13:50:55 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8NDot48022772; Wed, 23 Sep 2015 13:50:55 GMT
To: Ladislav Lhotka , netmod@ietf.org, j.schoenwaelder@jacobs-university.de
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local>  <20150921082628.GA11184@elstar.local>
From: Robert Wilton 
Message-ID: <5602AE3A.9020902@cisco.com>
Date: Wed, 23 Sep 2015 14:50:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150921082628.GA11184@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 13:51:02 -0000

Hi Juergen,

On 21/09/2015 09:26, Juergen Schoenwaelder wrote:
> On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>
> Still some text needs to be written explaining that breaking old
> clients by adding new mandatory nodes is a no go. I did not ask to
> enumerate all situations where it is allowed, I am looking for text
> that clearly says what people have to look out for if they add
> mandatory nodes.
Would it be sufficient to just change the MUST NOT to SHOULD NOT and 
then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which 
seems to provide the explanation that you are requesting?

E.g. something like:

draft-ietf-netmod-rfc6020bis, section 7.17.  The augment Statement

From:

If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1).

To:

If the target node is in another module, then nodes added by the
augmentation SHOULD NOT be mandatory nodes (see Section 3.1).  The
safe scenarios to augment with mandatory nodes are described in
[draft-ietf-netmod-rfc6087bis] section 5.17.2.


For reference, I've also reproduced the text for 
draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below:

5.17.  Augment Statements

    The YANG "augment" statement is used to define a set of data
    definition statements that will be added as child nodes of a target
    data node.  The module namespace for these data nodes will be the
    augmenting module, not the augmented module.

    A top-level "augment" statement SHOULD NOT be used if the target data
    node is in the same module or submodule as the evaluated "augment"
    statement.  The data definition statements SHOULD be added inline
    instead.

5.17.1.  Conditional Augment Statements

    The "augment" statement is often used together with the "when"
    statement and/or "if-feature" statement to make the augmentation
    conditional on some portion of the data model.

    The following example from [RFC7223] shows how a conditional
    container called "ethernet" is added to the "interface" list only for
    entries of the type "ethernetCsmacd".

         augment "/if:interfaces/if:interface" {
             when "if:type = 'ianaift:ethernetCsmacd'";

             container ethernet {
                 leaf duplex {
                     ...
                 }
             }
         }

5.17.2.  Conditionally Mandatory Data Definition Statements

    YANG has very specific rules about how configuration data can be
    updated in new releases of a module.  These rules allow an "old
    client" to continue interoperating with a "new server".

    If data nodes are added to an existing entry, the old client MUST NOT
    be required to provide any mandatory parameters that were not in the
    original module definition.

    It is possible to add conditional augment statements such that the
    old client would not know about the new condition, and would not
    specify the new condition.  The conditional augment statement can
    contain mandatory objects only if the condition is false unless
    explicitly requested by the client.

    Only a conditional augment statement that uses the "when" statement
    form of condition can be used in this manner.  The YANG features
    enabled on the server cannot be controlled by the client in any way,
    so it is not safe to add mandatory augmenting data nodes based on the
    "if-feature" statement.

    The XPath "when" statement condition MUST NOT reference data outside
    of target data node because the client does not have any control over
    this external data.

    In the following dummy example, it is OK to augment the "interface"
    entry with "mandatory-leaf" because the augmentation depends on
    support for "some-new-iftype".  The old client does not know about
    this type so it would never select this type, and therefore not be
    adding a mandatory data node.

      module my-module {
        ...

        identity some-new-iftype {
           base iana:iana-interface-type;
        }

        augment "/if:interfaces/if:interface" {
           when "if:type = 'mymod:some-new-iftype'";

           leaf mandatory-leaf {
              mandatory true;
              ...
           }
        }
      }

    Note that this practice is safe only for creating data resources.  It
    is not safe for replacing or modifying resources if the client does
    not know about the new condition.  The YANG data model MUST be
    packaged in a way that requires the client to be aware of the
    mandatory data nodes if it is aware of the condition for this data.
    In the example above, the "some-new-iftype" identity is defined in
    the same module as the "mandatory-leaf" data definition statement.

    This practice is not safe for identities defined in a common module
    such as "iana-if-type" because the client is not required to know
    about "my-module" just because it knows about the "iana-if-type"
    module.



Rob


>
> /js
>


From nobody Wed Sep 23 07:19:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243C41A21AF for ; Wed, 23 Sep 2015 07:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXIktglc0VxL for ; Wed, 23 Sep 2015 07:19:09 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5911A1EF5 for ; Wed, 23 Sep 2015 07:19:09 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 14:18:47 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 14:18:48 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
Thread-Index: AQHQ8lzThTAvqjhhWUW821rJF43C855GvL+AgABdlQCAATGCgP//9VcAgABOVICAAV42AA==
Date: Wed, 23 Sep 2015 14:18:47 +0000
Message-ID: 
References:  <55FFCF2F.5010902@cisco.com>  <56011DF7.9020400@cisco.com>  <560156BB.7050804@cisco.com>
In-Reply-To: <560156BB.7050804@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:MnIWxuPnln5smJuZPW6he60CoxfsL5omCjzP+LQvN+PdE2RnwSEF34Fd2thUrsFfYyB1n9wsHmgsKGBkJEhUc6jcv4jzymtjVY0k3GST1r4pa4V38i4RW+qGEUg3lqOisQWgfadgj0c4V0R4EHooig==; 24:LlT+LpJD1HiTM1IAhOzO/7jjxFRSNLyIxB6P5+lS5vlzsrAvu3qDVQ/tHBf3OtjR7emmg9sEqxQiJOIPa7Xxw6SkaiSdrCsPcz+Kx8YBFr0=; 20:DqTBj1NAdH1G3++tqKrrheO1DLmWOVMpyLx3SQ7Bq8fEEzb13xdhyZH7xWV2aS9lvOkFyFwVMw688ZtV0NinHw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(2501003)(76176999)(50986999)(4001540100001)(5002640100001)(97736004)(87936001)(2900100001)(4001350100001)(40100003)(122556002)(5001860100001)(2950100001)(5001770100001)(5001830100001)(101416001)(189998001)(54356999)(68736005)(81156007)(36756003)(5007970100001)(106116001)(77156002)(107886002)(99286002)(106356001)(105586002)(66066001)(102836002)(64706001)(5004730100002)(62966003)(83506001)(92566002)(46102003)(10400500002)(5001960100002)(93886004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <38775A7574B92248B3499819524AECAE@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 14:18:47.9944 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 14:19:13 -0000

>NEW:
>
>   7.  Ability for distinct modules to leverage a common model-structure
>        A.  Focus on the IETF-defined modules, and ideally provides
>guidance to other SDOs
>        B.  Multiple domain-specific trees are okay
>        C.  Model-structures may be defined in multiple modules with
>distinct namespaces.


If no one objects within 5 days, we will move forward with the NEW text
listed above for requirement #7.

Thanks,
Kent


From nobody Wed Sep 23 07:23:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0DC1A21BD for ; Wed, 23 Sep 2015 07:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.061
X-Spam-Level: 
X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nxYQ6b1D0EO for ; Wed, 23 Sep 2015 07:22:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F8E1A21C2 for ; Wed, 23 Sep 2015 07:22:12 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 46540181898; Wed, 23 Sep 2015 16:22:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443018131; bh=udMKDaVm7Hf4DsvkHAm4teF8DCDLlzCg857Ovdknx9o=; h=From:Date:To; b=cmmRj+sOlC0m8jNYDCD3aRd4yYdDG8t+NINDKmbxX3LqNW+8K40aZJ/hHhZImb6Ds ZMBwuxUeBvlbT5eE+/VQxnpH1HmZpjUFLIYCAfq6Zps3m31QJFbUocOy8Q0FDOhmxu vKg7Z9Sm49tXWntWn/KD7o4bm8mgcHKEIL6vpnxw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <5602AB4A.1080606@mg-soft.si>
Date: Wed, 23 Sep 2015 16:22:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0866BAD8-3096-4CCC-86BD-34A2B642F2E2@nic.cz>
References:  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <20150923.130709.926246931083333700.mbj@tail-f.com>  <5602A442.9020205@mg-soft.si> <7968BC66-1BEC-493B-A51B-37BCF20482C9@nic.cz> <5602AB4A.1080606@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 14:23:03 -0000

> On 23 Sep 2015, at 15:38, Jernej Tuljak  wrote:
>=20
> Ladislav Lhotka je 23.9.2015 ob 15:13 napisal:
>>> On 23 Sep 2015, at 15:08, Jernej Tuljak 
>>>  wrote:
>>>=20
>>> Ladislav Lhotka je 23.9.2015 ob 14:21 napisal:
>>>=20
>>>> Martin Bjorklund 
>>>>  writes:
>>>>=20
>>>>=20
>>>>> Ladislav Lhotka 
>>>>>  wrote:
>>>>>=20
>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak 
>>>>>>>  wrote:
>>>>>>>=20
>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>=20
>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak 
>>>>>>>>>  wrote:
>>>>>>>>>=20
>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation =
case
>>>>>>>>> does not consider that an "augment" may specify a top-level =
"choice"
>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the =
target
>>>>>>>>> node. There will be no initial context node for the expression =
in such
>>>>>>>>> a case.
>>>>>>>>>=20
>>>>>>>>>  leaf enable-foos {
>>>>>>>>>    type boolean;
>>>>>>>>>  }
>>>>>>>>>  choice ch1 {
>>>>>>>>>    case foo {
>>>>>>>>>      choice foos {
>>>>>>>>>        when "enable-foos =3D 'true'";
>>>>>>>>>        leaf foo1 {
>>>>>>>>>          type string;
>>>>>>>>>        }
>>>>>>>>>        leaf foo2 {
>>>>>>>>>          type string;
>>>>>>>>>        }
>>>>>>>>>      }
>>>>>>>>>    }
>>>>>>>>>    container meh;
>>>>>>>>>  }
>>>>>>>>>=20
>>>>>>>>>  augment "/ch1/foo/foos" {
>>>>>>>>>    when "enable-foos =3D 'true'";
>>>>>>>>>    leaf foo3 {
>>>>>>>>>      type string;
>>>>>>>>>    }
>>>>>>>>>  }
>>>>>>>>>=20
>>>>>>>>> OLD:
>>>>>>>>>=20
>>>>>>>>>   o  If the "when" statement is a child of an "augment" =
statement, then
>>>>>>>>>      the context node is the augment's target node in the data =
tree, if
>>>>>>>>>      the target node is a data node.  Otherwise, the context =
node is
>>>>>>>>>      the closest ancestor node to the target node that is also =
a data
>>>>>>>>>      node.
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>>=20
>>>>>>>>>   o  If the "when" statement is a child of an "augment" =
statement, then
>>>>>>>>>      the context node is the augment's target node in the data =
tree, if
>>>>>>>>>      the target node is a data node.  Otherwise, the context =
node is
>>>>>>>>>      the closest ancestor node to the target node that is also =
a data
>>>>>>>>>      node. If no such node exists, the context node is the =
root node.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>> Good catch, I support this change.
>>>>>>>>=20
>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when =
expression
>>>>>>>> must not reference nodes that are made conditional through that =
when
>>>>>>>> statement. I can=E2=80=99t find this rule in the text.
>>>>>>>>=20
>>>>>>> The "no referencing the initial context node and its =
descendants" text
>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>>=20
>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>> seriously broken and could lead to deadlocks.
>>>>>>=20
>>>>> This reminds me of Juergen's golden rule: "All implementations of =
this
>>>>> spec MUST be bug-free".  We'd have to say "all XPath expressions =
MUST
>>>>> make sense".
>>>>>=20
>>>> Of course this is very different. An XPath expression that =
doesn=E2=80=99t make
>>>> sense represents no problem whatsoever as long as the result can be
>>>> reliably determined.
>>>>=20
>>>> What we (potentially) have here is this: the server evaluates an
>>>> expression, then changes the datastore schema based on the result,
>>>> deletes some instances from the datastore, but after this the XPath
>>>> expression gives a different result. This IMO indicates that it's
>>>> something rotten with the definition of "when".
>>>>=20
>>>>=20
>>>>> Referencing nodes that don't exist is legal XPath, but it probably
>>>>> does not make much sense.
>>>>>=20
>>>> It's more complicated than this because of other YANG-specific =
rules.
>>>>=20
>>>> container foo {
>>>>   when "not(enabled =3D 'false')";
>>>>   leaf enabled {
>>>>     type boolean;
>>>>     default false;
>>>>   }
>>>> }
>>>>=20
>>>> If there is no "foo" in the datastore, then the procedure from the =
third
>>>> bullet in sec. 7.21.5 leads to the result that the when expression =
is
>>>> true, so "foo" is valid and the default value for "enabled" comes =
into
>>>> play, which however makes the when expression evaluate to false.
>>>>=20
>>> This is not how I read it.
>>>=20
>> Well, I significantly contributed to this formulation. :-)
>>=20
>>=20
>>> 3rd bullet makes your expression _always_ evaluate to the same =
boolean value, since there is no "enabled" child node to "foo" during =
evaluation, ever. It will never be present in the accessible tree, since =
it is pruned away before evaluation (child::enabled always returns an =
empty node-set no matter what is in your datastore).
>>>=20
>> Are you saying that the data tree
>>=20
>> "foo": { "enabled" : false }
>>=20
>> is valid?
>>=20
>=20
> Yes. And so would be:

Yuck! Maybe the third bullet can be interpreted this way but I think it =
is very confusing because sec. 7.21.5 also says:

The node defined by the parent data definition statement is only valid =
when the condition specified by the "when" statement is satisfied.

Note that my argument and example also apply to when appearing on an =
augment, and the third bullet doesn=E2=80=99t cover to this case.

Lada

> "foo": { "enabled" : true }
>=20
> In XPath 1.0 spec language (Section 3.4):
>=20
> If one object to be compared is a node-set and the other is a string, =
then the comparison will be true if and only if there is a node in the =
node-set such that the result of performing the comparison on =
thestring-value of the node and the other string is true
>=20
> meaning that=20
> enabled =3D 'false'
> always evaluates to boolean false, since the node-set will always be =
empty, no matter what you do.
>=20
> =46rom the expression context point of view, your expression could be =
changed to:
> not(enabled1 =3D 'false')
> not(enabled2 =3D 'false')
> not(enabled3 =3D 'false')
> ...
> not(enabledN =3D 'false')
>=20
>=20
> but that would make no difference, since the context node (foo) will =
never have any children. You can no longer reference descendants of the =
context node, nor its value (unless it's the document root) in when =
expressions.
>=20
> If you take the negation away in your example, your instance will =
never be valid, however.
>=20
> Jernej
>=20
>> Lada
>>=20
>>=20
>>> Jernej
>>>=20
>>>=20
>>>> Lada
>>>>=20
>>>>=20
>>>>> /martin
>>>>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Sep 23 08:03:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8C31A6F9A for ; Wed, 23 Sep 2015 08:03: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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEUSNL7VNdla for ; Wed, 23 Sep 2015 08:03:55 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296C11A6F6D for ; Wed, 23 Sep 2015 08:03:54 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 15:03:37 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 15:03:37 +0000
From: Kent Watsen 
To: Ladislav Lhotka 
Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
Thread-Index: AQHQ9dDoRdQSjEGRK0ukRcywpHq1Ip5J6MYA
Date: Wed, 23 Sep 2015 15:03:36 +0000
Message-ID: 
References:  <4DAEFCCA-6BA7-4BD9-B0B8-1867949209CF@nic.cz>
In-Reply-To: <4DAEFCCA-6BA7-4BD9-B0B8-1867949209CF@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:X7/bGv2MZVgsfUCx4ClbEa4xX0S/F10CybJstFUQlrkJYWIlUmWOLqyQVRtInodz2o7wuwbDRSX/xCcsWFLIfkfWlwBpBsGfyZLRrJkv1Dmx3ulmU9+E3rdT2azoezvHHLegXxREPj12Rt9Q88GB7g==; 24:ggiqpI7yum5YJHp0IL7OI2izUaaHIARGn21kInAzF/A/FCCfvuoL+FF0GUQ28g+mKiWj7iioZJcZriQQxLbpfzHtGQYo/43gigLtlPIC4k8=; 20:AjvNkSoEto3suE3lRyi+QMtc0Sn0aHVjg5ohmPM07nLSwbJoaDrUSM0I1Gax+JpuJXlkAa/F0pRnZIvGy0Sf1A==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(24454002)(479174004)(5423002)(377454003)(66066001)(189998001)(5001960100002)(105586002)(106356001)(11100500001)(83506001)(10400500002)(110136002)(5002640100001)(77156002)(62966003)(2950100001)(92566002)(102836002)(64706001)(106116001)(68736005)(99286002)(4001350100001)(122556002)(50986999)(97736004)(19580395003)(86362001)(2900100001)(5001830100001)(5004730100002)(87936001)(19580405001)(46102003)(76176999)(5001860100001)(5007970100001)(81156007)(230783001)(101416001)(4001540100001)(36756003)(40100003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 15:03:36.9190 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 15:03:57 -0000

On 9/23/15, 3:24 AM, "Ladislav Lhotka"  wrote:

>>=20
>>  "I have reviewed I-D XYZ and I found no issues"
>>  "I have implemented the data model in I-D XYZ"
>>  "I am implementing the data model in I-D XYZ"
>>  "I am considering to implement the data model in I-D XYZ=B2
>
>I believe the last three item should be about implementing the encoding
>rather than =B3the data model=B2.


True, this text was just copied/pasted from the previos LC on this draft,
which then was copied/pasted from another LC.  Making these options
specific to this draft:

  "I have reviewed draft-ietf-netmod-yang-json-05 and I found no issues"
  "I have implemented the encoding defined in
draft-ietf-netmod-yang-json-05"
  "I am implementing the encoding defined draft-ietf-netmod-yang-json-05"
  "I am considering to implement the encoding defined in
draft-ietf-netmod-yang-json-05=B2


Of course, these are merely suggestions, folks can provide comments in any
form that suits them.


Thanks,
Kent


From nobody Wed Sep 23 08:04:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2821A6F9A for ; Wed, 23 Sep 2015 08:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7wG6DMm39Bz for ; Wed, 23 Sep 2015 08:04:21 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA271A6F6D for ; Wed, 23 Sep 2015 08:04:21 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 15:03:57 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 15:03:57 +0000
From: Kent Watsen 
To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kA
Date: Wed, 23 Sep 2015 15:03:57 +0000
Message-ID: 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>
In-Reply-To: <56027D26.8020801@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:gVhtKQjeaoxJXr8mJxUfZZS0GqS/rP2vdLpXsIL3T0jqeRR4nzoBZl39ik89X39VNhiAV4F0ZnX7gbHp4koXwJytdNvtZqF6Lvmpj8Rv91MK5V9/izZn6DccZoJ48PdJB0juispTugQtY4Sy7/JitA==; 24:ROLGcb6Tk9jP1KtNp2szu20x49qzhJMBnjVBhibO5yefjSuFUJQ8AKJatcK1CNjfth/LCBQfrbePPOMdf6nG0ADJ7ZVexy38yFwMBH1MX6Y=; 20:dC4lkbDvCWtPMO9cr9Pucpj4sfkpXZsJQM1kWl2nyTbrhpKF7d8gq7Zkaamf+29hEvVMxjyAYdaIbo4hUb3iYA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51444003)(164054003)(66066001)(16236675004)(189998001)(5001960100002)(105586002)(106356001)(107886002)(11100500001)(83506001)(10400500002)(5002640100001)(77156002)(62966003)(2950100001)(92566002)(102836002)(64706001)(106116001)(68736005)(99286002)(4001350100001)(122556002)(50986999)(97736004)(86362001)(2900100001)(5001830100001)(5004730100002)(87936001)(46102003)(2501003)(76176999)(5001860100001)(5001770100001)(5007970100001)(81156007)(93886004)(101416001)(4001540100001)(36756003)(40100003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2282F28E0334kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 15:03:57.4734 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 15:04:23 -0000

--_000_D2282F28E0334kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


> This doesn't seem to be consistent with the rfc6241 section 5.1 that stat=
es:
> "The running configuration datastore holds the complete configuration cur=
rently active on the network device."

Good catch!  RFC 6241 appears to be inaccurate, unless we assume "currently=
 active" means active from the control plane's perspective, but not necessa=
rily operationally active.  Does this require errata?


Popping the stack on this issue, the issue remains as to what to do with re=
quirement 3:

   3.  Support for both transactional, synchronous management systems
        as well as distributed, asynchronous management systems

       A.  For asynchronous systems, the ability to request a protocol
           operation to not return (i.e. block) until the intended
           configuration has been fully synchronized.

       B.  The protocol operation's response would indicate the result
           of the operation (success, failure, partial, etc.)


Again, my position is that sub-requirements A and B are not actual requirem=
ents in the sense that we're being asked to add to NETCONF/RESTCONF (the on=
ly protocols supported currently) an ability to block protocol operations u=
ntil the intended configuration is fully propagated to the operational comp=
onents of a system.  So I think that 3A and 3B should be removed.

But the top-level statement in 3 remains valid, and yet it now seems like a=
 duplicate to the requirement #1.  That is, a synchronous system presumably=
 has no "applied" configuration whereas an asynchronous does.  So it seems =
that satisfying this requirements is one and the same as satisfying the des=
ire for a system to advertise (or not) support for an "applied" configurati=
on.  Agreed?

If this is agreed, then we can close this issue by replacing A and B with a=
 note indicating that requirement #3 is a duplicate of #1.

Thanks,
Kent






--_000_D2282F28E0334kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable














> This doesn't seem to be cons=
istent with the rfc6241 section 5.1 that states:

> "The running configuration datastore holds the complete configura=
tion currently active on the network device."










Good catch!  RFC 6241 appears to be inaccurate, unless we assume "=
;currently active" means active from the control plane's perspective, =
but not necessarily operationally active.  Does this require errata?












Popping the stack on this issue, the issue remains as to what to do with re=
quirement 3:













   3.  Support for bo=
th transactional, synchronous management systems


        as well as distributed, asynchronous management sy=
stems







       A.  =
For asynchronous systems, the ability to request a protocol


          &=
nbsp;operation to not return (i.e. block) until the intended


          &=
nbsp;configuration has been fully synchronized.







       B.  =
The protocol operation's response would indicate the result


          &=
nbsp;of the operation (success, failure, partial, etc.)

















Again, my position is that sub-requirements A and B are not actual requirem=
ents in the sense that we're being asked to add to NETCONF/RESTCONF (the on=
ly protocols supported currently) an ability to block protocol operations u=
ntil the intended configuration
 is fully propagated to the operational components of a system.  So I =
think that 3A and 3B should be removed.









But the top-level statement in 3 remains valid, and yet it now seems like a=
 duplicate to the requirement #1.  That is, a synchronous system presu=
mably has no "applied" configuration whereas an asynchronous does=
.  So it seems that satisfying this requirements
 is one and the same as satisfying the desire for a system to advertise (or=
 not) support for an "applied" configuration.  Agreed?









If this is agreed, then we can close this issue by replacing A and B with a=
 note indicating that requirement #3 is a duplicate of #1.













Thanks,



Kent


































--_000_D2282F28E0334kwatsenjunipernet_--


From nobody Wed Sep 23 08:13:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F501A6FBB for ; Wed, 23 Sep 2015 08:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRvCgkDTCGu6 for ; Wed, 23 Sep 2015 08:13: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 2058B1A6F83 for ; Wed, 23 Sep 2015 08:13:04 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 58E5D1AE0489; Wed, 23 Sep 2015 17:13:02 +0200 (CEST)
Date: Wed, 23 Sep 2015 17:13:53 +0200 (CEST)
Message-Id: <20150923.171353.1848736574597749201.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: 
References:  <56027D26.8020801@cisco.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: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 15:13:05 -0000

Kent Watsen  wrote:
> 
> > This doesn't seem to be consistent with the rfc6241 section 5.1 that
> > states:
> > "The running configuration datastore holds the complete configuration
> > currently active on the network device."
> 
> Good catch!  RFC 6241 appears to be inaccurate, unless we assume
> "currently active" means active from the control plane's perspective,
> but not necessarily operationally active.  Does this require errata?

I think the term "active configuration" can be interpreted to mean
"intended configuration".  I don't think we should file an errata at
this point, and in any case we should wait until we have a (published)
definition of the term.

> Popping the stack on this issue, the issue remains as to what to do
> with requirement 3:
> 
>    3.  Support for both transactional, synchronous management systems
>         as well as distributed, asynchronous management systems
> 
>        A.  For asynchronous systems, the ability to request a protocol
>            operation to not return (i.e. block) until the intended
>            configuration has been fully synchronized.
> 
>        B.  The protocol operation's response would indicate the result
>            of the operation (success, failure, partial, etc.)
> 
> 
> Again, my position is that sub-requirements A and B are not actual
> requirements in the sense that we're being asked to add to
> NETCONF/RESTCONF (the only protocols supported currently) an ability
> to block protocol operations until the intended configuration is fully
> propagated to the operational components of a system.  So I think that
> 3A and 3B should be removed.

+1


/martin


From nobody Wed Sep 23 08:25:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA0C1A7008 for ; Wed, 23 Sep 2015 08:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znwMvogwC67D for ; Wed, 23 Sep 2015 08:25:27 -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 C500C1A7002 for ; Wed, 23 Sep 2015 08:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11518; q=dns/txt; s=iport; t=1443021925; x=1444231525; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=NoTTiUFmu2kMKBSD2QwnSVRukCnwI6X05LB7n0YnJLQ=; b=M/nDjrwfyu6UuGrBj2Sw7hznHfqTYw/aiiX1/3EQ6wr3JGpFQ0Yh0pAh arV7sSNpJ3MHzjQVxJt4c6F4Msc5eojvdxfq3qqSlcIj4JLaXiMlZFNNw 7UFp+dQoSTizY4NAX6TACcE8tJqtdufVaQUtodKMu2x8rENNlxcj2Lr9V g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcBADhwwJW/xbLJq1dglfFCIJWAoITAQEBAQEBgQuEJAEBAQMBeAYLCw4KCRYECwkDAgECAUUGAQwIAQGIIgjLUAEBAQEBAQEDAQEBAQEBAQEBGYZzhH2FFIQsBZI+gymNC4FPhzSJa4g8Y4JDgT89iiABAQE
X-IronPort-AV: E=Sophos;i="5.17,578,1437436800";  d="scan'208,217";a="605310051"
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; 23 Sep 2015 15:25:23 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8NFPNBm019150; Wed, 23 Sep 2015 15:25:23 GMT
To: Kent Watsen , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com> 
From: Robert Wilton 
Message-ID: <5602C464.8070205@cisco.com>
Date: Wed, 23 Sep 2015 16:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020808030009010801010304"
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 15:25:28 -0000

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



On 23/09/2015 16:03, Kent Watsen wrote:
>
> > This doesn't seem to be consistent with the rfc6241 section 5.1 that states:
> > "The running configuration datastore holds the complete 
> configuration currently active on the network device."
>
> Good catch!  RFC 6241 appears to be inaccurate, unless we assume 
> "currently active" means active from the control plane's perspective, 
> but not necessarily operationally active.
That is what I would normally expect the running the configuration to mean.

>  Does this require errata?
>
>
> Popping the stack on this issue, the issue remains as to what to do 
> with requirement 3:
>
>    3.  Support for both transactional, synchronous management systems
> as well as distributed, asynchronous management systems
>
>        A.  For asynchronous systems, the ability to request a protocol
>            operation to not return (i.e. block) until the intended
>            configuration has been fully synchronized.
>
>        B.  The protocol operation's response would indicate the result
>            of the operation (success, failure, partial, etc.)
>
>
> Again, my position is that sub-requirements A and B are not actual 
> requirements in the sense that we're being asked to add to 
> NETCONF/RESTCONF (the only protocols supported currently) an ability 
> to block protocol operations until the intended configuration is fully 
> propagated to the operational components of a system.
I don't think that this is what it asking for, but I'm not sure that it 
matters.


>  So I think that 3A and 3B should be removed.
I agree.

>
> But the top-level statement in 3 remains valid, and yet it now seems 
> like a duplicate to the requirement #1.  That is, a synchronous system 
> presumably has no "applied" configuration whereas an asynchronous 
> does.  So it seems that satisfying this requirements is one and the 
> same as satisfying the desire for a system to advertise (or not) 
> support for an "applied" configuration.  Agreed?
Not quite.


E.g. I think that for compatibility a system could still advertise 
support for "applied" configuration even through its configuration 
processing is "synchronous" and hence applied config would always match 
intended config.

Hence I still question whether there is a need for the system to 
advertise that it performs "asynchronous" configuration processing, 
which is different from the requirement to support applied configuration 
above.  I.e. does the client need to know that config edit operations 
will return before the configuration is applied to running config.  It 
may be that we need to get to the bottom of the definition of "intended 
vs applied vs currently active" cfg before this can be sensibly answered.

Rob

>
> If this is agreed, then we can close this issue by replacing A and B 
> with a note indicating that requirement #3 is a duplicate of #1.
>
> Thanks,
> Kent
>
>
>
>
>


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


  
    
  
  
    

    

    
On 23/09/2015 16:03, Kent Watsen wrote:

    

    

      
      

        

      

      
        
> This doesn't seem to
          be consistent with the rfc6241 section 5.1 that states:

          > "The running configuration datastore holds the complete
          configuration currently active on the network device."

      
      

        

      

      

        Good catch! RFC 6241 appears to be inaccurate, unless we assume
        "currently active" means active from the control plane's
        perspective, but not necessarily operationally active.

    

    That is what I would normally expect the running the configuration
    to mean.

    

    

      
 Does this require errata?

      

        

      

      
        

          


            Popping the stack on this issue, the issue remains as to
            what to do with requirement 3:

        

      
      

        

      

      

        
 3. Support for both
            transactional, synchronous management systems

        
   aswell as
            distributed, asynchronous management systems

        


          

        
   A. For asynchronous
            systems, the ability to request a protocol

        
     operation to not
            return (i.e. block) until the intended

        
     configuration
            has been fully synchronized.

        


          

        
   B. The protocol
            operation's response would indicate the result

        
     of the operation
            (success, failure, partial, etc.)

      

      

        

      

      

        

      

      

        Again, my position is that sub-requirements A and B are not
        actual requirements in the sense that we're being asked to add
        to NETCONF/RESTCONF (the only protocols supported currently) an
        ability to block protocol operations until the intended
        configuration is fully propagated to the operational components
        of a system.

    

    I don't think that this is what it asking for, but I'm not sure that
    it matters.

    

    

    

      
 So I think that 3A and 3B should be removed.

    

    I agree.

    

    

      

        

      

      

        But the top-level statement in 3 remains valid, and yet it now
        seems like a duplicate to the requirement #1. That is, a
        synchronous system presumably has no "applied" configuration
        whereas an asynchronous does. So it seems that satisfying this
        requirements is one and the same as satisfying the desire for a
        system to advertise (or not) support for an "applied"
        configuration. Agreed?

    

    Not quite.

    

    

    E.g. I think that for compatibility a system could still advertise
    support for "applied" configuration even through its configuration
    processing is "synchronous" and hence applied config would always
    match intended config.

    

    Hence I still question whether there is a need for the system to
    advertise that it performs "asynchronous" configuration processing,
    which is different from the requirement to support applied
    configuration above. I.e. does the client need to know that config
    edit operations will return before the configuration is applied to
    running config. It may be that we need to get to the bottom of the
    definition of "intended vs applied vs currently active" cfg before
    this can be sensibly answered.

    

    Rob

    

    

      

        

      

      

        If this is agreed, then we can close this issue by replacing A
        and B with a note indicating that requirement #3 is a duplicate
        of #1.

    

    

      

        

          

        

      

      

        Thanks,

      

        Kent

      

        

      

      

        

      

      

        

      

      

        

      

      

        

      

    

    

  


--------------020808030009010801010304--


From nobody Wed Sep 23 09:13:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9B01A8763 for ; Wed, 23 Sep 2015 09:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo9my2HUtMLL for ; Wed, 23 Sep 2015 09:12:58 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBA71A8739 for ; Wed, 23 Sep 2015 09:12:58 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 16:12:57 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 16:12:56 +0000
From: Kent Watsen 
To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
Thread-Index: AQHQ9T+RQ8yGc7JN/0i9oUnVbQsvDp5ImdcAgAAc8CeAAAPdAIAACyiAgAAR+4CAARDuAIAAC6kAgABJRQD//8o3AA==
Date: Wed, 23 Sep 2015 16:12:56 +0000
Message-ID: 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com>  <5602C464.8070205@cisco.com>
In-Reply-To: <5602C464.8070205@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:spdUndJIJxX0X0AGFnYAylQ8PJgzGajF1ZlhOlZJp/IUAq1afqy3Ono+hhRMKPBqn0dkqizoQGaKWxC+Q+f6u7a6AXRt5oXOuiHbNvb7V4ToQAZ8J4U7IkmL55nM+sNTRK+o0+2ujBlRYXP5lVE8uQ==; 24:8gT0HRHIPpSpE6fkvGoUCMfy6uKEG9R6sk7XdGxcT2Ycqz/emaB6we+U1CobJE/RR14fb9t9PuJ2gBHaYKdQ2v2pFYCI7uVHrAIQvcGfZf0=; 20:Um39wCAauMqUeL5sfizHQMhD7Ex88DDu0Dqle8GIs9p0AIBG4MgdiPGxxpsVZ42Nzmxye4aCtoTl5M63LPcJlQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51444003)(164054003)(81156007)(5001960100002)(92566002)(2950100001)(107886002)(40100003)(122556002)(83506001)(16236675004)(102836002)(50986999)(86362001)(189998001)(101416001)(2900100001)(5002640100001)(76176999)(54356999)(87936001)(106356001)(68736005)(561944003)(106116001)(105586002)(4001350100001)(62966003)(5004730100002)(46102003)(5001830100001)(5001860100001)(99286002)(36756003)(4001540100001)(10400500002)(97736004)(2501003)(5001770100001)(66066001)(5007970100001)(64706001)(93886004)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2283EA8E03F0kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 16:12:56.7154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 16:13:05 -0000

--_000_D2283EA8E03F0kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


> Not quite.
>
> E.g. I think that for compatibility a system could still advertise
> support for "applied" configuration even through its configuration
> processing is "synchronous" and hence applied config would always
> match intended config.

OK, I can see this perspective.   For now I've updated #3 with a proposal t=
o remove A & B, with a remaining open issue is top-level requirement #3 is =
still needed.


> Hence I still question whether there is a need for the system to
> advertise that it performs "asynchronous" configuration processing,
> which is different from the requirement to support applied
> configuration above.  I.e. does the client need to know that config
> edit operations will return before the configuration is applied to
> running config.  It may be that we need to get to the bottom of the
> definition of "intended vs applied vs currently active" cfg before this
> can be sensibly answered.

Yes, and this is exactly what issue #6 is about:

  #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and =
applied)

Let me start a thread on that now.


Thanks,
Kent


--_000_D2283EA8E03F0kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <8E6280A70C48104ABB198EE875A3CACA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














> Not quite.





> 

> E.g. I think that for compatibility a system could still advertise





> support for "applied" configuration even through its configu=
ration



> processing is "synchronous" and hence applied config would a=
lways



> match intended config.











OK, I can see this perspective. &=
nbsp; For now I've updated #3 with a proposal to remove A & B, with a r=
emaining open issue is top-level requirement #3 is still needed.
















> Hence I still question whether there is a need for the system to 





> advertise that it performs "asynchronous" configuration proc=
essing,



> which is different from the requirement to support applied



> configuration above.  I.e. does the client need to know that conf=
ig



> edit operations will return before the configuration is applied to


> running config.  It may be that we need to get to the bottom of t=
he



> definition of "intended vs applied vs currently active" cfg =
before this



> can be sensibly answered.














Yes, and this is exactly what issue #6 is about:










  #6: clarify impact of synchro=
nous vs asynchronous (esp. wrt intended and applied)











Let me start a thread on that now.

















Thanks,






Kent










--_000_D2283EA8E03F0kwatsenjunipernet_--


From nobody Wed Sep 23 09:15:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002A1A8739 for ; Wed, 23 Sep 2015 09:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yazFwpDmjIB0 for ; Wed, 23 Sep 2015 09:15:44 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.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 210891A8842 for ; Wed, 23 Sep 2015 09:15:43 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 16:15:41 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.107]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 16:15:41 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwSw==
Date: Wed, 23 Sep 2015 16:15:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:znlR1Z8b/vZ0n+cKj6DInVXvAv7wHVYNwPS8eoVNK1Eja4nKpKK/CO3OaVZOPQg2Ko63Rx65gDVsjF42HV3omtGe+VzIWAm7ZLW7yNS77x1Q/s8m6pjgB+p8GOYERN70sovdU6QqfVZgpxNb78vg/g==; 24:TxVuPct4IHeDB27p2HwZzjP0sYe712xWrob/JoIu3HnLL7T9G/NKZcUxIo8EMCdJeiIZjBlvUXaJEQkEI/18MWr0JqK0oVeFs2v8chJrv2o=; 20:BQgIbt4y422H+uQloS47KAMoxQnEsnKGhhyDe19RXJhpm1x4bi2E81HMiXHP/UV6sVyu1zQqzr2VqX/29EIVQg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(81156007)(5001960100002)(92566002)(11100500001)(107886002)(40100003)(122556002)(83506001)(110136002)(16236675004)(102836002)(50986999)(86362001)(189998001)(2351001)(101416001)(2900100001)(5002640100001)(229853001)(54356999)(87936001)(106356001)(68736005)(106116001)(105586002)(4001350100001)(62966003)(5004730100002)(46102003)(5001830100001)(5001860100001)(99286002)(36756003)(450100001)(4001540100001)(10400500002)(97736004)(2501003)(66066001)(5007970100001)(64706001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D228486BE047Ckwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 16:15:41.0416 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Sep 2015 16:15:47 -0000

--_000_D228486BE047Ckwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Jonathan Hansford writes: The requirements talk about both synchronous and =
asynchronous systems (1(D), 3, 3(A)) but really only address the behaviour =
for asynchronous systems. Would it not be worth clarifying the relationship=
 between the intended and applied configurations for synchronous systems (i=
.e. they are the same), hence there is no need for synchronous requirements=
 equivalent to 1(D) and 3(A)?

Ultimately, I think we need normative text in the "Terminology Section" for=
 a "synchronous system" and "asynchronous system".  Would someone care to t=
ake a stab providing these two definitions?


PS: please Reply-All to this thread, rather than post comments on the GitHu=
b issue tracker.

Thanks,
Kent


--_000_D228486BE047Ckwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <216F825831D3DB4EB2C2B8EB5F5AA97E@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable















Jonathan Hansford writes: The requir=
ements talk about both synchronous and asynchronous systems (1(D), 3, 3(A))=
 but really only address the behaviour for asynchronous systems. Would it n=
ot be worth clarifying the relationship
 between the intended and applied configurations for synchronous systems (i=
.e. they are the same), hence there is no need for synchronous requirements=
 equivalent to 1(D) and 3(A)?







Ultimately, I think we need normative text in the "Terminology Se=
ction" for a "synchronous system" and "asynchronous sys=
tem".  Would someone care to take a stab providing these two defi=
nitions?
















PS: please Reply-All to this thread,=
 rather than post comments on the GitHub issue tracker.











Thanks,



Kent










--_000_D228486BE047Ckwatsenjunipernet_--


From nobody Thu Sep 24 02:00:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51D11A87EC for ; Thu, 24 Sep 2015 02:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level: 
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe46DLRGACeC for ; Thu, 24 Sep 2015 02:00:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D9B1A87E8 for ; Thu, 24 Sep 2015 02:00:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBR09134; Thu, 24 Sep 2015 09:00:45 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Sep 2015 10:00:43 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Thu, 24 Sep 2015 17:00:37 +0800
From: Qin Wu 
To: Robert Wilton , Ladislav Lhotka , "netmod@ietf.org" , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: [netmod] Y26 again, sorry
Thread-Index: AQHQ7C/iIzxeOoD3bkuuCnmT+hgLIZ47kC8AgAEqlQCACXUuAIADf0gAgAHF05A=
Date: Thu, 24 Sep 2015 09:00:37 +0000
Message-ID: 
References: <29019400.1441934361017.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20150914141206.GD67363@elstar.local>  <20150921082628.GA11184@elstar.local> <5602AE3A.9020902@cisco.com>
In-Reply-To: <5602AE3A.9020902@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.180]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Y26 again, sorry
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 09:00:56 -0000

SSBzZWUgaXQgaXMgdXNlZnVsIHRvIHJlbGF4IHRoZSByZXN0cmljdGlvbiBvbiBtYW5kYXRvcnkg
YXVnbWVudCBnaXZlbiBzZXZlcmFsIHVzZSBjYXNlcyB0aGF0IGhhdmUgYmVlbiBkaXNjdXNzZWQg
b24gdGhlIGxpc3QuDQpUaGUgcHJvcG9zZWQgY2hhbmdlcyBnZXQgaW4gbGluZSB3aXRoIGRyYWZ0
LWlldGYtbmV0bW9kLXJmYzYwODdiaXMtMDQgYW5kIGxvb2sgZ29vZCB0byBtZS4NCg0KLVFpbg0K
LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnXSC0+rHtIFJvYmVydCBXaWx0b24NCreiy83KsbzkOiAyMDE1xOo51MIyM8jVIDIx
OjUxDQrK1bz+yMs6IExhZGlzbGF2IExob3RrYTsgbmV0bW9kQGlldGYub3JnOyBqLnNjaG9lbndh
ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUNCtb3zOI6IFJlOiBbbmV0bW9kXSBZMjYgYWdhaW4s
IHNvcnJ5DQoNCkhpIEp1ZXJnZW4sDQoNCk9uIDIxLzA5LzIwMTUgMDk6MjYsIEp1ZXJnZW4gU2No
b2Vud2FlbGRlciB3cm90ZToNCj4gT24gVHVlLCBTZXAgMTUsIDIwMTUgYXQgMTA6MDA6NDZBTSAr
MDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq
LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyaXRlczoNCj4+DQo+IFN0aWxs
IHNvbWUgdGV4dCBuZWVkcyB0byBiZSB3cml0dGVuIGV4cGxhaW5pbmcgdGhhdCBicmVha2luZyBv
bGQgDQo+IGNsaWVudHMgYnkgYWRkaW5nIG5ldyBtYW5kYXRvcnkgbm9kZXMgaXMgYSBubyBnby4g
SSBkaWQgbm90IGFzayB0byANCj4gZW51bWVyYXRlIGFsbCBzaXR1YXRpb25zIHdoZXJlIGl0IGlz
IGFsbG93ZWQsIEkgYW0gbG9va2luZyBmb3IgdGV4dCANCj4gdGhhdCBjbGVhcmx5IHNheXMgd2hh
dCBwZW9wbGUgaGF2ZSB0byBsb29rIG91dCBmb3IgaWYgdGhleSBhZGQgDQo+IG1hbmRhdG9yeSBu
b2Rlcy4NCldvdWxkIGl0IGJlIHN1ZmZpY2llbnQgdG8ganVzdCBjaGFuZ2UgdGhlIE1VU1QgTk9U
IHRvIFNIT1VMRCBOT1QgYW5kIHRoZW4gcmVmZXJlbmNlIHNlY3Rpb24gNS4xNy4yIG9mIGRyYWZ0
LWlldGYtbmV0bW9kLXJmYzYwODdiaXMgd2hpY2ggc2VlbXMgdG8gcHJvdmlkZSB0aGUgZXhwbGFu
YXRpb24gdGhhdCB5b3UgYXJlIHJlcXVlc3Rpbmc/DQoNCkUuZy4gc29tZXRoaW5nIGxpa2U6DQoN
CmRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwMjBiaXMsIHNlY3Rpb24gNy4xNy4gIFRoZSBhdWdtZW50
IFN0YXRlbWVudA0KDQpGcm9tOg0KDQpJZiB0aGUgdGFyZ2V0IG5vZGUgaXMgaW4gYW5vdGhlciBt
b2R1bGUsIHRoZW4gbm9kZXMgYWRkZWQgYnkgdGhlIGF1Z21lbnRhdGlvbiBNVVNUIE5PVCBiZSBt
YW5kYXRvcnkgbm9kZXMgKHNlZSBTZWN0aW9uIDMuMSkuDQoNClRvOg0KDQpJZiB0aGUgdGFyZ2V0
IG5vZGUgaXMgaW4gYW5vdGhlciBtb2R1bGUsIHRoZW4gbm9kZXMgYWRkZWQgYnkgdGhlIGF1Z21l
bnRhdGlvbiBTSE9VTEQgTk9UIGJlIG1hbmRhdG9yeSBub2RlcyAoc2VlIFNlY3Rpb24gMy4xKS4g
IFRoZSBzYWZlIHNjZW5hcmlvcyB0byBhdWdtZW50IHdpdGggbWFuZGF0b3J5IG5vZGVzIGFyZSBk
ZXNjcmliZWQgaW4gW2RyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXNdIHNlY3Rpb24gNS4xNy4y
Lg0KDQoNCkZvciByZWZlcmVuY2UsIEkndmUgYWxzbyByZXByb2R1Y2VkIHRoZSB0ZXh0IGZvciBk
cmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTA0XSBzZWN0aW9uIDUuMTcuMiBiZWxvdzoNCg0K
NS4xNy4gIEF1Z21lbnQgU3RhdGVtZW50cw0KDQogICAgVGhlIFlBTkcgImF1Z21lbnQiIHN0YXRl
bWVudCBpcyB1c2VkIHRvIGRlZmluZSBhIHNldCBvZiBkYXRhDQogICAgZGVmaW5pdGlvbiBzdGF0
ZW1lbnRzIHRoYXQgd2lsbCBiZSBhZGRlZCBhcyBjaGlsZCBub2RlcyBvZiBhIHRhcmdldA0KICAg
IGRhdGEgbm9kZS4gIFRoZSBtb2R1bGUgbmFtZXNwYWNlIGZvciB0aGVzZSBkYXRhIG5vZGVzIHdp
bGwgYmUgdGhlDQogICAgYXVnbWVudGluZyBtb2R1bGUsIG5vdCB0aGUgYXVnbWVudGVkIG1vZHVs
ZS4NCg0KICAgIEEgdG9wLWxldmVsICJhdWdtZW50IiBzdGF0ZW1lbnQgU0hPVUxEIE5PVCBiZSB1
c2VkIGlmIHRoZSB0YXJnZXQgZGF0YQ0KICAgIG5vZGUgaXMgaW4gdGhlIHNhbWUgbW9kdWxlIG9y
IHN1Ym1vZHVsZSBhcyB0aGUgZXZhbHVhdGVkICJhdWdtZW50Ig0KICAgIHN0YXRlbWVudC4gIFRo
ZSBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50cyBTSE9VTEQgYmUgYWRkZWQgaW5saW5lDQogICAg
aW5zdGVhZC4NCg0KNS4xNy4xLiAgQ29uZGl0aW9uYWwgQXVnbWVudCBTdGF0ZW1lbnRzDQoNCiAg
ICBUaGUgImF1Z21lbnQiIHN0YXRlbWVudCBpcyBvZnRlbiB1c2VkIHRvZ2V0aGVyIHdpdGggdGhl
ICJ3aGVuIg0KICAgIHN0YXRlbWVudCBhbmQvb3IgImlmLWZlYXR1cmUiIHN0YXRlbWVudCB0byBt
YWtlIHRoZSBhdWdtZW50YXRpb24NCiAgICBjb25kaXRpb25hbCBvbiBzb21lIHBvcnRpb24gb2Yg
dGhlIGRhdGEgbW9kZWwuDQoNCiAgICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgZnJvbSBbUkZDNzIy
M10gc2hvd3MgaG93IGEgY29uZGl0aW9uYWwNCiAgICBjb250YWluZXIgY2FsbGVkICJldGhlcm5l
dCIgaXMgYWRkZWQgdG8gdGhlICJpbnRlcmZhY2UiIGxpc3Qgb25seSBmb3INCiAgICBlbnRyaWVz
IG9mIHRoZSB0eXBlICJldGhlcm5ldENzbWFjZCIuDQoNCiAgICAgICAgIGF1Z21lbnQgIi9pZjpp
bnRlcmZhY2VzL2lmOmludGVyZmFjZSIgew0KICAgICAgICAgICAgIHdoZW4gImlmOnR5cGUgPSAn
aWFuYWlmdDpldGhlcm5ldENzbWFjZCciOw0KDQogICAgICAgICAgICAgY29udGFpbmVyIGV0aGVy
bmV0IHsNCiAgICAgICAgICAgICAgICAgbGVhZiBkdXBsZXggew0KICAgICAgICAgICAgICAgICAg
ICAgLi4uDQogICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICB9DQogICAgICAgICB9DQoN
CjUuMTcuMi4gIENvbmRpdGlvbmFsbHkgTWFuZGF0b3J5IERhdGEgRGVmaW5pdGlvbiBTdGF0ZW1l
bnRzDQoNCiAgICBZQU5HIGhhcyB2ZXJ5IHNwZWNpZmljIHJ1bGVzIGFib3V0IGhvdyBjb25maWd1
cmF0aW9uIGRhdGEgY2FuIGJlDQogICAgdXBkYXRlZCBpbiBuZXcgcmVsZWFzZXMgb2YgYSBtb2R1
bGUuICBUaGVzZSBydWxlcyBhbGxvdyBhbiAib2xkDQogICAgY2xpZW50IiB0byBjb250aW51ZSBp
bnRlcm9wZXJhdGluZyB3aXRoIGEgIm5ldyBzZXJ2ZXIiLg0KDQogICAgSWYgZGF0YSBub2RlcyBh
cmUgYWRkZWQgdG8gYW4gZXhpc3RpbmcgZW50cnksIHRoZSBvbGQgY2xpZW50IE1VU1QgTk9UDQog
ICAgYmUgcmVxdWlyZWQgdG8gcHJvdmlkZSBhbnkgbWFuZGF0b3J5IHBhcmFtZXRlcnMgdGhhdCB3
ZXJlIG5vdCBpbiB0aGUNCiAgICBvcmlnaW5hbCBtb2R1bGUgZGVmaW5pdGlvbi4NCg0KICAgIEl0
IGlzIHBvc3NpYmxlIHRvIGFkZCBjb25kaXRpb25hbCBhdWdtZW50IHN0YXRlbWVudHMgc3VjaCB0
aGF0IHRoZQ0KICAgIG9sZCBjbGllbnQgd291bGQgbm90IGtub3cgYWJvdXQgdGhlIG5ldyBjb25k
aXRpb24sIGFuZCB3b3VsZCBub3QNCiAgICBzcGVjaWZ5IHRoZSBuZXcgY29uZGl0aW9uLiAgVGhl
IGNvbmRpdGlvbmFsIGF1Z21lbnQgc3RhdGVtZW50IGNhbg0KICAgIGNvbnRhaW4gbWFuZGF0b3J5
IG9iamVjdHMgb25seSBpZiB0aGUgY29uZGl0aW9uIGlzIGZhbHNlIHVubGVzcw0KICAgIGV4cGxp
Y2l0bHkgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQuDQoNCiAgICBPbmx5IGEgY29uZGl0aW9uYWwg
YXVnbWVudCBzdGF0ZW1lbnQgdGhhdCB1c2VzIHRoZSAid2hlbiIgc3RhdGVtZW50DQogICAgZm9y
bSBvZiBjb25kaXRpb24gY2FuIGJlIHVzZWQgaW4gdGhpcyBtYW5uZXIuICBUaGUgWUFORyBmZWF0
dXJlcw0KICAgIGVuYWJsZWQgb24gdGhlIHNlcnZlciBjYW5ub3QgYmUgY29udHJvbGxlZCBieSB0
aGUgY2xpZW50IGluIGFueSB3YXksDQogICAgc28gaXQgaXMgbm90IHNhZmUgdG8gYWRkIG1hbmRh
dG9yeSBhdWdtZW50aW5nIGRhdGEgbm9kZXMgYmFzZWQgb24gdGhlDQogICAgImlmLWZlYXR1cmUi
IHN0YXRlbWVudC4NCg0KICAgIFRoZSBYUGF0aCAid2hlbiIgc3RhdGVtZW50IGNvbmRpdGlvbiBN
VVNUIE5PVCByZWZlcmVuY2UgZGF0YSBvdXRzaWRlDQogICAgb2YgdGFyZ2V0IGRhdGEgbm9kZSBi
ZWNhdXNlIHRoZSBjbGllbnQgZG9lcyBub3QgaGF2ZSBhbnkgY29udHJvbCBvdmVyDQogICAgdGhp
cyBleHRlcm5hbCBkYXRhLg0KDQogICAgSW4gdGhlIGZvbGxvd2luZyBkdW1teSBleGFtcGxlLCBp
dCBpcyBPSyB0byBhdWdtZW50IHRoZSAiaW50ZXJmYWNlIg0KICAgIGVudHJ5IHdpdGggIm1hbmRh
dG9yeS1sZWFmIiBiZWNhdXNlIHRoZSBhdWdtZW50YXRpb24gZGVwZW5kcyBvbg0KICAgIHN1cHBv
cnQgZm9yICJzb21lLW5ldy1pZnR5cGUiLiAgVGhlIG9sZCBjbGllbnQgZG9lcyBub3Qga25vdyBh
Ym91dA0KICAgIHRoaXMgdHlwZSBzbyBpdCB3b3VsZCBuZXZlciBzZWxlY3QgdGhpcyB0eXBlLCBh
bmQgdGhlcmVmb3JlIG5vdCBiZQ0KICAgIGFkZGluZyBhIG1hbmRhdG9yeSBkYXRhIG5vZGUuDQoN
CiAgICAgIG1vZHVsZSBteS1tb2R1bGUgew0KICAgICAgICAuLi4NCg0KICAgICAgICBpZGVudGl0
eSBzb21lLW5ldy1pZnR5cGUgew0KICAgICAgICAgICBiYXNlIGlhbmE6aWFuYS1pbnRlcmZhY2Ut
dHlwZTsNCiAgICAgICAgfQ0KDQogICAgICAgIGF1Z21lbnQgIi9pZjppbnRlcmZhY2VzL2lmOmlu
dGVyZmFjZSIgew0KICAgICAgICAgICB3aGVuICJpZjp0eXBlID0gJ215bW9kOnNvbWUtbmV3LWlm
dHlwZSciOw0KDQogICAgICAgICAgIGxlYWYgbWFuZGF0b3J5LWxlYWYgew0KICAgICAgICAgICAg
ICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICAgICAgICAgICAgLi4uDQogICAgICAgICAgIH0NCiAgICAg
ICAgfQ0KICAgICAgfQ0KDQogICAgTm90ZSB0aGF0IHRoaXMgcHJhY3RpY2UgaXMgc2FmZSBvbmx5
IGZvciBjcmVhdGluZyBkYXRhIHJlc291cmNlcy4gIEl0DQogICAgaXMgbm90IHNhZmUgZm9yIHJl
cGxhY2luZyBvciBtb2RpZnlpbmcgcmVzb3VyY2VzIGlmIHRoZSBjbGllbnQgZG9lcw0KICAgIG5v
dCBrbm93IGFib3V0IHRoZSBuZXcgY29uZGl0aW9uLiAgVGhlIFlBTkcgZGF0YSBtb2RlbCBNVVNU
IGJlDQogICAgcGFja2FnZWQgaW4gYSB3YXkgdGhhdCByZXF1aXJlcyB0aGUgY2xpZW50IHRvIGJl
IGF3YXJlIG9mIHRoZQ0KICAgIG1hbmRhdG9yeSBkYXRhIG5vZGVzIGlmIGl0IGlzIGF3YXJlIG9m
IHRoZSBjb25kaXRpb24gZm9yIHRoaXMgZGF0YS4NCiAgICBJbiB0aGUgZXhhbXBsZSBhYm92ZSwg
dGhlICJzb21lLW5ldy1pZnR5cGUiIGlkZW50aXR5IGlzIGRlZmluZWQgaW4NCiAgICB0aGUgc2Ft
ZSBtb2R1bGUgYXMgdGhlICJtYW5kYXRvcnktbGVhZiIgZGF0YSBkZWZpbml0aW9uIHN0YXRlbWVu
dC4NCg0KICAgIFRoaXMgcHJhY3RpY2UgaXMgbm90IHNhZmUgZm9yIGlkZW50aXRpZXMgZGVmaW5l
ZCBpbiBhIGNvbW1vbiBtb2R1bGUNCiAgICBzdWNoIGFzICJpYW5hLWlmLXR5cGUiIGJlY2F1c2Ug
dGhlIGNsaWVudCBpcyBub3QgcmVxdWlyZWQgdG8ga25vdw0KICAgIGFib3V0ICJteS1tb2R1bGUi
IGp1c3QgYmVjYXVzZSBpdCBrbm93cyBhYm91dCB0aGUgImlhbmEtaWYtdHlwZSINCiAgICBtb2R1
bGUuDQoNCg0KDQpSb2INCg0KDQo+DQo+IC9qcw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll
dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Thu Sep 24 02:08:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF8B1A8890 for ; Thu, 24 Sep 2015 02:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt7XNAfK5IN9 for ; Thu, 24 Sep 2015 02:08:39 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E871A8896 for ; Thu, 24 Sep 2015 02:08:38 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-b5-5603bd94e681
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.92.17026.49DB3065; Thu, 24 Sep 2015 11:08:37 +0200 (CEST)
Received: from [159.107.197.197] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Thu, 24 Sep 2015 11:08:36 +0200
To: Martin Bjorklund , "netmod@ietf.org" 
References: <56029C96.30408@ericsson.com> <20150923.193450.891946329598810280.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <5603BD94.6000700@ericsson.com>
Date: Thu, 24 Sep 2015 11:08:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150923.193450.891946329598810280.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje7UvcxhBk++sll0dz9jt5h/sZHV gcljyZKfTB4bfy1mCWCK4rJJSc3JLEst0rdL4MpovnuJuaCbr+JaawtTA+NFri5GDg4JAROJ 0z+Kuhg5gUwxiQv31rN1MXJxCAkcZZQ4+uMKE4SzllHi+ObT7CBVwgIaEjs+7WMCsUUEvCQ6 719gBLGFBOIllrb9B7PZBIwkpvafZwGxeQW0JSade88GYrMIqEp0nLkLViMqECPR82sDG0SN oMTJmU/A6jkFHCQm/Z/GAnIcs4C9xIOtZSBhZgF5ie1v5zBDrNKQeHjhL+sERoFZSLpnIXTM QtKxgJF5FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgSB7c8lt3B+Pq146HGAU4GJV4eBUi mcOEWBPLiitzDzFKc7AoifO2MD0IFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBou2FP52uu 9XunXxNXcNL+OiN2e+V0zm+vvItqfkUHVYpXGMXL8R96xr+N9bCASuylC7feB8x4s+nFb63t H8u0Lx/pWRetdVz4rJWL8Wup2jU8ocbqQS4Ntg/YHvHIFL5zvSeet2XOv6kND7zFPhZ/e2bq c10p0vzzV0GLWbpSAVMyVU8vcNitxFKckWioxVxUnAgAVCF7wyoCAAA=
Archived-At: 
Subject: Re: [netmod] Accessible subtree for When
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 09:08:40 -0000

On 2015-09-23 19:34, Martin Bjorklund wrote:
> Balazs Lengyel  wrote:
>> Hello Martin,
>> The RFC 6002bis-07writes:
>>
>> If the "when" statement is a child of any other data definition
>>        statement, the accessible tree is tentatively altered during the
>>        processing of the XPath expression by replacing all instances (if
>>        any) of the data node for which the "when" statement is defined
>>        with a single dummy node with the same name, but with no value and
>>        no children.  The context node is this dummy node.
>>
>> This to me means that the XPath expression can not reference any data nodes below
>> the when expression. True?
>>
>> This seems reasonable and needed. However if the when is a child of a uses,
>> choice, case or augment I don't see a similar rule. So the following would be
>> allowed:
>>
>>      augment "/if:interfaces/if:ifEntry" {
>>         when "num = 5";
>>         leaf num { type uint8; }
>>     }
>> This would be crazy as setting num to 5 would delete num itself. So I would
>> rather see a rule like:
>>
>> "When Xpath expressions MUST NOT reference data below the data definition
>> statement containing when."
> I think it would be better to say that these nodes do not exist in the
> XPath evaluation.  That gives deterministic behaviour.  The "MUST NOT
> reference" is hard to detect in a compiler...
>
>
> /martin
I am OK with that, just please make it generic for all cases of when, 
including cases when the when statement is a child of a uses,
choice, case or augment.
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Thu Sep 24 02:13:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2A81A88F2 for ; Thu, 24 Sep 2015 02:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr9QqbUlMmPc for ; Thu, 24 Sep 2015 02:13:50 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id BA2071A88C6 for ; Thu, 24 Sep 2015 02:13:49 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id F271DC4175C6; Thu, 24 Sep 2015 11:13:45 +0200 (CEST)
To: Ladislav Lhotka 
References: <20150923071322.14368.36275.idtracker@ietfa.amsl.com> <560274AF.3060705@mg-soft.si>  <560280FC.7080703@mg-soft.si> <99200EA5-1DFC-4749-B74B-84DC7876C8F4@nic.cz> <560287D1.9050905@mg-soft.si> 
From: Jernej Tuljak 
Message-ID: <5603BEC4.8050803@mg-soft.si>
Date: Thu, 24 Sep 2015 11:13:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 09:13:52 -0000

Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
> Jernej Tuljak  writes:
>
>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>
>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>>
>>>>>> Section 7.21.5., the first bullet describing the augmentation case does not consider that an "augment" may specify a top-level "choice" or a "choice"/"case" nested within a top-level "choice" as the target node. There will be no initial context node for the expression in such a case.
>>>>>>
>>>>>>    leaf enable-foos {
>>>>>>      type boolean;
>>>>>>    }
>>>>>>    choice ch1 {
>>>>>>      case foo {
>>>>>>        choice foos {
>>>>>>          when "enable-foos = 'true'";
>>>>>>          leaf foo1 {
>>>>>>            type string;
>>>>>>          }
>>>>>>          leaf foo2 {
>>>>>>            type string;
>>>>>>          }
>>>>>>        }
>>>>>>      }
>>>>>>      container meh;
>>>>>>    }
>>>>>>
>>>>>>    augment "/ch1/foo/foos" {
>>>>>>      when "enable-foos = 'true'";
>>>>>>      leaf foo3 {
>>>>>>        type string;
>>>>>>      }
>>>>>>    }
>>>>>>
>>>>>> OLD:
>>>>>>
>>>>>>     o  If the "when" statement is a child of an "augment" statement, then
>>>>>>        the context node is the augment's target node in the data tree, if
>>>>>>        the target node is a data node.  Otherwise, the context node is
>>>>>>        the closest ancestor node to the target node that is also a data
>>>>>>        node.
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>>     o  If the "when" statement is a child of an "augment" statement, then
>>>>>>        the context node is the augment's target node in the data tree, if
>>>>>>        the target node is a data node.  Otherwise, the context node is
>>>>>>        the closest ancestor node to the target node that is also a data
>>>>>>        node. If no such node exists, the context node is the root node.
>>>>>>
>>>>> Good catch, I support this change.
>>>>>
>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression must not reference nodes that are made conditional through that when statement. I can’t find this rule in the text.
>>>> The "no referencing the initial context node and its descendants" text is currently in the guidelines draft only (6087bis).
>>> IMO this should be a hard rule in 6020bis. Such expressions are seriously broken and could lead to deadlocks.
>> I think that was the purpose of the change in 3rd bullet. A "dummy" node
>> with no value and child nodes has been introduced.
> Not really, the dummy node solves the problem of a non-existent context
> node.

Are you referring to "existence" in the instance document or the schema 
tree? Why is there no need for "no children, no value dummy" in 1st and 
2nd bullet?

Jernej

> If the when expression refers to the value or descendants of the
> dummy node, then the procedure is ill-defined, see my response to
> Martin.
>
> Lada
>
>>      o  If the "when" statement is a child of any other data definition
>>         statement, the accessible tree is tentatively altered during the
>>         processing of the XPath expression by replacing all instances (if
>>         any) of the data node for which the "when" statement is defined
>>         with a single dummy node with the same name, but with no value and
>>         no children.  The context node is this dummy node.
>>
>> Jernej
>>
>>> Lada
>>>
>>>> Jernej
>>>>
>>>>> Lada
>>>>>
>>>>>> Jernej
>>>>>>
>>>>>> internet-drafts@ietf.org je 23.9.2015 ob 9:13 napisal:
>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>>    This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>>>>>>>
>>>>>>>           Title           : The YANG 1.1 Data Modeling Language
>>>>>>>           Author          : Martin Bjorklund
>>>>>>> 	Filename        : draft-ietf-netmod-rfc6020bis-07.txt
>>>>>>> 	Pages           : 196
>>>>>>> 	Date            : 2015-09-23
>>>>>>>
>>>>>>> Abstract:
>>>>>>>      YANG is a data modeling language used to model configuration data,
>>>>>>>      state data, remote procedure calls, and notifications for network
>>>>>>>      management protocols like the Network Configuration Protocol
>>>>>>>      (NETCONF).
>>>>>>>
>>>>>>>
>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>>>>>>
>>>>>>> There's also a htmlized version available at:
>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07
>>>>>>>
>>>>>>> A diff from the previous version is available at:
>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-07
>>>>>>>
>>>>>>>
>>>>>>> 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/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 24 02:16:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2326A1A88F3 for ; Thu, 24 Sep 2015 02:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX6F_oD_278o for ; Thu, 24 Sep 2015 02:16:56 -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 CB8BF1A8955 for ; Thu, 24 Sep 2015 02:16:55 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 49334FE6; Thu, 24 Sep 2015 11:16:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sbAei0RQN4Er; Thu, 24 Sep 2015 11:16:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 24 Sep 2015 11:16:53 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F2EB20054; Thu, 24 Sep 2015 11:16:53 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cZeNpjEtBMbn; Thu, 24 Sep 2015 11:16:52 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39AC32004E; Thu, 24 Sep 2015 11:16:51 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7D402375866A; Thu, 24 Sep 2015 11:16:50 +0200 (CEST)
Date: Thu, 24 Sep 2015 11:16:50 +0200
From: Juergen Schoenwaelder 
To: Dean Bogdanovic 
Message-ID: <20150924091649.GA5515@elstar.local>
Mail-Followup-To: Dean Bogdanovic , Andy Bierman , "netmod@ietf.org" 
References:  <55FFCF2F.5010902@cisco.com>   <560126A7.6060307@cisco.com>  <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4155A1EE-C87D-4873-8F31-5BED6D83F118@gmail.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 09:16:58 -0000

On Tue, Sep 22, 2015 at 02:39:20PM -0400, Dean Bogdanovic wrote:
> Andy,
> 
> Mobile operators are sharing infrastructure more and more. They are even now considering sharing spectrum. Today there are already use cases where Radio Access Network (RAN) is shared between multiple operators and they are interested in sharing core resources as well. I can see multiple NETCONF servers running on Mobile Switching Center (MSC), server per each virtual instance for tenant.
>

This sounds like full virtualization in the sense that each tenant
sees his own view of the world. This is fine and does not require any
changes to any of the existing data models. We are running NETCONF
servers on virtual machines and all is just fine.

The discussion (as I understand it) is whether multiple networking
stacks within a single operating system is something that needs to be
supported universally by mandating that every data model path includes
elements that allow to select the network stack (or namespace) one
talks about.

And in Linux, there are actually several namespaces (not just network
stack namespaces) that you can combine more or less freely, giving you
so called Linux containers (where the isolation is so complete that
running a NETCONF server inside a container is just fine again) and
the like but it is a whole spectrum of possible combinations in this
space.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Sep 24 04:54:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4625D1A909B for ; Thu, 24 Sep 2015 04:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDHOa0cAXYKt for ; Thu, 24 Sep 2015 04:54: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 242C11A909C for ; Thu, 24 Sep 2015 04:54:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 3382F1AE0484; Thu, 24 Sep 2015 13:54:50 +0200 (CEST)
Date: Thu, 24 Sep 2015 13:54:49 +0200 (CEST)
Message-Id: <20150924.135449.1944322803447003762.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <5603BEC4.8050803@mg-soft.si>
References: <560287D1.9050905@mg-soft.si>  <5603BEC4.8050803@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 11:54:54 -0000

SmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPiB3cm90ZToNCj4gTGFkaXNsYXYgTGhv
dGthIGplIDIzLjkuMjAxNSBvYiAxNDoyOSBuYXBpc2FsOg0KPiA+IEplcm5laiBUdWxqYWsgPGpl
cm5lanRAbWctc29mdC5zaT4gd3JpdGVzOg0KPiA+DQo+ID4+IExhZGlzbGF2IExob3RrYSBqZSAy
My45LjIwMTUgb2IgMTI6NTIgbmFwaXNhbDoNCj4gPj4+PiBPbiAyMyBTZXAgMjAxNSwgYXQgMTI6
MzcsIEplcm5laiBUdWxqYWsgPGplcm5lanRAbWctc29mdC5zaT4gd3JvdGU6DQo+ID4+Pj4NCj4g
Pj4+PiBMYWRpc2xhdiBMaG90a2EgamUgMjMuOS4yMDE1IG9iIDExOjU4IG5hcGlzYWw6DQo+ID4+
Pj4+PiBPbiAyMyBTZXAgMjAxNSwgYXQgMTE6NDUsIEplcm5laiBUdWxqYWsgPGplcm5lanRAbWct
c29mdC5zaT4gd3JvdGU6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU2VjdGlvbiA3LjIxLjUuLCB0aGUg
Zmlyc3QgYnVsbGV0IGRlc2NyaWJpbmcgdGhlIGF1Z21lbnRhdGlvbiBjYXNlDQo+ID4+Pj4+PiBk
b2VzIG5vdCBjb25zaWRlciB0aGF0IGFuICJhdWdtZW50IiBtYXkgc3BlY2lmeSBhIHRvcC1sZXZl
bCAiY2hvaWNlIg0KPiA+Pj4+Pj4gb3IgYSAiY2hvaWNlIi8iY2FzZSIgbmVzdGVkIHdpdGhpbiBh
IHRvcC1sZXZlbCAiY2hvaWNlIiBhcyB0aGUgdGFyZ2V0DQo+ID4+Pj4+PiBub2RlLiBUaGVyZSB3
aWxsIGJlIG5vIGluaXRpYWwgY29udGV4dCBub2RlIGZvciB0aGUgZXhwcmVzc2lvbiBpbiBzdWNo
DQo+ID4+Pj4+PiBhIGNhc2UuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgbGVhZiBlbmFibGUtZm9v
cyB7DQo+ID4+Pj4+PiAgICAgIHR5cGUgYm9vbGVhbjsNCj4gPj4+Pj4+ICAgIH0NCj4gPj4+Pj4+
ICAgIGNob2ljZSBjaDEgew0KPiA+Pj4+Pj4gICAgICBjYXNlIGZvbyB7DQo+ID4+Pj4+PiAgICAg
ICAgY2hvaWNlIGZvb3Mgew0KPiA+Pj4+Pj4gICAgICAgICAgd2hlbiAiZW5hYmxlLWZvb3MgPSAn
dHJ1ZSciOw0KPiA+Pj4+Pj4gICAgICAgICAgbGVhZiBmb28xIHsNCj4gPj4+Pj4+ICAgICAgICAg
ICAgdHlwZSBzdHJpbmc7DQo+ID4+Pj4+PiAgICAgICAgICB9DQo+ID4+Pj4+PiAgICAgICAgICBs
ZWFmIGZvbzIgew0KPiA+Pj4+Pj4gICAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPj4+Pj4+ICAg
ICAgICAgIH0NCj4gPj4+Pj4+ICAgICAgICB9DQo+ID4+Pj4+PiAgICAgIH0NCj4gPj4+Pj4+ICAg
ICAgY29udGFpbmVyIG1laDsNCj4gPj4+Pj4+ICAgIH0NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBh
dWdtZW50ICIvY2gxL2Zvby9mb29zIiB7DQo+ID4+Pj4+PiAgICAgIHdoZW4gImVuYWJsZS1mb29z
ID0gJ3RydWUnIjsNCj4gPj4+Pj4+ICAgICAgbGVhZiBmb28zIHsNCj4gPj4+Pj4+ICAgICAgICB0
eXBlIHN0cmluZzsNCj4gPj4+Pj4+ICAgICAgfQ0KPiA+Pj4+Pj4gICAgfQ0KPiA+Pj4+Pj4NCj4g
Pj4+Pj4+IE9MRDoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgbyBJZiB0aGUgIndoZW4iIHN0YXRl
bWVudCBpcyBhIGNoaWxkIG9mIGFuICJhdWdtZW50IiBzdGF0ZW1lbnQsDQo+ID4+Pj4+PiAgICAg
dGhlbg0KPiA+Pj4+Pj4gICAgICAgIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIGF1Z21lbnQncyB0
YXJnZXQgbm9kZSBpbiB0aGUgZGF0YSB0cmVlLA0KPiA+Pj4+Pj4gICAgICAgIGlmDQo+ID4+Pj4+
PiAgICAgICAgdGhlIHRhcmdldCBub2RlIGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0aGUg
Y29udGV4dCBub2RlIGlzDQo+ID4+Pj4+PiAgICAgICAgdGhlIGNsb3Nlc3QgYW5jZXN0b3Igbm9k
ZSB0byB0aGUgdGFyZ2V0IG5vZGUgdGhhdCBpcyBhbHNvIGEgZGF0YQ0KPiA+Pj4+Pj4gICAgICAg
IG5vZGUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTkVXOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICBv
IElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRl
bWVudCwNCj4gPj4+Pj4+ICAgICB0aGVuDQo+ID4+Pj4+PiAgICAgICAgdGhlIGNvbnRleHQgbm9k
ZSBpcyB0aGUgYXVnbWVudCdzIHRhcmdldCBub2RlIGluIHRoZSBkYXRhIHRyZWUsDQo+ID4+Pj4+
PiAgICAgICAgaWYNCj4gPj4+Pj4+ICAgICAgICB0aGUgdGFyZ2V0IG5vZGUgaXMgYSBkYXRhIG5v
ZGUuICBPdGhlcndpc2UsIHRoZSBjb250ZXh0IG5vZGUgaXMNCj4gPj4+Pj4+ICAgICAgICB0aGUg
Y2xvc2VzdCBhbmNlc3RvciBub2RlIHRvIHRoZSB0YXJnZXQgbm9kZSB0aGF0IGlzIGFsc28gYSBk
YXRhDQo+ID4+Pj4+PiAgICAgICAgbm9kZS4gSWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNv
bnRleHQgbm9kZSBpcyB0aGUgcm9vdCBub2RlLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4gR29vZCBjYXRj
aCwgSSBzdXBwb3J0IHRoaXMgY2hhbmdlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBbHNvIHJlZ2FyZGlu
ZyBzZWMuIDcuMjEuNSwgSSB0aGluayB3ZSBhZ3JlZWQgdGhhdCBhIHdoZW4gZXhwcmVzc2lvbg0K
PiA+Pj4+PiBtdXN0IG5vdCByZWZlcmVuY2Ugbm9kZXMgdGhhdCBhcmUgbWFkZSBjb25kaXRpb25h
bCB0aHJvdWdoIHRoYXQgd2hlbg0KPiA+Pj4+PiBzdGF0ZW1lbnQuIEkgY2Fu4oCZdCBmaW5kIHRo
aXMgcnVsZSBpbiB0aGUgdGV4dC4NCj4gPj4+PiBUaGUgIm5vIHJlZmVyZW5jaW5nIHRoZSBpbml0
aWFsIGNvbnRleHQgbm9kZSBhbmQgaXRzIGRlc2NlbmRhbnRzIiB0ZXh0DQo+ID4+Pj4gaXMgY3Vy
cmVudGx5IGluIHRoZSBndWlkZWxpbmVzIGRyYWZ0IG9ubHkgKDYwODdiaXMpLg0KPiA+Pj4gSU1P
IHRoaXMgc2hvdWxkIGJlIGEgaGFyZCBydWxlIGluIDYwMjBiaXMuIFN1Y2ggZXhwcmVzc2lvbnMg
YXJlDQo+ID4+PiBzZXJpb3VzbHkgYnJva2VuIGFuZCBjb3VsZCBsZWFkIHRvIGRlYWRsb2Nrcy4N
Cj4gPj4gSSB0aGluayB0aGF0IHdhcyB0aGUgcHVycG9zZSBvZiB0aGUgY2hhbmdlIGluIDNyZCBi
dWxsZXQuIEEgImR1bW15Ig0KPiA+PiBub2RlDQo+ID4+IHdpdGggbm8gdmFsdWUgYW5kIGNoaWxk
IG5vZGVzIGhhcyBiZWVuIGludHJvZHVjZWQuDQo+ID4gTm90IHJlYWxseSwgdGhlIGR1bW15IG5v
ZGUgc29sdmVzIHRoZSBwcm9ibGVtIG9mIGEgbm9uLWV4aXN0ZW50DQo+ID4gY29udGV4dA0KPiA+
IG5vZGUuDQo+IA0KPiBBcmUgeW91IHJlZmVycmluZyB0byAiZXhpc3RlbmNlIiBpbiB0aGUgaW5z
dGFuY2UgZG9jdW1lbnQgb3IgdGhlDQo+IHNjaGVtYSB0cmVlPyBXaHkgaXMgdGhlcmUgbm8gbmVl
ZCBmb3IgIm5vIGNoaWxkcmVuLCBubyB2YWx1ZSBkdW1teSIgaW4NCj4gMXN0IGFuZCAybmQgYnVs
bGV0Pw0KDQpJbiB0aGVzZSBjYXNlcywgdGhlIGNvbnRleHQgbm9kZSBpcyB3ZWxsLWRlZmluZWQg
YW55d2F5LiAgQnV0IEkgdGhpbmsNCnRoYXQgYWxzbyB0aGVzZSBidWxsZXRzIG5lZWQgdG8gaGF2
ZSB0ZXh0IHRoYXQgbWFrZSBzdXJlIHRoYXQgdGhlDQpvdXRjb21lIGlzIGRldGVybWluaXN0aWMg
aW4gYWxsIGNhc2VzLCBzdWNoIGFzOg0KDQogIGF1Z2VtZW50IC9mb28gew0KICAgIHdoZW4gImJh
ciA+IDEiOw0KICAgIGxlYWYgYmFyIHsgdHlwZSBpbnQzMjsgfQ0KICB9DQoNCm9yDQoNCiAgZ3Jv
dXBpbmcgZm9vIHsNCiAgICBsZWFmIGJhciB7IHR5cGUgaW50MzI7IH0NCiAgfQ0KICBjb250YWlu
ZXIgeCB7DQogICAgdXNlcyBmb28gew0KICAgICAgd2hlbiAiYmFyID4gMSI7DQogICAgfQ0KICB9
DQoNCg0KZXRjLg0KDQpTbyBJIHN1Z2dlc3QgdGhpcyBORVcgdGV4dDoNCg0KDQogICBvICBJZiB0
aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFuICJhdWdtZW50IiBzdGF0ZW1lbnQs
IHRoZW4NCiAgICAgIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIGF1Z21lbnQncyB0YXJnZXQgbm9k
ZSBpbiB0aGUgZGF0YSB0cmVlLCBpZg0KICAgICAgdGhlIHRhcmdldCBub2RlIGlzIGEgZGF0YSBu
b2RlLiAgT3RoZXJ3aXNlLCB0aGUgY29udGV4dCBub2RlIGlzDQogICAgICB0aGUgY2xvc2VzdCBh
bmNlc3RvciBub2RlIHRvIHRoZSB0YXJnZXQgbm9kZSB0aGF0IGlzIGFsc28gYSBkYXRhDQogICAg
ICBub2RlLiAgSWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUg
cm9vdCBub2RlLg0KICAgICAgVGhlIGFjY2Vzc2libGUgdHJlZSBpcyB0ZW50YXRpdmVseSBhbHRl
cmVkIGR1cmluZyB0aGUgcHJvY2Vzc2luZw0KICAgICAgb2YgdGhlIFhQYXRoIGV4cHJlc3Npb24g
YnkgcmVtb3ZpbmcgYWxsIGluc3RhbmNlcyAoaWYgYW55KSBvZiB0aGUNCiAgICAgIG5vZGVzIGFk
ZGVkIGJ5IHRoZSAiYXVnbWVudCIgc3RhdGVtZW50Lg0KDQogICBvICBJZiB0aGUgIndoZW4iIHN0
YXRlbWVudCBpcyBhIGNoaWxkIG9mIGEgInVzZXMiLCAiY2hvaWNlIiwgb3INCiAgICAgICJjYXNl
IiBzdGF0ZW1lbnQsIHRoZW4gdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgY2xvc2VzdCBhbmNlc3Rv
cg0KICAgICAgbm9kZSB0byB0aGUgInVzZXMiLCAiY2hvaWNlIiwgb3IgImNhc2UiIG5vZGUgdGhh
dCBpcyBhbHNvIGEgZGF0YQ0KICAgICAgbm9kZS4gIElmIG5vIHN1Y2ggbm9kZSBleGlzdHMsIHRo
ZSBjb250ZXh0IG5vZGUgaXMgdGhlIHJvb3Qgbm9kZS4NCiAgICAgIFRoZSBhY2Nlc3NpYmxlIHRy
ZWUgaXMgdGVudGF0aXZlbHkgYWx0ZXJlZCBkdXJpbmcgdGhlIHByb2Nlc3NpbmcNCiAgICAgIG9m
IHRoZSBYUGF0aCBleHByZXNzaW9uIGJ5IHJlbW92aW5nIGFsbCBpbnN0YW5jZXMgKGlmIGFueSkg
b2YgdGhlDQogICAgICBub2RlcyBhZGRlZCBieSB0aGUgInVzZXMiLCAiY2hvaWNlIiwgb3IgImNh
c2UiIHN0YXRlbWVudC4NCg0KICAgbyAgSWYgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgYSBjaGls
ZCBvZiBhbnkgb3RoZXIgZGF0YSBkZWZpbml0aW9uDQogICAgICBzdGF0ZW1lbnQsIHRoZSBhY2Nl
c3NpYmxlIHRyZWUgaXMgdGVudGF0aXZlbHkgYWx0ZXJlZCBkdXJpbmcgdGhlDQogICAgICBwcm9j
ZXNzaW5nIG9mIHRoZSBYUGF0aCBleHByZXNzaW9uIGJ5IHJlcGxhY2luZyBhbGwgaW5zdGFuY2Vz
IChpZg0KICAgICAgYW55KSBvZiB0aGUgZGF0YSBub2RlIGZvciB3aGljaCB0aGUgIndoZW4iIHN0
YXRlbWVudCBpcyBkZWZpbmVkDQogICAgICB3aXRoIGEgc2luZ2xlIGR1bW15IG5vZGUgd2l0aCB0
aGUgc2FtZSBuYW1lLCBidXQgd2l0aCBubyB2YWx1ZSBhbmQNCiAgICAgIG5vIGNoaWxkcmVuLiAg
VGhlIGNvbnRleHQgbm9kZSBpcyB0aGlzIGR1bW15IG5vZGUuDQoNCg0KDQovbWFydGluDQo=


From nobody Thu Sep 24 05:48:09 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F181ACE05 for ; Thu, 24 Sep 2015 05:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQfqeoQ7LJkd for ; Thu, 24 Sep 2015 05:48:05 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2631ACDE5 for ; Thu, 24 Sep 2015 05:48:05 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id BDB2FC4175C6; Thu, 24 Sep 2015 14:48:03 +0200 (CEST)
To: Martin Bjorklund 
References: <560287D1.9050905@mg-soft.si>  <5603BEC4.8050803@mg-soft.si> <20150924.135449.1944322803447003762.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <5603F0FE.6000808@mg-soft.si>
Date: Thu, 24 Sep 2015 14:47:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150924.135449.1944322803447003762.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 12:48:08 -0000

Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
> Jernej Tuljak  wrote:
>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>> Jernej Tuljak  writes:
>>>
>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>>>
>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>>>>
>>>>>>>> Section 7.21.5., the first bullet describing the augmentation case
>>>>>>>> does not consider that an "augment" may specify a top-level "choice"
>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the target
>>>>>>>> node. There will be no initial context node for the expression in such
>>>>>>>> a case.
>>>>>>>>
>>>>>>>>     leaf enable-foos {
>>>>>>>>       type boolean;
>>>>>>>>     }
>>>>>>>>     choice ch1 {
>>>>>>>>       case foo {
>>>>>>>>         choice foos {
>>>>>>>>           when "enable-foos = 'true'";
>>>>>>>>           leaf foo1 {
>>>>>>>>             type string;
>>>>>>>>           }
>>>>>>>>           leaf foo2 {
>>>>>>>>             type string;
>>>>>>>>           }
>>>>>>>>         }
>>>>>>>>       }
>>>>>>>>       container meh;
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     augment "/ch1/foo/foos" {
>>>>>>>>       when "enable-foos = 'true'";
>>>>>>>>       leaf foo3 {
>>>>>>>>         type string;
>>>>>>>>       }
>>>>>>>>     }
>>>>>>>>
>>>>>>>> OLD:
>>>>>>>>
>>>>>>>>      o If the "when" statement is a child of an "augment" statement,
>>>>>>>>      then
>>>>>>>>         the context node is the augment's target node in the data tree,
>>>>>>>>         if
>>>>>>>>         the target node is a data node.  Otherwise, the context node is
>>>>>>>>         the closest ancestor node to the target node that is also a data
>>>>>>>>         node.
>>>>>>>>
>>>>>>>> NEW:
>>>>>>>>
>>>>>>>>      o If the "when" statement is a child of an "augment" statement,
>>>>>>>>      then
>>>>>>>>         the context node is the augment's target node in the data tree,
>>>>>>>>         if
>>>>>>>>         the target node is a data node.  Otherwise, the context node is
>>>>>>>>         the closest ancestor node to the target node that is also a data
>>>>>>>>         node. If no such node exists, the context node is the root node.
>>>>>>>>
>>>>>>> Good catch, I support this change.
>>>>>>>
>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression
>>>>>>> must not reference nodes that are made conditional through that when
>>>>>>> statement. I can’t find this rule in the text.
>>>>>> The "no referencing the initial context node and its descendants" text
>>>>>> is currently in the guidelines draft only (6087bis).
>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>> seriously broken and could lead to deadlocks.
>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>> node
>>>> with no value and child nodes has been introduced.
>>> Not really, the dummy node solves the problem of a non-existent
>>> context
>>> node.
>> Are you referring to "existence" in the instance document or the
>> schema tree? Why is there no need for "no children, no value dummy" in
>> 1st and 2nd bullet?
> In these cases, the context node is well-defined anyway.  But I think
> that also these bullets need to have text that make sure that the
> outcome is deterministic in all cases, such as:
>
>    augement /foo {
>      when "bar > 1";
>      leaf bar { type int32; }
>    }
>
> or
>
>    grouping foo {
>      leaf bar { type int32; }
>    }
>    container x {
>      uses foo {
>        when "bar > 1";
>      }
>    }
>
>
> etc.
>
> So I suggest this NEW text:
>
>
>     o  If the "when" statement is a child of an "augment" statement, then
>        the context node is the augment's target node in the data tree, if
>        the target node is a data node.  Otherwise, the context node is
>        the closest ancestor node to the target node that is also a data
>        node.  If no such node exists, the context node is the root node.
>        The accessible tree is tentatively altered during the processing
>        of the XPath expression by removing all instances (if any) of the
>        nodes added by the "augment" statement.
>
>     o  If the "when" statement is a child of a "uses", "choice", or
>        "case" statement, then the context node is the closest ancestor
>        node to the "uses", "choice", or "case" node that is also a data
>        node.  If no such node exists, the context node is the root node.
>        The accessible tree is tentatively altered during the processing
>        of the XPath expression by removing all instances (if any) of the
>        nodes added by the "uses", "choice", or "case" statement.
>
>     o  If the "when" statement is a child of any other data definition
>        statement, the accessible tree is tentatively altered during the
>        processing of the XPath expression by replacing all instances (if
>        any) of the data node for which the "when" statement is defined
>        with a single dummy node with the same name, but with no value and
>        no children.  The context node is this dummy node.
>

+1

   container foo {
     when "child::* or child::text() or not(self::*)"; // always false
     leaf bar {
       type string;
     }
   }

Jernej

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


From nobody Thu Sep 24 06:25:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2641AD059 for ; Thu, 24 Sep 2015 06:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_7aoArUxbdi for ; Thu, 24 Sep 2015 06:25:26 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAF11ACF6C for ; Thu, 24 Sep 2015 06:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8457; q=dns/txt; s=iport; t=1443101126; x=1444310726; h=from:subject:to:references:message-id:date:mime-version: in-reply-to; bh=PIEz6ycmbQ5VIJq98fjlgyk2uXrJxUbm96D83vIhf9Q=; b=cnqepC1P9seoeJmoFhqZ4Yh+bI/l9xgkoKRnjJVZ8CnFvhjzU65FksN1 znwa0zXyKjomNfXlKbQIHMshG96Wly/ZuqioS7w7yKYC3BgCCYdgGE2jy vnix/mBQ33RGJ1B55D34H3nh1ju5N9/q6ZynHshtZk/vpsONziDnfL9wY 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DLAQB2+QNW/xbLJq1dgleBIWm9PgENgXABCYUvSgKCAhQBAQEBAQEBgQqEJAEBAQMBAQEBawQGEQsOCgkWBAsJAwIBAgEVMAYBDAYCAQGIIggNy3cBAQEBAQEBAQEBAQEBAQEBAQEBARQEhnOEfYRCUoQsBZVnjQuBT4Q2gn6Ja4g8HwEBQoJDgT89M4gmJYEhAQEB
X-IronPort-AV: E=Sophos;i="5.17,581,1437436800";  d="scan'208,217";a="611821261"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 24 Sep 2015 13:25:24 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8ODPNoZ009967; Thu, 24 Sep 2015 13:25:23 GMT
From: Robert Wilton 
To: Kent Watsen , "netmod@ietf.org" 
References: 
Message-ID: <5603F9C2.2000500@cisco.com>
Date: Thu, 24 Sep 2015 14:25:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030400030804000406020900"
Archived-At: 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 13:25:29 -0000

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

Hi Kent,

On 23/09/2015 17:15, Kent Watsen wrote:
>
> Jonathan Hansford writes: The requirements talk about both synchronous 
> and asynchronous systems (1(D), 3, 3(A)) but really only address the 
> behaviour for asynchronous systems. Would it not be worth clarifying 
> the relationship between the intended and applied configurations for 
> synchronous systems (i.e. they are the same), hence there is no need 
> for synchronous requirements equivalent to 1(D) and 3(A)?
>
> Ultimately, I think we need normative text in the "Terminology 
> Section" for a "synchronous system" and "asynchronous system".  Would 
> someone care to take a stab providing these two definitions?

First stab only, probably needs some tweaking ...

I find that the term "system" is a bit ambiguous in this context. It is 
talking about the NMS, the server, or both together?

Anyway, I've tried to define them relative to the configuration 
operations being performed.

Synchronous configuration operation - A configuration request that the 
server applies synchronously with respect to the client request.  Before 
the server replies back to the client indicating the success or failure 
of the operation it MUST semantically validate the contents of the 
request and update the intended configuration of the target datastore.  
If the request is to the running datastore then the configuration change 
MUST also be applied in the system before the server replies back to the 
client.  The reply to the client indicates whether there are any 
semantic errors or system errors from applying the configuration change.

Asynchronous configuration operation - A configuration request that the 
server applies asynchronously with respect to the client request.  
Before the server replies back to the client indicating the success or 
failure of the operation it MUST semantically validate the contents of 
the request and update the intended configuration of the target 
datastore.  If the request is to the running datastore then the 
configuration change is applied to the system after the server has 
replied back to the client.  The reply to the client only indicates 
whether there are any semantic errors in the configuration change.

Synchronous system - NETCONF/RESTCONF client/server interactions that 
processes all configuration operations as synchronous configuration 
operations.

Asynchronous system - NETCONF/RESTCONF client/server interactions that 
processes all configuration operations as asynchronous configuration 
operations.

Thanks,
Rob


>
>
> PS: please Reply-All to this thread, rather than post comments on the 
> GitHub issue tracker.
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    Hi Kent,

    

    
On 23/09/2015 17:15, Kent Watsen wrote:

    

    

      
      

        
 

        

        
Jonathan Hansford writes:
            The requirements talk about both synchronous and
            asynchronous systems (1(D), 3, 3(A)) but really only address
            the behaviour for asynchronous systems. Would it not be
            worth clarifying the relationship between the intended and
            applied configurations for synchronous systems (i.e. they
            are the same), hence there is no need for synchronous
            requirements equivalent to 1(D) and 3(A)?

        


        

        
Ultimately, I think we need normative text in the
          "Terminology Section" for a "synchronous system" and
          "asynchronous system". Would someone care to take a stab
          providing these two definitions?

      

    

    

    First stab only, probably needs some tweaking ...

    

    I find that the term "system" is a bit ambiguous in this context.
    It is talking about the NMS, the server, or both together?

    

    Anyway, I've tried to define them relative to the configuration
    operations being performed.

    

    Synchronous configuration operation - A configuration request that
    the server applies synchronously with respect to the client
    request. Before the server replies back to the client indicating
    the success or failure of the operation it MUST semantically
    validate the contents of the request and update the intended
    configuration of the target datastore. If the request is to the
    running datastore then the configuration change MUST also be applied
    in the system before the server replies back to the client. The
    reply to the client indicates whether there are any semantic errors
    or system errors from applying the configuration change.

    

    Asynchronous configuration operation - A configuration request that
    the server applies asynchronously with respect to the client
    request. Before the server replies back to the client indicating
    the success or failure of the operation it MUST semantically
    validate the contents of the request and update the intended
    configuration of the target datastore. If the request is to the
    running datastore then the configuration change is applied to the
    system after the server has replied back to the client. The reply
    to the client only indicates whether there are any semantic errors
    in the configuration change.

    

    Synchronous system - NETCONF/RESTCONF client/server interactions
    that processes all configuration operations as synchronous
    configuration operations.

    

    Asynchronous system - NETCONF/RESTCONF client/server interactions
    that processes all configuration operations as asynchronous
    configuration operations.

    

    Thanks,

    Rob

    

    

    

      
 

      

        


          

        


          

        
PS: please Reply-All to
            this thread, rather than post comments on theGitHub issue
            tracker.

        
 

        

      

      
 Thanks,

      
 Kent

      
 

      

      

      

      

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


    

    

  


--------------030400030804000406020900--


From nobody Thu Sep 24 11:22:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A03C1A00C6 for ; Thu, 24 Sep 2015 11:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cSjyiAS3YLI for ; Thu, 24 Sep 2015 11:22:10 -0700 (PDT)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 0C0431A6F66 for ; Thu, 24 Sep 2015 11:22:10 -0700 (PDT)
Received: by lacao8 with SMTP id ao8so73266068lac.3 for ; Thu, 24 Sep 2015 11:22:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cmfI7b4HcPv8LxNYVg0k66AbY9VQK2jS+Yb8+ytAX8o=; b=jhyuJfM/2/UE+4TiKJumgOvwPHce7xsIGkbx2Bl4OtEa1fVScL8XkDDgvdU3MFWlX8 txvFTnQLg8mWfxiiTyuT7W5WAuzXgPndVYAeojbExFcccCyXGAG4XNwN/WwoCm1ugL2x euE1JmGlDSma+qtCS2B9D6/HBW47OpGzaghOFVBL2AqIh26n+kS6iVCRzTjBhaR8Pcdv eAvFUvJfPOOBpxP7p4mT1OnqaAmWzwBqUsoZsmAh6E46q3wD3hZtKPT4y3cvI0yv4MEJ MDGolDXFwcwFK+rLpskNgLa8NRreo8YK5ybHqzfm44k6+isAyNVijAzoBoK73JJRjblK Dz5A==
X-Gm-Message-State: ALoCoQl+We0KNGcTzMEJQ5d+S5D72Yda/UlGVQteCd7CY5ESr5QXfZl2+9fF13M/PoPrZZ7P0Cu7
MIME-Version: 1.0
X-Received: by 10.112.156.167 with SMTP id wf7mr321781lbb.88.1443118928094; Thu, 24 Sep 2015 11:22:08 -0700 (PDT)
Received: by 10.112.200.104 with HTTP; Thu, 24 Sep 2015 11:22:07 -0700 (PDT)
In-Reply-To: <5603F9C2.2000500@cisco.com>
References:  <5603F9C2.2000500@cisco.com>
Date: Thu, 24 Sep 2015 11:22:07 -0700
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11c27b261404bc0520824f51
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 18:22:13 -0000

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

Hi,

I find this exercise to classify servers as synchronous or asynchronous
mostly useless.
We have both types of instrumentation in our server. They can be different
on a per-node basis.  They can both take a long time or both be instant,
depending
on the instrumentation code the vendor writes.

In any case, the server does not know if the instrumentation has finished
making
the network behave according to the new edit.  That would be new
functionality that
no vendor supports at this time.  Currently servers return "ok" if the edit
is accepted
into the running datastore.  There are no other semantics wrt/ returning
"ok".

Even something as simple as "set the log-level" could be centralized or
distributed.
So every single leaf is a separate case and every single implementation of
every leaf
is a separate case.  It is completely implementation-dependent.  One
platform may
take a long time and another from the same vendor may not, for the exact
same leaf.

So instead of talking about the entire server being sync or async, we need
to
talk about a specific implementation of a specific leaf, and not try to
generalize
and simplify the problem.


Andy







On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton  wrote:

> Hi Kent,
>
> On 23/09/2015 17:15, Kent Watsen wrote:
>
>
> Jonathan Hansford writes: The requirements talk about both synchronous and
> asynchronous systems (1(D), 3, 3(A)) but really only address the behaviour
> for asynchronous systems. Would it not be worth clarifying the relationship
> between the intended and applied configurations for synchronous systems
> (i.e. they are the same), hence there is no need for synchronous
> requirements equivalent to 1(D) and 3(A)?
>
> Ultimately, I think we need normative text in the "Terminology Section"
> for a "synchronous system" and "asynchronous system".  Would someone care
> to take a stab providing these two definitions?
>
>
> First stab only, probably needs some tweaking ...
>
> I find that the term "system" is a bit ambiguous in this context.  It is
> talking about the NMS, the server, or both together?
>
> Anyway, I've tried to define them relative to the configuration operations
> being performed.
>
> Synchronous configuration operation - A configuration request that the
> server applies synchronously with respect to the client request.  Before
> the server replies back to the client indicating the success or failure of
> the operation it MUST semantically validate the contents of the request and
> update the intended configuration of the target datastore.  If the request
> is to the running datastore then the configuration change MUST also be
> applied in the system before the server replies back to the client.  The
> reply to the client indicates whether there are any semantic errors or
> system errors from applying the configuration change.
>
> Asynchronous configuration operation - A configuration request that the
> server applies asynchronously with respect to the client request.  Before
> the server replies back to the client indicating the success or failure of
> the operation it MUST semantically validate the contents of the request and
> update the intended configuration of the target datastore.  If the request
> is to the running datastore then the configuration change is applied to the
> system after the server has replied back to the client.  The reply to the
> client only indicates whether there are any semantic errors in the
> configuration change.
>
> Synchronous system - NETCONF/RESTCONF client/server interactions that
> processes all configuration operations as synchronous configuration
> operations.
>
> Asynchronous system - NETCONF/RESTCONF client/server interactions that
> processes all configuration operations as asynchronous configuration
> operations.
>
> Thanks,
> Rob
>
>
>
>
> PS: please Reply-All to this thread, rather than post comments on the GitHub
> issue tracker.
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi,

I find this exercise to classify se=
rvers as synchronous or asynchronous mostly useless.
We have both=
 types of instrumentation in our server. They can be different
on=
 a per-node basis.=C2=A0 They can both take a long time or both be instant,=
 depending
on the instrumentation code the vendor writes.

In any case, the server does not know if the instrumentat=
ion has finished making
the network behave according to the new e=
dit.=C2=A0 That would be new functionality that
no vendor support=
s at this time.=C2=A0 Currently servers return "ok" if the edit i=
s accepted
into the running datastore.=C2=A0 There are no other s=
emantics wrt/ returning "ok".

Even somet=
hing as simple as "set the log-level" could be centralized or dis=
tributed.
So every single leaf is a separate case and every singl=
e implementation of every leaf
is a separate case.=C2=A0 It is co=
mpletely implementation-dependent.=C2=A0 One platform may
take a =
long time and another from the same vendor may not, for the exact same leaf=
.

So instead of talking about the entire server be=
ing sync or async, we need to
talk about a specific implementatio=
n of a specific leaf, and not try to generalize
and simplify the =
problem.


Andy

<=
div>




<=
/div>

On Thu, Sep =
24, 2015 at 6:25 AM, Robert Wilton <rwilton@cisco.com> wrote=
:

 =20
   =20
 =20
  

    Hi Kent,

    

    
On 23/09/2015 17:15, Kent Watsen wrote:

    

    

     =20
      

        
 

        

        
Jonathan Hansford writes:
            The requirements talk about both synchronous and
            asynchronous systems (1(D), 3, 3(A)) but really only address
            the behaviour for asynchronous systems. Would it not be
            worth clarifying the relationship between the intended and
            applied configurations for synchronous systems (i.e. they
            are the same), hence there is no need for synchronous
            requirements equivalent to 1(D) and 3(A)?

        


        

        
Ultimately, I think we need normative text in the
          "Terminology Section" for a "synchronous system&qu=
ot; and
          "asynchronous system".=C2=A0 Would someone care to take=
 a stab
          providing these two definitions?

      

    

    

    First stab only, probably needs some tweaking ...

    

    I find that the term "system" is a bit ambiguous in this cont=
ext.=C2=A0
    It is talking about the NMS, the server, or both together?

    

    Anyway, I've tried to define them relative to the configuration
    operations being performed.

    

    Synchronous configuration operation - A configuration request that
    the server applies synchronously with respect to the client
    request.=C2=A0 Before the server replies back to the client indicating
    the success or failure of the operation it MUST semantically
    validate the contents of the request and update the intended
    configuration of the target datastore.=C2=A0 If the request is to the
    running datastore then the configuration change MUST also be applied
    in the system before the server replies back to the client.=C2=A0 The
    reply to the client indicates whether there are any semantic errors
    or system errors from applying the configuration change.

    

    Asynchronous configuration operation - A configuration request that
    the server applies asynchronously with respect to the client
    request.=C2=A0 Before the server replies back to the client indicating
    the success or failure of the operation it MUST semantically
    validate the contents of the request and update the intended
    configuration of the target datastore.=C2=A0 If the request is to the
    running datastore then the configuration change is applied to the
    system after the server has replied back to the client.=C2=A0 The reply
    to the client only indicates whether there are any semantic errors
    in the configuration change.

    

    Synchronous system - NETCONF/RESTCONF client/server interactions
    that processes all configuration operations as synchronous
    configuration operations.

    

    Asynchronous system - NETCONF/RESTCONF client/server interactions
    that processes all configuration operations as asynchronous
    configuration operations.

    

    Thanks,

    Rob

    

    

    

      
 

      

        


          

        


          

        
PS: please Reply-All to
            this thread, rather than post comments on the=C2=A0GitHub issue
            tracker.

        
 

        

      

      
 Thanks,

      
 Kent

      
 

      

      

      

      

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


    

    

  



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c27b261404bc0520824f51--


From nobody Thu Sep 24 13:08:09 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BA31AC3AE for ; Thu, 24 Sep 2015 13:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_rt4ECZ0S5Z for ; Thu, 24 Sep 2015 13:08:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92621A9308 for ; Thu, 24 Sep 2015 13:08:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXZ77819; Thu, 24 Sep 2015 20:08:01 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Sep 2015 21:08:01 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 24 Sep 2015 13:07:57 -0700
From: Linda Dunbar 
To: "'netmod@ietf.org'" , "draft-ietf-netmod-acl-model.ll@tools.ietf.org" 
Thread-Topic: Question about draft-ietf-netmod-acl-model-03
Thread-Index: AdD3BLPlCKPuBUwORB6rJEmAQKX2vw==
Date: Thu, 24 Sep 2015 20:07:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D61691@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.54]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657D61691dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Question about draft-ietf-netmod-acl-model-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 20:08:07 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F657D61691dfweml701chm_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dean, et al,

Does the following statement in the Section 7 IANA Consideration make  "iet=
f-acl" equivalent to the long name "urn:ietf:params:xml:ns:yang:ietf-access=
-control-list"?

urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl


If the answer is YES, can the example in Section 4.3 can use "ietf-acl" dir=
ectly instead of the long name?
i.e.
 


What does the ":1.0" mean in the example?

Thanks, Linda


--_000_4A95BA014132FF49AE685FAB4B9F17F657D61691dfweml701chm_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dean, et al, 


 


Does the following statement in the Section 7 IANA C=
onsideration make  “ietf-acl” equivalent to the long name =
“urn:ietf:params=
:xml:ns:yang:ietf-access-control-list”?


 


urn:ietf:params:xml:ns:yang:ietf-access-control=
-list prefix: ietf-acl


 


 


If the answer is YES, can the example in Section 4.3=
 can use “ietf-acl” directly instead of the long name?



i.e. 


 <access-lists "urn:ietf:par=
ams:xml:ns:yang:ietf-acl:1.0">


 


 


What does the “:1.0” mean in the example=
? 


 


Thanks, Linda 


 






--_000_4A95BA014132FF49AE685FAB4B9F17F657D61691dfweml701chm_--


From nobody Thu Sep 24 13:52:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427381B329F for ; Thu, 24 Sep 2015 13:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDn-WK1kZV5Q for ; Thu, 24 Sep 2015 13:51:57 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3946B1B3299 for ; Thu, 24 Sep 2015 13:51:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXZ79729; Thu, 24 Sep 2015 20:51:54 +0000 (GMT)
Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Sep 2015 21:51:53 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 24 Sep 2015 13:51:46 -0700
From: Linda Dunbar 
To: "'draft-ietf-netmod-acl-model.all@tools.ietf.org'" <'draft-ietf-netmod-acl-model.all@tools.ietf.org'>
Thread-Topic: more Questions about draft-ietf-netmod-acl-model-03
Thread-Index: AQHQ9wrTP0qEmeoXzU+W1Lr3da54Zw==
Date: Thu, 24 Sep 2015 20:51:45 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D61751@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.54]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657D61751dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "ietf-access-control-list@2015-05-03.yang" , "'netmod@ietf.org'" 
Subject: [netmod] more Questions about draft-ietf-netmod-acl-model-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 20:52:00 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F657D61751dfweml701chm_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Dean, et al,

I have a few questions about the draft:

1.      Does the following statement in the Section 7 IANA Consideration ma=
ke  "ietf-acl" equivalent to the long name "urn:ietf:params:xml:ns:yang:iet=
f-access-control-list"?

urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl


If the answer is YES, can the example in Section 4.3 can use "ietf-acl" dir=
ectly instead of the long name?
i.e.
 



Does the "1" in ":1.0" above mean "yang-version 1" defined in the "module i=
etf-access-control-list"?  what about the "0" a?


2.      The beginning of the module has "prefix acl". Does it mean that "ac=
l" is equivalent to "ietf-access-control-list"?

file "ietf-access-control-list@2015-05-03.yang"
module ietf-access-control-list {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
prefix acl;


3.      With "prefix acl" listed right after the "namespace", does the acl =
in "ietf-acl:acl" (in Appendix A.1) actually mean the whole name space?

Thanks, Linda


--_000_4A95BA014132FF49AE685FAB4B9F17F657D61751dfweml701chm_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


Dean, et al, 


 


I have a few questions about the draft: <=
/p>

1.     
Does the following statement in the Section 7 IANA =
Consideration make  “ietf-acl” equivalent to the long name=
 “urn:ietf:param=
s:xml:ns:yang:ietf-access-control-list”?


 


urn:ietf:params:xml:ns:yang:ietf-access-control=
-list prefix: ietf-acl


 


 


If the answer is YES, can=
 the example in Section 4.3 can use “ietf-acl” directly instead=
 of the long name?



i.e. 


 =
;<access-lists &quo=
t;urn:ietf:params:xml:ns:yang:ietf-acl:1.0">


 


 


 


Does the “1” =
in “:1.0” above mean “yang-version 1” defined in th=
e “module ietf-access-control-list”?  what about the ̶=
0;0” a?



 


2.     
The beginning of the module has “prefix acl&#=
8221;. Does it mean that “acl” is equivalent to “ietf-acc=
ess-control-list”?


 


<CODE BEGINS>file &qu=
ot;ietf-access-control-list@2015-05-03.yang"


module ietf-access-control-=
list {


yang-version 1;=



namespace "urn:ietf:p=
arams:xml:ns:yang:ietf-access-control-list";


prefix acl;


 


3.     
With “prefix acl” listed right after th=
e “namespace”, does the acl in “ietf-acl:acl” (in A=
ppendix A.1) actually mean the whole name space?



 


Thanks, Linda 


 






--_000_4A95BA014132FF49AE685FAB4B9F17F657D61751dfweml701chm_--


From nobody Thu Sep 24 14:29:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4321B3B7F for ; Thu, 24 Sep 2015 14:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.26
X-Spam-Level: 
X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tXZkGDlXsSz for ; Thu, 24 Sep 2015 14:29:44 -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 82BC81B3B7C for ; Thu, 24 Sep 2015 14:29:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20DE11018; Thu, 24 Sep 2015 23:29:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zMapF3uyTdKJ; Thu, 24 Sep 2015 23:29:41 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 24 Sep 2015 23:29:41 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0DE920054; Thu, 24 Sep 2015 23:29:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TbeIDN-4hi_W; Thu, 24 Sep 2015 23:29:40 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2338B2004E; Thu, 24 Sep 2015 23:29:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E13C63759124; Thu, 24 Sep 2015 23:29:39 +0200 (CEST)
Date: Thu, 24 Sep 2015 23:29:39 +0200
From: Juergen Schoenwaelder 
To: Linda Dunbar 
Message-ID: <20150924212939.GA7113@elstar.local>
Mail-Followup-To: Linda Dunbar , "'draft-ietf-netmod-acl-model.all@tools.ietf.org'" <'draft-ietf-netmod-acl-model.all@tools.ietf.org'>,  "ietf-access-control-list@2015-05-03.yang" ,  "'netmod@ietf.org'" 
References: <4A95BA014132FF49AE685FAB4B9F17F657D61751@dfweml701-chm>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D61751@dfweml701-chm>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "ietf-access-control-list@2015-05-03.yang" , "'draft-ietf-netmod-acl-model.all@tools.ietf.org'" <'draft-ietf-netmod-acl-model.all@tools.ietf.org'>, "'netmod@ietf.org'" 
Subject: Re: [netmod] more Questions about draft-ietf-netmod-acl-model-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Sep 2015 21:29:47 -0000

On Thu, Sep 24, 2015 at 08:51:45PM +0000, Linda Dunbar wrote:
> 
> Dean, et al,
> 
> I have a few questions about the draft:
> 
> 1.      Does the following statement in the Section 7 IANA Consideration make  "ietf-acl" equivalent to the long name "urn:ietf:params:xml:ns:yang:ietf-access-control-list"?
> 
> urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl
>

No. See RFC 6020 sections 7.1.3 and 7.1.4 how 'namespace' and 'prefix'
statements work. The IANA section only registers the values declared
in the YANG modules.
 
> If the answer is YES, can the example in Section 4.3 can use "ietf-acl" directly instead of the long name?
> i.e.
>  

The example does not match the YANG definition, it is broken.

> Does the "1" in ":1.0" above mean "yang-version 1" defined in the "module ietf-access-control-list"?  what about the "0" a?

The :1.0 likely should not be there. There is not tagging of the YANG
language version used to define the data model in the payload.

> 2.      The beginning of the module has "prefix acl". Does it mean that "acl" is equivalent to "ietf-access-control-list"?

Essentially yes.
 
> file "ietf-access-control-list@2015-05-03.yang"
> module ietf-access-control-list {
> yang-version 1;
> namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
> prefix acl;
> 
> 
> 3.      With "prefix acl" listed right after the "namespace", does the acl in "ietf-acl:acl" (in Appendix A.1) actually mean the whole name space?
>

If you have in a YANG module

   import  {
     prefix foo;
   }

then you can refer to  defined in  via

   foo:

but if you declare the namespace of the module you are defining an
a prefix for it, that is

   module  {
     namespace ;
     prefix bar;

   }

and I (a) suggest that modules importing  should use the
prefix 'bar' and (b) I allow to refer inside  to things
defined in  using the prefix 'bar:' (which is however
usually not needed since you can simply omit the prefix for anything
locally defined).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Sep 24 19:33:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7311B3533 for ; Thu, 24 Sep 2015 19:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWbdry6kumHM for ; Thu, 24 Sep 2015 19:33:24 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 340F21B3531 for ; Thu, 24 Sep 2015 19:33:24 -0700 (PDT)
Received: by qgev79 with SMTP id v79so59995949qge.0 for ; Thu, 24 Sep 2015 19:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=59FQcA9m1KAPP3cuT2k1CoW6LYnMHOhznRichio0cYY=; b=xGWYCKsR0nwpqPXHLnx/e47uZur05FrtRt7fs4kpqqAB62NQ4PBrYUfQNRdgwsu6gP ax35ivgfYKyjDib9EcRqoc5+OIzVpX5U4zs8PMOAf2A32Xop4JBRiNHteykyLoBQUgMx AGSNScE/1vtfmxX+7YB4krRg2VB14XzjtfXp81tu4iCQ+tq3RLYIF043H559Ak/gKkn6 LlJfACguKSQm96c8XXOa+XdR6EPKLYPJI183uR8Xmd+Vq+6jSUFWEQcbFzQWZGilxLjL zarw/mkmdEATiexPJ3rl20q6WhSfeOwyMuddqlWh0USzaAHLHA+Z46sHw2rVir++Vr+c MxxA==
X-Received: by 10.140.98.54 with SMTP id n51mr3337669qge.75.1443148403349; Thu, 24 Sep 2015 19:33:23 -0700 (PDT)
Received: from [10.0.1.3] (c-73-234-145-200.hsd1.ma.comcast.net. [73.234.145.200]) by smtp.gmail.com with ESMTPSA id u81sm578688qku.47.2015.09.24.19.33.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Sep 2015 19:33:22 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Dean Bogdanovic 
In-Reply-To: <20150924212939.GA7113@elstar.local>
Date: Thu, 24 Sep 2015 22:33:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <67B793CC-7155-4877-A4E4-8BC88631C94F@gmail.com>
References: <4A95BA014132FF49AE685FAB4B9F17F657D61751@dfweml701-chm> <20150924212939.GA7113@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: draft-ietf-netmod-acl-model.all@tools.ietf.org, "ietf-access-control-list@2015-05-03.yang" , "netmod@ietf.org" 
Subject: Re: [netmod] more Questions about draft-ietf-netmod-acl-model-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 02:33:25 -0000

> On Sep 24, 2015, at 5:29 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Thu, Sep 24, 2015 at 08:51:45PM +0000, Linda Dunbar wrote:
>>=20
>> Dean, et al,
>>=20
>> I have a few questions about the draft:
>>=20
>> 1.      Does the following statement in the Section 7 IANA =
Consideration make  "ietf-acl" equivalent to the long name =
"urn:ietf:params:xml:ns:yang:ietf-access-control-list"?
>>=20
>> urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl
>>=20
>=20
> No. See RFC 6020 sections 7.1.3 and 7.1.4 how 'namespace' and 'prefix'
> statements work. The IANA section only registers the values declared
> in the YANG modules.
>=20
>> If the answer is YES, can the example in Section 4.3 can use =
"ietf-acl" directly instead of the long name?
>> i.e.
>> 
>=20
> The example does not match the YANG definition, it is broken.
>> Does the "1" in ":1.0" above mean "yang-version 1" defined in the =
"module ietf-access-control-list"?  what about the "0" a?
>=20
> The :1.0 likely should not be there. There is not tagging of the YANG
> language version used to define the data model in the payload

We have used pyang with -f sample-xml-skeleton and then updated it with =
the example info. I=E2=80=99ll update the pyang compiler and redo the =
output.=20

Dean
> .
>=20
>> 2.      The beginning of the module has "prefix acl". Does it mean =
that "acl" is equivalent to "ietf-access-control-list"?
>=20
> Essentially yes.
>=20
>> file "ietf-access-control-list@2015-05-03.yang"
>> module ietf-access-control-list {
>> yang-version 1;
>> namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
>> prefix acl;
>>=20
>>=20
>> 3.      With "prefix acl" listed right after the "namespace", does =
the acl in "ietf-acl:acl" (in Appendix A.1) actually mean the whole name =
space?
>>=20
>=20
> If you have in a YANG module
>=20
>   import  {
>     prefix foo;
>   }
>=20
> then you can refer to  defined in  via
>=20
>   foo:
>=20
> but if you declare the namespace of the module you are defining an
> a prefix for it, that is
>=20
>   module  {
>     namespace ;
>     prefix bar;
>=20
>   }
>=20
> and I (a) suggest that modules importing  should use the
> prefix 'bar' and (b) I allow to refer inside  to things
> defined in  using the prefix 'bar:' (which is however
> usually not needed since you can simply omit the prefix for anything
> locally defined).
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 25 00:58:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B33D1B2C0E for ; Fri, 25 Sep 2015 00:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUX1VnK-tlwF for ; Fri, 25 Sep 2015 00:58:18 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 575161A8547 for ; Fri, 25 Sep 2015 00:58:17 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 854311CC00B1; Fri, 25 Sep 2015 09:58:25 +0200 (CEST)
From: Ladislav Lhotka 
To: Jernej Tuljak , Martin Bjorklund 
In-Reply-To: <5603F0FE.6000808@mg-soft.si>
References: <560287D1.9050905@mg-soft.si>  <5603BEC4.8050803@mg-soft.si> <20150924.135449.1944322803447003762.mbj@tail-f.com> <5603F0FE.6000808@mg-soft.si>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 25 Sep 2015 09:58:16 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 07:58:21 -0000

Jernej Tuljak  writes:

> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>> Jernej Tuljak  wrote:
>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>> Jernej Tuljak  writes:
>>>>
>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>>>>
>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrot=
e:
>>>>>>>>>
>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation case
>>>>>>>>> does not consider that an "augment" may specify a top-level "choi=
ce"
>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the ta=
rget
>>>>>>>>> node. There will be no initial context node for the expression in=
 such
>>>>>>>>> a case.
>>>>>>>>>
>>>>>>>>>     leaf enable-foos {
>>>>>>>>>       type boolean;
>>>>>>>>>     }
>>>>>>>>>     choice ch1 {
>>>>>>>>>       case foo {
>>>>>>>>>         choice foos {
>>>>>>>>>           when "enable-foos =3D 'true'";
>>>>>>>>>           leaf foo1 {
>>>>>>>>>             type string;
>>>>>>>>>           }
>>>>>>>>>           leaf foo2 {
>>>>>>>>>             type string;
>>>>>>>>>           }
>>>>>>>>>         }
>>>>>>>>>       }
>>>>>>>>>       container meh;
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>>     augment "/ch1/foo/foos" {
>>>>>>>>>       when "enable-foos =3D 'true'";
>>>>>>>>>       leaf foo3 {
>>>>>>>>>         type string;
>>>>>>>>>       }
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> OLD:
>>>>>>>>>
>>>>>>>>>      o If the "when" statement is a child of an "augment" stateme=
nt,
>>>>>>>>>      then
>>>>>>>>>         the context node is the augment's target node in the data=
 tree,
>>>>>>>>>         if
>>>>>>>>>         the target node is a data node.  Otherwise, the context n=
ode is
>>>>>>>>>         the closest ancestor node to the target node that is also=
 a data
>>>>>>>>>         node.
>>>>>>>>>
>>>>>>>>> NEW:
>>>>>>>>>
>>>>>>>>>      o If the "when" statement is a child of an "augment" stateme=
nt,
>>>>>>>>>      then
>>>>>>>>>         the context node is the augment's target node in the data=
 tree,
>>>>>>>>>         if
>>>>>>>>>         the target node is a data node.  Otherwise, the context n=
ode is
>>>>>>>>>         the closest ancestor node to the target node that is also=
 a data
>>>>>>>>>         node. If no such node exists, the context node is the roo=
t node.
>>>>>>>>>
>>>>>>>> Good catch, I support this change.
>>>>>>>>
>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expressi=
on
>>>>>>>> must not reference nodes that are made conditional through that wh=
en
>>>>>>>> statement. I can=E2=80=99t find this rule in the text.
>>>>>>> The "no referencing the initial context node and its descendants" t=
ext
>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>> seriously broken and could lead to deadlocks.
>>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>>> node
>>>>> with no value and child nodes has been introduced.
>>>> Not really, the dummy node solves the problem of a non-existent
>>>> context
>>>> node.
>>> Are you referring to "existence" in the instance document or the
>>> schema tree? Why is there no need for "no children, no value dummy" in
>>> 1st and 2nd bullet?
>> In these cases, the context node is well-defined anyway.  But I think
>> that also these bullets need to have text that make sure that the
>> outcome is deterministic in all cases, such as:
>>
>>    augement /foo {
>>      when "bar > 1";
>>      leaf bar { type int32; }
>>    }
>>
>> or
>>
>>    grouping foo {
>>      leaf bar { type int32; }
>>    }
>>    container x {
>>      uses foo {
>>        when "bar > 1";
>>      }
>>    }
>>
>>
>> etc.
>>
>> So I suggest this NEW text:
>>
>>
>>     o  If the "when" statement is a child of an "augment" statement, then
>>        the context node is the augment's target node in the data tree, if
>>        the target node is a data node.  Otherwise, the context node is
>>        the closest ancestor node to the target node that is also a data
>>        node.  If no such node exists, the context node is the root node.
>>        The accessible tree is tentatively altered during the processing
>>        of the XPath expression by removing all instances (if any) of the
>>        nodes added by the "augment" statement.
>>
>>     o  If the "when" statement is a child of a "uses", "choice", or
>>        "case" statement, then the context node is the closest ancestor
>>        node to the "uses", "choice", or "case" node that is also a data
>>        node.  If no such node exists, the context node is the root node.
>>        The accessible tree is tentatively altered during the processing
>>        of the XPath expression by removing all instances (if any) of the
>>        nodes added by the "uses", "choice", or "case" statement.
>>
>>     o  If the "when" statement is a child of any other data definition
>>        statement, the accessible tree is tentatively altered during the
>>        processing of the XPath expression by replacing all instances (if
>>        any) of the data node for which the "when" statement is defined
>>        with a single dummy node with the same name, but with no value and
>>        no children.  The context node is this dummy node.
>>
>
> +1
>
>    container foo {
>      when "child::* or child::text() or not(self::*)"; // always false
>      leaf bar {
>        type string;
>      }
>    }

I think it would be better to clearly state that a "when" expression
MUST NOT refer to nodes that are made conditional by the same "when"
statement - it's similar to the rule that forbids mutual references.
This would also cover all uses of "when".

The above example would be really confusing if the "bar" instance is
present. I also don't like the fact that "when" and "must" would give
different results in this case.

Lada

>
> Jernej
>
>>
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 25 01:12:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627071B3606 for ; Fri, 25 Sep 2015 01:12: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] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df2ZcXUxdgef for ; Fri, 25 Sep 2015 01:12:26 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B27E51B2FA9 for ; Fri, 25 Sep 2015 01:12:26 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3D16A1CC00B1; Fri, 25 Sep 2015 10:12:34 +0200 (CEST)
From: Ladislav Lhotka 
To: Linda Dunbar , "'netmod\@ietf.org'" , "draft-ietf-netmod-acl-model.ll\@tools.ietf.org" 
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D61691@dfweml701-chm>
References: <4A95BA014132FF49AE685FAB4B9F17F657D61691@dfweml701-chm>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 25 Sep 2015 10:12:25 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Question about draft-ietf-netmod-acl-model-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 08:12:28 -0000

Linda Dunbar  writes:

> Dean, et al,
>
> Does the following statement in the Section 7 IANA Consideration make  "ietf-acl" equivalent to the long name "urn:ietf:params:xml:ns:yang:ietf-access-control-list"?
>
> urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl
>
>
> If the answer is YES, can the example in Section 4.3 can use "ietf-acl" directly instead of the long name?
> i.e.
>  
>
>
> What does the ":1.0" mean in the example?

That example is broken, it's not even well-formed XML.

It would be useful if module authors always validate such examples
before publishing an I-D. My skeleton project at GitHub shows how to
make such a validation an integral part of I-D processing - see the
Makefile:

https://github.com/llhotka/YANG-I-D

Lada


>
> Thanks, Linda
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 25 04:25:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A351B305F for ; Fri, 25 Sep 2015 04:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cetaYQkImU3s for ; Fri, 25 Sep 2015 04:25:15 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 79ED61B3046 for ; Fri, 25 Sep 2015 04:25:13 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id EE595C4175C1; Fri, 25 Sep 2015 13:25:09 +0200 (CEST)
To: Ladislav Lhotka , Martin Bjorklund 
References: <560287D1.9050905@mg-soft.si>  <5603BEC4.8050803@mg-soft.si> <20150924.135449.1944322803447003762.mbj@tail-f.com> <5603F0FE.6000808@mg-soft.si> 
From: Jernej Tuljak 
Message-ID: <56052F11.3010903@mg-soft.si>
Date: Fri, 25 Sep 2015 13:25:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090208020801090606030800"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 11:25:19 -0000

This is a multi-part message in MIME format.
--------------090208020801090606030800
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
> Jernej Tuljak  writes:
>
>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>>> Jernej Tuljak  wrote:
>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>>> Jernej Tuljak  writes:
>>>>>
>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>>>>>
>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>>>>>>
>>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation case
>>>>>>>>>> does not consider that an "augment" may specify a top-level "choice"
>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the target
>>>>>>>>>> node. There will be no initial context node for the expression in such
>>>>>>>>>> a case.
>>>>>>>>>>
>>>>>>>>>>      leaf enable-foos {
>>>>>>>>>>        type boolean;
>>>>>>>>>>      }
>>>>>>>>>>      choice ch1 {
>>>>>>>>>>        case foo {
>>>>>>>>>>          choice foos {
>>>>>>>>>>            when "enable-foos = 'true'";
>>>>>>>>>>            leaf foo1 {
>>>>>>>>>>              type string;
>>>>>>>>>>            }
>>>>>>>>>>            leaf foo2 {
>>>>>>>>>>              type string;
>>>>>>>>>>            }
>>>>>>>>>>          }
>>>>>>>>>>        }
>>>>>>>>>>        container meh;
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      augment "/ch1/foo/foos" {
>>>>>>>>>>        when "enable-foos = 'true'";
>>>>>>>>>>        leaf foo3 {
>>>>>>>>>>          type string;
>>>>>>>>>>        }
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>> OLD:
>>>>>>>>>>
>>>>>>>>>>       o If the "when" statement is a child of an "augment" statement,
>>>>>>>>>>       then
>>>>>>>>>>          the context node is the augment's target node in the data tree,
>>>>>>>>>>          if
>>>>>>>>>>          the target node is a data node.  Otherwise, the context node is
>>>>>>>>>>          the closest ancestor node to the target node that is also a data
>>>>>>>>>>          node.
>>>>>>>>>>
>>>>>>>>>> NEW:
>>>>>>>>>>
>>>>>>>>>>       o If the "when" statement is a child of an "augment" statement,
>>>>>>>>>>       then
>>>>>>>>>>          the context node is the augment's target node in the data tree,
>>>>>>>>>>          if
>>>>>>>>>>          the target node is a data node.  Otherwise, the context node is
>>>>>>>>>>          the closest ancestor node to the target node that is also a data
>>>>>>>>>>          node. If no such node exists, the context node is the root node.
>>>>>>>>>>
>>>>>>>>> Good catch, I support this change.
>>>>>>>>>
>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression
>>>>>>>>> must not reference nodes that are made conditional through that when
>>>>>>>>> statement. I can’t find this rule in the text.
>>>>>>>> The "no referencing the initial context node and its descendants" text
>>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>>> seriously broken and could lead to deadlocks.
>>>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>>>> node
>>>>>> with no value and child nodes has been introduced.
>>>>> Not really, the dummy node solves the problem of a non-existent
>>>>> context
>>>>> node.
>>>> Are you referring to "existence" in the instance document or the
>>>> schema tree? Why is there no need for "no children, no value dummy" in
>>>> 1st and 2nd bullet?
>>> In these cases, the context node is well-defined anyway.  But I think
>>> that also these bullets need to have text that make sure that the
>>> outcome is deterministic in all cases, such as:
>>>
>>>     augement /foo {
>>>       when "bar > 1";
>>>       leaf bar { type int32; }
>>>     }
>>>
>>> or
>>>
>>>     grouping foo {
>>>       leaf bar { type int32; }
>>>     }
>>>     container x {
>>>       uses foo {
>>>         when "bar > 1";
>>>       }
>>>     }
>>>
>>>
>>> etc.
>>>
>>> So I suggest this NEW text:
>>>
>>>
>>>      o  If the "when" statement is a child of an "augment" statement, then
>>>         the context node is the augment's target node in the data tree, if
>>>         the target node is a data node.  Otherwise, the context node is
>>>         the closest ancestor node to the target node that is also a data
>>>         node.  If no such node exists, the context node is the root node.
>>>         The accessible tree is tentatively altered during the processing
>>>         of the XPath expression by removing all instances (if any) of the
>>>         nodes added by the "augment" statement.
>>>
>>>      o  If the "when" statement is a child of a "uses", "choice", or
>>>         "case" statement, then the context node is the closest ancestor
>>>         node to the "uses", "choice", or "case" node that is also a data
>>>         node.  If no such node exists, the context node is the root node.
>>>         The accessible tree is tentatively altered during the processing
>>>         of the XPath expression by removing all instances (if any) of the
>>>         nodes added by the "uses", "choice", or "case" statement.
>>>
>>>      o  If the "when" statement is a child of any other data definition
>>>         statement, the accessible tree is tentatively altered during the
>>>         processing of the XPath expression by replacing all instances (if
>>>         any) of the data node for which the "when" statement is defined
>>>         with a single dummy node with the same name, but with no value and
>>>         no children.  The context node is this dummy node.
>>>
>> +1
>>
>>     container foo {
>>       when "child::* or child::text() or not(self::*)"; // always false
>>       leaf bar {
>>         type string;
>>       }
>>     }
> I think it would be better to clearly state that a "when" expression
> MUST NOT refer to nodes that are made conditional by the same "when"
> statement - it's similar to the rule that forbids mutual references.
> This would also cover all uses of "when".
>
> The above example would be really confusing if the "bar" instance is
> present.

It is true that this introduces a caveat that is bound to confuse end 
YANG users.

>   I also don't like the fact that "when" and "must" would give
> different results in this case.

Just to be clear, you would like this, right?

NEW:

    The XPath expression is conceptually evaluated in the following
    context, in addition to the definition inSection 6.4.1 
:

    o  If the "when" statement is a child of an "augment" statement, then
       the context node is the augment's target node in the data tree, if
       the target node is a data node.  Otherwise, the context node is
       the closest ancestor node to the target node that is also a data
       node. If no such node exists, the context node is the root node.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.

    o  If the "when" statement is a child of any other data definition
       statement, the context node is the node in the accessible tree for
       which the "when" statement is defined.
    
    An XPath expression MUST NOT reference nodes that are made conditional
    by the "when" statement that defines it.

I don't see a case in which the context node is non-existent (in the 
schema tree) in any of the three bullets, even without "no value, no 
descendants" dummy node.

This text implies that:

   container foo {
     when "descendant-or-self::node()"; // semantic error
     leaf bar {
       type string;
     }
   }

This is actually what our YANG 1.0 implementation currently does, though 
it only generates a warning.

Jernej

>
> Lada
>
>> Jernej
>>
>>> /martin
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


--------------090208020801090606030800
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Ladislav Lhotka je 25.9.2015 ob
      9:58 napisal:

    

    

      
Jernej Tuljak <jernejt@mg-soft.si> writes:



      

        
Martin Bjorklund je 24.9.2015 ob 13:54 napisal:


        

          
Jernej Tuljak <jernejt@mg-soft.si> wrote:


          

            
Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:


            

              
Jernej Tuljak <jernejt@mg-soft.si> writes:



              

                
Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:


                

                  

                    
On 23 Sep 2015, at 12:37, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:


                    

                      

                        
On 23 Sep 2015, at 11:45, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Section 7.21.5., the first bullet describing the augmentation case
does not consider that an "augment" may specify a top-level "choice"
or a "choice"/"case" nested within a top-level "choice" as the target
node. There will be no initial context node for the expression in such
a case.

    leaf enable-foos {
      type boolean;
    }
    choice ch1 {
      case foo {
        choice foos {
          when "enable-foos = 'true'";
          leaf foo1 {
            type string;
          }
          leaf foo2 {
            type string;
          }
        }
      }
      container meh;
    }

    augment "/ch1/foo/foos" {
      when "enable-foos = 'true'";
      leaf foo3 {
        type string;
      }
    }

OLD:

     o If the "when" statement is a child of an "augment" statement,
     then
        the context node is the augment's target node in the data tree,
        if
        the target node is a data node.  Otherwise, the context node is
        the closest ancestor node to the target node that is also a data
        node.

NEW:

     o If the "when" statement is a child of an "augment" statement,
     then
        the context node is the augment's target node in the data tree,
        if
        the target node is a data node.  Otherwise, the context node is
        the closest ancestor node to the target node that is also a data
        node. If no such node exists, the context node is the root node.



                      

                      
Good catch, I support this change.

Also regarding sec. 7.21.5, I think we agreed that a when expression
must not reference nodes that are made conditional through that when
statement. I can’t find this rule in the text.


                    

                    
The "no referencing the initial context node and its descendants" text
is currently in the guidelines draft only (6087bis).


                  

                  
IMO this should be a hard rule in 6020bis. Such expressions are
seriously broken and could lead to deadlocks.


                

                
I think that was the purpose of the change in 3rd bullet. A "dummy"
node
with no value and child nodes has been introduced.


              

              
Not really, the dummy node solves the problem of a non-existent
context
node.


            

            
Are you referring to "existence" in the instance document or the
schema tree? Why is there no need for "no children, no value dummy" in
1st and 2nd bullet?


          

          
In these cases, the context node is well-defined anyway.  But I think
that also these bullets need to have text that make sure that the
outcome is deterministic in all cases, such as:

   augement /foo {
     when "bar > 1";
     leaf bar { type int32; }
   }

or

   grouping foo {
     leaf bar { type int32; }
   }
   container x {
     uses foo {
       when "bar > 1";
     }
   }


etc.

So I suggest this NEW text:


    o  If the "when" statement is a child of an "augment" statement, then
       the context node is the augment's target node in the data tree, if
       the target node is a data node.  Otherwise, the context node is
       the closest ancestor node to the target node that is also a data
       node.  If no such node exists, the context node is the root node.
       The accessible tree is tentatively altered during the processing
       of the XPath expression by removing all instances (if any) of the
       nodes added by the "augment" statement.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.
       The accessible tree is tentatively altered during the processing
       of the XPath expression by removing all instances (if any) of the
       nodes added by the "uses", "choice", or "case" statement.

    o  If the "when" statement is a child of any other data definition
       statement, the accessible tree is tentatively altered during the
       processing of the XPath expression by replacing all instances (if
       any) of the data node for which the "when" statement is defined
       with a single dummy node with the same name, but with no value and
       no children.  The context node is this dummy node.



        

        
+1

   container foo {
     when "child::* or child::text() or not(self::*)"; // always false
     leaf bar {
       type string;
     }
   }


      

      
I think it would be better to clearly state that a "when" expression
MUST NOT refer to nodes that are made conditional by the same "when"
statement - it's similar to the rule that forbids mutual references.
This would also cover all uses of "when".

The above example would be really confusing if the "bar" instance is
present.

    

    

    It is true that this introduces a caveat that is bound to confuse
    end YANG users.

    

    

      
 I also don't like the fact that "when" and "must" would give
different results in this case.

    

    

    Just to be clear, you would like this, right?

    

    NEW:

    
   The XPath expression is conceptually evaluated in the following
   context, in addition to the definition in Section 6.4.1:

   o  If the "when" statement is a child of an "augment" statement, then
      the context node is the augment's target node in the data tree, if
      the target node is a data node.  Otherwise, the context node is
      the closest ancestor node to the target node that is also a data
      node. If no such node exists, the context node is the root node.

   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the "uses", "choice", or "case" node that is also a data
      node.  If no such node exists, the context node is the root node.

   o  If the "when" statement is a child of any other data definition
      statement, the context node is the node in the accessible tree for
      which the "when" statement is defined.
   
   An XPath expression MUST NOT reference nodes that are made conditional
   by the "when" statement that defines it. 


    I don't see a case in which the context node is non-existent (in the
    schema tree) in any of the three bullets, even without "no value, no
    descendants" dummy node.

    

    This text implies that:

    

      container foo {
    

        when "descendant-or-self::node()"; // semantic error
    

        leaf bar {
    

          type string;
    

        }
    

      }
    

    

    This is actually what our YANG 1.0 implementation currently does,
    though it only generates a warning.

    

    Jernej

    

    

      

Lada



      

        
Jernej



        

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


        

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


      

      

    

    

  


--------------090208020801090606030800--


From nobody Fri Sep 25 04:41:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D25E1B306F for ; Fri, 25 Sep 2015 04:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzABHabu3PJ9 for ; Fri, 25 Sep 2015 04:41:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 865E31B307E for ; Fri, 25 Sep 2015 04:41:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 96D4E1AE0977; Fri, 25 Sep 2015 13:41:10 +0200 (CEST)
Date: Fri, 25 Sep 2015 13:41:10 +0200 (CEST)
Message-Id: <20150925.134110.1680423075885764349.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20150924.135449.1944322803447003762.mbj@tail-f.com> <5603F0FE.6000808@mg-soft.si> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 11:41:30 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSmVybmVqIFR1bGphayA8
amVybmVqdEBtZy1zb2Z0LnNpPiB3cml0ZXM6DQo+IA0KPiA+IE1hcnRpbiBCam9ya2x1bmQgamUg
MjQuOS4yMDE1IG9iIDEzOjU0IG5hcGlzYWw6DQo+ID4+IEplcm5laiBUdWxqYWsgPGplcm5lanRA
bWctc29mdC5zaT4gd3JvdGU6DQo+ID4+PiBMYWRpc2xhdiBMaG90a2EgamUgMjMuOS4yMDE1IG9i
IDE0OjI5IG5hcGlzYWw6DQo+ID4+Pj4gSmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNp
PiB3cml0ZXM6DQo+ID4+Pj4NCj4gPj4+Pj4gTGFkaXNsYXYgTGhvdGthIGplIDIzLjkuMjAxNSBv
YiAxMjo1MiBuYXBpc2FsOg0KPiA+Pj4+Pj4+IE9uIDIzIFNlcCAyMDE1LCBhdCAxMjozNywgSmVy
bmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+Pj4+
Pj4+IExhZGlzbGF2IExob3RrYSBqZSAyMy45LjIwMTUgb2IgMTE6NTggbmFwaXNhbDoNCj4gPj4+
Pj4+Pj4+IE9uIDIzIFNlcCAyMDE1LCBhdCAxMTo0NSwgSmVybmVqIFR1bGphayA8amVybmVqdEBt
Zy1zb2Z0LnNpPiB3cm90ZToNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBTZWN0aW9uIDcuMjEu
NS4sIHRoZSBmaXJzdCBidWxsZXQgZGVzY3JpYmluZyB0aGUgYXVnbWVudGF0aW9uIGNhc2UNCj4g
Pj4+Pj4+Pj4+IGRvZXMgbm90IGNvbnNpZGVyIHRoYXQgYW4gImF1Z21lbnQiIG1heSBzcGVjaWZ5
IGEgdG9wLWxldmVsICJjaG9pY2UiDQo+ID4+Pj4+Pj4+PiBvciBhICJjaG9pY2UiLyJjYXNlIiBu
ZXN0ZWQgd2l0aGluIGEgdG9wLWxldmVsICJjaG9pY2UiIGFzIHRoZSB0YXJnZXQNCj4gPj4+Pj4+
Pj4+IG5vZGUuIFRoZXJlIHdpbGwgYmUgbm8gaW5pdGlhbCBjb250ZXh0IG5vZGUgZm9yIHRoZSBl
eHByZXNzaW9uIGluIHN1Y2gNCj4gPj4+Pj4+Pj4+IGEgY2FzZS4NCj4gPj4+Pj4+Pj4+DQo+ID4+
Pj4+Pj4+PiAgICAgbGVhZiBlbmFibGUtZm9vcyB7DQo+ID4+Pj4+Pj4+PiAgICAgICB0eXBlIGJv
b2xlYW47DQo+ID4+Pj4+Pj4+PiAgICAgfQ0KPiA+Pj4+Pj4+Pj4gICAgIGNob2ljZSBjaDEgew0K
PiA+Pj4+Pj4+Pj4gICAgICAgY2FzZSBmb28gew0KPiA+Pj4+Pj4+Pj4gICAgICAgICBjaG9pY2Ug
Zm9vcyB7DQo+ID4+Pj4+Pj4+PiAgICAgICAgICAgd2hlbiAiZW5hYmxlLWZvb3MgPSAndHJ1ZSci
Ow0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgIGxlYWYgZm9vMSB7DQo+ID4+Pj4+Pj4+PiAgICAgICAg
ICAgICB0eXBlIHN0cmluZzsNCj4gPj4+Pj4+Pj4+ICAgICAgICAgICB9DQo+ID4+Pj4+Pj4+PiAg
ICAgICAgICAgbGVhZiBmb28yIHsNCj4gPj4+Pj4+Pj4+ICAgICAgICAgICAgIHR5cGUgc3RyaW5n
Ow0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgIH0NCj4gPj4+Pj4+Pj4+ICAgICAgICAgfQ0KPiA+Pj4+
Pj4+Pj4gICAgICAgfQ0KPiA+Pj4+Pj4+Pj4gICAgICAgY29udGFpbmVyIG1laDsNCj4gPj4+Pj4+
Pj4+ICAgICB9DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gICAgIGF1Z21lbnQgIi9jaDEvZm9v
L2Zvb3MiIHsNCj4gPj4+Pj4+Pj4+ICAgICAgIHdoZW4gImVuYWJsZS1mb29zID0gJ3RydWUnIjsN
Cj4gPj4+Pj4+Pj4+ICAgICAgIGxlYWYgZm9vMyB7DQo+ID4+Pj4+Pj4+PiAgICAgICAgIHR5cGUg
c3RyaW5nOw0KPiA+Pj4+Pj4+Pj4gICAgICAgfQ0KPiA+Pj4+Pj4+Pj4gICAgIH0NCj4gPj4+Pj4+
Pj4+DQo+ID4+Pj4+Pj4+PiBPTEQ6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gICAgICBvIElm
IHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVu
dCwNCj4gPj4+Pj4+Pj4+ICAgICAgdGhlbg0KPiA+Pj4+Pj4+Pj4gICAgICAgICB0aGUgY29udGV4
dCBub2RlIGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwNCj4g
Pj4+Pj4+Pj4+ICAgICAgICAgaWYNCj4gPj4+Pj4+Pj4+ICAgICAgICAgdGhlIHRhcmdldCBub2Rl
IGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0aGUgY29udGV4dCBub2RlIGlzDQo+ID4+Pj4+
Pj4+PiAgICAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2Rl
IHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gPj4+Pj4+Pj4+ICAgICAgICAgbm9kZS4NCj4gPj4+Pj4+
Pj4+DQo+ID4+Pj4+Pj4+PiBORVc6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gICAgICBvIElm
IHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVu
dCwNCj4gPj4+Pj4+Pj4+ICAgICAgdGhlbg0KPiA+Pj4+Pj4+Pj4gICAgICAgICB0aGUgY29udGV4
dCBub2RlIGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwNCj4g
Pj4+Pj4+Pj4+ICAgICAgICAgaWYNCj4gPj4+Pj4+Pj4+ICAgICAgICAgdGhlIHRhcmdldCBub2Rl
IGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0aGUgY29udGV4dCBub2RlIGlzDQo+ID4+Pj4+
Pj4+PiAgICAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2Rl
IHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gPj4+Pj4+Pj4+ICAgICAgICAgbm9kZS4gSWYgbm8gc3Vj
aCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgcm9vdCBub2RlLg0KPiA+Pj4+
Pj4+Pj4NCj4gPj4+Pj4+Pj4gR29vZCBjYXRjaCwgSSBzdXBwb3J0IHRoaXMgY2hhbmdlLg0KPiA+
Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBbHNvIHJlZ2FyZGluZyBzZWMuIDcuMjEuNSwgSSB0aGluayB3
ZSBhZ3JlZWQgdGhhdCBhIHdoZW4gZXhwcmVzc2lvbg0KPiA+Pj4+Pj4+PiBtdXN0IG5vdCByZWZl
cmVuY2Ugbm9kZXMgdGhhdCBhcmUgbWFkZSBjb25kaXRpb25hbCB0aHJvdWdoIHRoYXQgd2hlbg0K
PiA+Pj4+Pj4+PiBzdGF0ZW1lbnQuIEkgY2Fu4oCZdCBmaW5kIHRoaXMgcnVsZSBpbiB0aGUgdGV4
dC4NCj4gPj4+Pj4+PiBUaGUgIm5vIHJlZmVyZW5jaW5nIHRoZSBpbml0aWFsIGNvbnRleHQgbm9k
ZSBhbmQgaXRzIGRlc2NlbmRhbnRzIiB0ZXh0DQo+ID4+Pj4+Pj4gaXMgY3VycmVudGx5IGluIHRo
ZSBndWlkZWxpbmVzIGRyYWZ0IG9ubHkgKDYwODdiaXMpLg0KPiA+Pj4+Pj4gSU1PIHRoaXMgc2hv
dWxkIGJlIGEgaGFyZCBydWxlIGluIDYwMjBiaXMuIFN1Y2ggZXhwcmVzc2lvbnMgYXJlDQo+ID4+
Pj4+PiBzZXJpb3VzbHkgYnJva2VuIGFuZCBjb3VsZCBsZWFkIHRvIGRlYWRsb2Nrcy4NCj4gPj4+
Pj4gSSB0aGluayB0aGF0IHdhcyB0aGUgcHVycG9zZSBvZiB0aGUgY2hhbmdlIGluIDNyZCBidWxs
ZXQuIEEgImR1bW15Ig0KPiA+Pj4+PiBub2RlDQo+ID4+Pj4+IHdpdGggbm8gdmFsdWUgYW5kIGNo
aWxkIG5vZGVzIGhhcyBiZWVuIGludHJvZHVjZWQuDQo+ID4+Pj4gTm90IHJlYWxseSwgdGhlIGR1
bW15IG5vZGUgc29sdmVzIHRoZSBwcm9ibGVtIG9mIGEgbm9uLWV4aXN0ZW50DQo+ID4+Pj4gY29u
dGV4dA0KPiA+Pj4+IG5vZGUuDQo+ID4+PiBBcmUgeW91IHJlZmVycmluZyB0byAiZXhpc3RlbmNl
IiBpbiB0aGUgaW5zdGFuY2UgZG9jdW1lbnQgb3IgdGhlDQo+ID4+PiBzY2hlbWEgdHJlZT8gV2h5
IGlzIHRoZXJlIG5vIG5lZWQgZm9yICJubyBjaGlsZHJlbiwgbm8gdmFsdWUgZHVtbXkiIGluDQo+
ID4+PiAxc3QgYW5kIDJuZCBidWxsZXQ/DQo+ID4+IEluIHRoZXNlIGNhc2VzLCB0aGUgY29udGV4
dCBub2RlIGlzIHdlbGwtZGVmaW5lZCBhbnl3YXkuICBCdXQgSSB0aGluaw0KPiA+PiB0aGF0IGFs
c28gdGhlc2UgYnVsbGV0cyBuZWVkIHRvIGhhdmUgdGV4dCB0aGF0IG1ha2Ugc3VyZSB0aGF0IHRo
ZQ0KPiA+PiBvdXRjb21lIGlzIGRldGVybWluaXN0aWMgaW4gYWxsIGNhc2VzLCBzdWNoIGFzOg0K
PiA+Pg0KPiA+PiAgICBhdWdlbWVudCAvZm9vIHsNCj4gPj4gICAgICB3aGVuICJiYXIgPiAxIjsN
Cj4gPj4gICAgICBsZWFmIGJhciB7IHR5cGUgaW50MzI7IH0NCj4gPj4gICAgfQ0KPiA+Pg0KPiA+
PiBvcg0KPiA+Pg0KPiA+PiAgICBncm91cGluZyBmb28gew0KPiA+PiAgICAgIGxlYWYgYmFyIHsg
dHlwZSBpbnQzMjsgfQ0KPiA+PiAgICB9DQo+ID4+ICAgIGNvbnRhaW5lciB4IHsNCj4gPj4gICAg
ICB1c2VzIGZvbyB7DQo+ID4+ICAgICAgICB3aGVuICJiYXIgPiAxIjsNCj4gPj4gICAgICB9DQo+
ID4+ICAgIH0NCj4gPj4NCj4gPj4NCj4gPj4gZXRjLg0KPiA+Pg0KPiA+PiBTbyBJIHN1Z2dlc3Qg
dGhpcyBORVcgdGV4dDoNCj4gPj4NCj4gPj4NCj4gPj4gICAgIG8gIElmIHRoZSAid2hlbiIgc3Rh
dGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVudCwgdGhlbg0KPiA+PiAg
ICAgICAgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgYXVnbWVudCdzIHRhcmdldCBub2RlIGluIHRo
ZSBkYXRhIHRyZWUsIGlmDQo+ID4+ICAgICAgICB0aGUgdGFyZ2V0IG5vZGUgaXMgYSBkYXRhIG5v
ZGUuICBPdGhlcndpc2UsIHRoZSBjb250ZXh0IG5vZGUgaXMNCj4gPj4gICAgICAgIHRoZSBjbG9z
ZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMgYWxzbyBhIGRhdGEN
Cj4gPj4gICAgICAgIG5vZGUuICBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBu
b2RlIGlzIHRoZSByb290IG5vZGUuDQo+ID4+ICAgICAgICBUaGUgYWNjZXNzaWJsZSB0cmVlIGlz
IHRlbnRhdGl2ZWx5IGFsdGVyZWQgZHVyaW5nIHRoZSBwcm9jZXNzaW5nDQo+ID4+ICAgICAgICBv
ZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBieSByZW1vdmluZyBhbGwgaW5zdGFuY2VzIChpZiBhbnkp
IG9mIHRoZQ0KPiA+PiAgICAgICAgbm9kZXMgYWRkZWQgYnkgdGhlICJhdWdtZW50IiBzdGF0ZW1l
bnQuDQo+ID4+DQo+ID4+ICAgICBvICBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxk
IG9mIGEgInVzZXMiLCAiY2hvaWNlIiwgb3INCj4gPj4gICAgICAgICJjYXNlIiBzdGF0ZW1lbnQs
IHRoZW4gdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgY2xvc2VzdCBhbmNlc3Rvcg0KPiA+PiAgICAg
ICAgbm9kZSB0byB0aGUgInVzZXMiLCAiY2hvaWNlIiwgb3IgImNhc2UiIG5vZGUgdGhhdCBpcyBh
bHNvIGEgZGF0YQ0KPiA+PiAgICAgICAgbm9kZS4gIElmIG5vIHN1Y2ggbm9kZSBleGlzdHMsIHRo
ZSBjb250ZXh0IG5vZGUgaXMgdGhlIHJvb3Qgbm9kZS4NCj4gPj4gICAgICAgIFRoZSBhY2Nlc3Np
YmxlIHRyZWUgaXMgdGVudGF0aXZlbHkgYWx0ZXJlZCBkdXJpbmcgdGhlIHByb2Nlc3NpbmcNCj4g
Pj4gICAgICAgIG9mIHRoZSBYUGF0aCBleHByZXNzaW9uIGJ5IHJlbW92aW5nIGFsbCBpbnN0YW5j
ZXMgKGlmIGFueSkgb2YgdGhlDQo+ID4+ICAgICAgICBub2RlcyBhZGRlZCBieSB0aGUgInVzZXMi
LCAiY2hvaWNlIiwgb3IgImNhc2UiIHN0YXRlbWVudC4NCj4gPj4NCj4gPj4gICAgIG8gIElmIHRo
ZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW55IG90aGVyIGRhdGEgZGVmaW5pdGlv
bg0KPiA+PiAgICAgICAgc3RhdGVtZW50LCB0aGUgYWNjZXNzaWJsZSB0cmVlIGlzIHRlbnRhdGl2
ZWx5IGFsdGVyZWQgZHVyaW5nIHRoZQ0KPiA+PiAgICAgICAgcHJvY2Vzc2luZyBvZiB0aGUgWFBh
dGggZXhwcmVzc2lvbiBieSByZXBsYWNpbmcgYWxsIGluc3RhbmNlcyAoaWYNCj4gPj4gICAgICAg
IGFueSkgb2YgdGhlIGRhdGEgbm9kZSBmb3Igd2hpY2ggdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMg
ZGVmaW5lZA0KPiA+PiAgICAgICAgd2l0aCBhIHNpbmdsZSBkdW1teSBub2RlIHdpdGggdGhlIHNh
bWUgbmFtZSwgYnV0IHdpdGggbm8gdmFsdWUgYW5kDQo+ID4+ICAgICAgICBubyBjaGlsZHJlbi4g
IFRoZSBjb250ZXh0IG5vZGUgaXMgdGhpcyBkdW1teSBub2RlLg0KPiA+Pg0KPiA+DQo+ID4gKzEN
Cj4gPg0KPiA+ICAgIGNvbnRhaW5lciBmb28gew0KPiA+ICAgICAgd2hlbiAiY2hpbGQ6Oiogb3Ig
Y2hpbGQ6OnRleHQoKSBvciBub3Qoc2VsZjo6KikiOyAvLyBhbHdheXMgZmFsc2UNCj4gPiAgICAg
IGxlYWYgYmFyIHsNCj4gPiAgICAgICAgdHlwZSBzdHJpbmc7DQo+ID4gICAgICB9DQo+ID4gICAg
fQ0KPiANCj4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2xlYXJseSBzdGF0ZSB0aGF0
IGEgIndoZW4iIGV4cHJlc3Npb24NCj4gTVVTVCBOT1QgcmVmZXIgdG8gbm9kZXMgdGhhdCBhcmUg
bWFkZSBjb25kaXRpb25hbCBieSB0aGUgc2FtZSAid2hlbiINCj4gc3RhdGVtZW50IC0gaXQncyBz
aW1pbGFyIHRvIHRoZSBydWxlIHRoYXQgZm9yYmlkcyBtdXR1YWwgcmVmZXJlbmNlcy4NCj4gVGhp
cyB3b3VsZCBhbHNvIGNvdmVyIGFsbCB1c2VzIG9mICJ3aGVuIi4NCg0KU28gd2hhdCBkb2VzIHRo
aXMgbWVhbjoNCg0KICBhdWdtZW50IC9hL2IvYyB7DQogICAgd2hlbiAiKiA9IDQyIjsNCiAgICBs
ZWFmIGZvbyB7DQogICAgICB0eXBlIGludDMyOw0KICAgIH0NCiAgfQ0KDQpJcyB0aGlzIGFuIGVy
cm9yLCBzaW5jZSB0aGUgIioiIHJlZmVyZW5jZXMgYSBub2RlIG1hZGUgY29uZGl0aW9uYWw/DQoN
Cg0KPiBUaGUgYWJvdmUgZXhhbXBsZSB3b3VsZCBiZSByZWFsbHkgY29uZnVzaW5nIGlmIHRoZSAi
YmFyIiBpbnN0YW5jZSBpcw0KPiBwcmVzZW50LiBJIGFsc28gZG9uJ3QgbGlrZSB0aGUgZmFjdCB0
aGF0ICJ3aGVuIiBhbmQgIm11c3QiIHdvdWxkIGdpdmUNCj4gZGlmZmVyZW50IHJlc3VsdHMgaW4g
dGhpcyBjYXNlLg0KDQpJIGFncmVlLCBidXQgT1RPSCB3ZSdyZSB0YWxraW5nIGFib3V0IGEgdGhl
b3JldGljYWwgY29ybmVyIGNhc2UuDQoNCg0KL21hcnRpbg0KDQoNCg0KDQo+IA0KPiBMYWRhDQo+
IA0KPiA+DQo+ID4gSmVybmVqDQo+ID4NCj4gPj4NCj4gPj4gL21hcnRpbg0KPiA+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBuZXRtb2QgbWFp
bGluZyBsaXN0DQo+ID4+IG5ldG1vZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4g
bmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCj4gDQo+IC0tIA0KPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+IFBH
UCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0K


From nobody Fri Sep 25 04:44:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD181B3084 for ; Fri, 25 Sep 2015 04:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywkSS9A77o13 for ; Fri, 25 Sep 2015 04:44:44 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 561531B3081 for ; Fri, 25 Sep 2015 04:44:43 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5900A1CC0049; Fri, 25 Sep 2015 13:44:51 +0200 (CEST)
From: Ladislav Lhotka 
To: Jernej Tuljak , Martin Bjorklund 
In-Reply-To: <56052F11.3010903@mg-soft.si>
References: <560287D1.9050905@mg-soft.si>  <5603BEC4.8050803@mg-soft.si> <20150924.135449.1944322803447003762.mbj@tail-f.com> <5603F0FE.6000808@mg-soft.si>  <56052F11.3010903@mg-soft.si>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 25 Sep 2015 13:44:39 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 11:44:47 -0000

Jernej Tuljak  writes:

> Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
>> Jernej Tuljak  writes:
>>
>>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>>>> Jernej Tuljak  wrote:
>>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>>>> Jernej Tuljak  writes:
>>>>>>
>>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrot=
e:
>>>>>>>>>
>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wr=
ote:
>>>>>>>>>>>
>>>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation c=
ase
>>>>>>>>>>> does not consider that an "augment" may specify a top-level "ch=
oice"
>>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the =
target
>>>>>>>>>>> node. There will be no initial context node for the expression =
in such
>>>>>>>>>>> a case.
>>>>>>>>>>>
>>>>>>>>>>>      leaf enable-foos {
>>>>>>>>>>>        type boolean;
>>>>>>>>>>>      }
>>>>>>>>>>>      choice ch1 {
>>>>>>>>>>>        case foo {
>>>>>>>>>>>          choice foos {
>>>>>>>>>>>            when "enable-foos =3D 'true'";
>>>>>>>>>>>            leaf foo1 {
>>>>>>>>>>>              type string;
>>>>>>>>>>>            }
>>>>>>>>>>>            leaf foo2 {
>>>>>>>>>>>              type string;
>>>>>>>>>>>            }
>>>>>>>>>>>          }
>>>>>>>>>>>        }
>>>>>>>>>>>        container meh;
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      augment "/ch1/foo/foos" {
>>>>>>>>>>>        when "enable-foos =3D 'true'";
>>>>>>>>>>>        leaf foo3 {
>>>>>>>>>>>          type string;
>>>>>>>>>>>        }
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>> OLD:
>>>>>>>>>>>
>>>>>>>>>>>       o If the "when" statement is a child of an "augment" stat=
ement,
>>>>>>>>>>>       then
>>>>>>>>>>>          the context node is the augment's target node in the d=
ata tree,
>>>>>>>>>>>          if
>>>>>>>>>>>          the target node is a data node.  Otherwise, the contex=
t node is
>>>>>>>>>>>          the closest ancestor node to the target node that is a=
lso a data
>>>>>>>>>>>          node.
>>>>>>>>>>>
>>>>>>>>>>> NEW:
>>>>>>>>>>>
>>>>>>>>>>>       o If the "when" statement is a child of an "augment" stat=
ement,
>>>>>>>>>>>       then
>>>>>>>>>>>          the context node is the augment's target node in the d=
ata tree,
>>>>>>>>>>>          if
>>>>>>>>>>>          the target node is a data node.  Otherwise, the contex=
t node is
>>>>>>>>>>>          the closest ancestor node to the target node that is a=
lso a data
>>>>>>>>>>>          node. If no such node exists, the context node is the =
root node.
>>>>>>>>>>>
>>>>>>>>>> Good catch, I support this change.
>>>>>>>>>>
>>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expres=
sion
>>>>>>>>>> must not reference nodes that are made conditional through that =
when
>>>>>>>>>> statement. I can=E2=80=99t find this rule in the text.
>>>>>>>>> The "no referencing the initial context node and its descendants"=
 text
>>>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>>>> seriously broken and could lead to deadlocks.
>>>>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>>>>> node
>>>>>>> with no value and child nodes has been introduced.
>>>>>> Not really, the dummy node solves the problem of a non-existent
>>>>>> context
>>>>>> node.
>>>>> Are you referring to "existence" in the instance document or the
>>>>> schema tree? Why is there no need for "no children, no value dummy" in
>>>>> 1st and 2nd bullet?
>>>> In these cases, the context node is well-defined anyway.  But I think
>>>> that also these bullets need to have text that make sure that the
>>>> outcome is deterministic in all cases, such as:
>>>>
>>>>     augement /foo {
>>>>       when "bar > 1";
>>>>       leaf bar { type int32; }
>>>>     }
>>>>
>>>> or
>>>>
>>>>     grouping foo {
>>>>       leaf bar { type int32; }
>>>>     }
>>>>     container x {
>>>>       uses foo {
>>>>         when "bar > 1";
>>>>       }
>>>>     }
>>>>
>>>>
>>>> etc.
>>>>
>>>> So I suggest this NEW text:
>>>>
>>>>
>>>>      o  If the "when" statement is a child of an "augment" statement, =
then
>>>>         the context node is the augment's target node in the data tree=
, if
>>>>         the target node is a data node.  Otherwise, the context node is
>>>>         the closest ancestor node to the target node that is also a da=
ta
>>>>         node.  If no such node exists, the context node is the root no=
de.
>>>>         The accessible tree is tentatively altered during the processi=
ng
>>>>         of the XPath expression by removing all instances (if any) of =
the
>>>>         nodes added by the "augment" statement.
>>>>
>>>>      o  If the "when" statement is a child of a "uses", "choice", or
>>>>         "case" statement, then the context node is the closest ancestor
>>>>         node to the "uses", "choice", or "case" node that is also a da=
ta
>>>>         node.  If no such node exists, the context node is the root no=
de.
>>>>         The accessible tree is tentatively altered during the processi=
ng
>>>>         of the XPath expression by removing all instances (if any) of =
the
>>>>         nodes added by the "uses", "choice", or "case" statement.
>>>>
>>>>      o  If the "when" statement is a child of any other data definition
>>>>         statement, the accessible tree is tentatively altered during t=
he
>>>>         processing of the XPath expression by replacing all instances =
(if
>>>>         any) of the data node for which the "when" statement is defined
>>>>         with a single dummy node with the same name, but with no value=
 and
>>>>         no children.  The context node is this dummy node.
>>>>
>>> +1
>>>
>>>     container foo {
>>>       when "child::* or child::text() or not(self::*)"; // always false
>>>       leaf bar {
>>>         type string;
>>>       }
>>>     }
>> I think it would be better to clearly state that a "when" expression
>> MUST NOT refer to nodes that are made conditional by the same "when"
>> statement - it's similar to the rule that forbids mutual references.
>> This would also cover all uses of "when".
>>
>> The above example would be really confusing if the "bar" instance is
>> present.
>
> It is true that this introduces a caveat that is bound to confuse end=20
> YANG users.
>
>>   I also don't like the fact that "when" and "must" would give
>> different results in this case.
>
> Just to be clear, you would like this, right?
>
> NEW:
>
>     The XPath expression is conceptually evaluated in the following
>     context, in addition to the definition inSection 6.4.1=20
> :
>
>     o  If the "when" statement is a child of an "augment" statement, then
>        the context node is the augment's target node in the data tree, if
>        the target node is a data node.  Otherwise, the context node is
>        the closest ancestor node to the target node that is also a data
>        node. If no such node exists, the context node is the root node.
>
>     o  If the "when" statement is a child of a "uses", "choice", or
>        "case" statement, then the context node is the closest ancestor
>        node to the "uses", "choice", or "case" node that is also a data
>        node.  If no such node exists, the context node is the root node.
>
>     o  If the "when" statement is a child of any other data definition
>        statement, the context node is the node in the accessible tree for
>        which the "when" statement is defined.
>=20=20=20=20=20
>     An XPath expression MUST NOT reference nodes that are made conditional
>     by the "when" statement that defines it.

Yes, plus the other two rules that are already in 6020bis:

If the XPath expression references any node that also has associated
"when" statements, these "when" expressions MUST be evaluated first.

There MUST NOT be any circular dependencies in these "when" expressions.
>
> I don't see a case in which the context node is non-existent (in the=20
> schema tree) in any of the three bullets, even without "no value, no=20
> descendants" dummy node.

The third bullet is aimed at cases like this:

leaf foo {
    when "../bar > 0";
    mandatory true;
    ...
}

If there is no instance of "foo", a validator has to find out whether
the "mandatory" statement applies (and the absence of "foo" is thus a
schema error), or whether it is overruled by the "when" expression being
false. But in order to be able to evaluate that expression, XPath
requires a context node in the instance document, so we need to
tentatively add one.

Lada

>
> This text implies that:
>
>    container foo {
>      when "descendant-or-self::node()"; // semantic error
>      leaf bar {
>        type string;
>      }
>    }
>
> This is actually what our YANG 1.0 implementation currently does, though=
=20
> it only generates a warning.
>
> Jernej
>
>>
>> Lada
>>
>>> Jernej
>>>
>>>> /martin
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 25 04:52:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FCF1B306F for ; Fri, 25 Sep 2015 04:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJGzYBf-Ok6F for ; Fri, 25 Sep 2015 04:52: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 D668B1B309C for ; Fri, 25 Sep 2015 04:52:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EFB21AE07F0 for ; Fri, 25 Sep 2015 13:52:22 +0200 (CEST)
Date: Fri, 25 Sep 2015 13:52:21 +0200 (CEST)
Message-Id: <20150925.135221.46626345962009176.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 11:52:43 -0000

Hi,

Kent Watsen  wrote:
> 
> This is a notice to start a NETMOD WG last call for the document "JSON
> Encoding of Data Modeled with YANG":
> 
> 	https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05

I have reviewed this document, and I only have some minor comments.
Once this document is published, we will update our existing JSON
implementation to match this document (it *almost* matches it
today...)

o  Section 1

   The text mentions the JSON media type "application/yang.data+json".

   Where is this media type defined?  I think it should be defined in
   this document (add an IANA Considerations section).

   (Also the string "application/yang+json is missing the ending ")


o  Section 5.5

   Remove the sentence "Anydata data node is a new feature in YANG
   1.1.".


o  Section 5.5

   OLD: "event-class: "fault",
   NEW: "event-class": "fault",


o  Section 6.2

   OLD:    A "string" value represented 
   NEW:    A "string" value is represented 


o  Section 6.10

  With the union defined here, is this legal:

     "bar": "1"

  If it is not legal, it should be noted.

  If it is legal, it should be noted that this is more expressive than
  the XML encoding.


/martin


From nobody Fri Sep 25 04:57:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AC61B30AC for ; Fri, 25 Sep 2015 04:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.36
X-Spam-Level: 
X-Spam-Status: No, score=-5.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFTq8rA-ytsi for ; Fri, 25 Sep 2015 04:57:32 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9301B30AD for ; Fri, 25 Sep 2015 04:57:31 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:cd9f:3935:2914:4f87] (unknown [IPv6:2001:718:1a02:1:cd9f:3935:2914:4f87]) by mail.nic.cz (Postfix) with ESMTPSA id 6FEAA1818DF; Fri, 25 Sep 2015 13:57:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1443182250; bh=eWGd/v/8zrSeWzKxJSBa0F7tGoLDPG0QufNxiM4NqOg=; h=From:Date:To; b=D7bnBFeKHRiNg2FH4e+3JdqsI/k661JPCnG9ji1397133b3d7mjjiu+cqz/MYiVhG c5nb/INGrTyg4Ob67CnooxM5gNui080bKESsKk4uBriOuCKIk5FYwYSz0WNBq4IwFy CDqbOQWfllqZQenC8YbSKspPBrG7hQWmPikubeJI=
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1BD3A2E-94E5-468F-B5E1-AE838D8A42E8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Ladislav Lhotka 
In-Reply-To: <20150925.134110.1680423075885764349.mbj@tail-f.com>
Date: Fri, 25 Sep 2015 13:57:28 +0200
Message-Id: <1BB04314-9FD7-4007-8EFE-5A21EA3D7241@nic.cz>
References: <20150924.135449.1944322803447003762.mbj@tail-f.com> <5603F0FE.6000808@mg-soft.si>  <20150925.134110.1680423075885764349.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.2104)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 11:57:35 -0000

--Apple-Mail=_D1BD3A2E-94E5-468F-B5E1-AE838D8A42E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 25 Sep 2015, at 13:41, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Jernej Tuljak  writes:
>>=20
>>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>>>> Jernej Tuljak  wrote:
>>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>>>> Jernej Tuljak  writes:
>>>>>>=20
>>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  =
wrote:
>>>>>>>>>=20
>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  =
wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> Section 7.21.5., the first bullet describing the =
augmentation case
>>>>>>>>>>> does not consider that an "augment" may specify a top-level =
"choice"
>>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as =
the target
>>>>>>>>>>> node. There will be no initial context node for the =
expression in such
>>>>>>>>>>> a case.
>>>>>>>>>>>=20
>>>>>>>>>>>    leaf enable-foos {
>>>>>>>>>>>      type boolean;
>>>>>>>>>>>    }
>>>>>>>>>>>    choice ch1 {
>>>>>>>>>>>      case foo {
>>>>>>>>>>>        choice foos {
>>>>>>>>>>>          when "enable-foos =3D 'true'";
>>>>>>>>>>>          leaf foo1 {
>>>>>>>>>>>            type string;
>>>>>>>>>>>          }
>>>>>>>>>>>          leaf foo2 {
>>>>>>>>>>>            type string;
>>>>>>>>>>>          }
>>>>>>>>>>>        }
>>>>>>>>>>>      }
>>>>>>>>>>>      container meh;
>>>>>>>>>>>    }
>>>>>>>>>>>=20
>>>>>>>>>>>    augment "/ch1/foo/foos" {
>>>>>>>>>>>      when "enable-foos =3D 'true'";
>>>>>>>>>>>      leaf foo3 {
>>>>>>>>>>>        type string;
>>>>>>>>>>>      }
>>>>>>>>>>>    }
>>>>>>>>>>>=20
>>>>>>>>>>> OLD:
>>>>>>>>>>>=20
>>>>>>>>>>>     o If the "when" statement is a child of an "augment" =
statement,
>>>>>>>>>>>     then
>>>>>>>>>>>        the context node is the augment's target node in the =
data tree,
>>>>>>>>>>>        if
>>>>>>>>>>>        the target node is a data node.  Otherwise, the =
context node is
>>>>>>>>>>>        the closest ancestor node to the target node that is =
also a data
>>>>>>>>>>>        node.
>>>>>>>>>>>=20
>>>>>>>>>>> NEW:
>>>>>>>>>>>=20
>>>>>>>>>>>     o If the "when" statement is a child of an "augment" =
statement,
>>>>>>>>>>>     then
>>>>>>>>>>>        the context node is the augment's target node in the =
data tree,
>>>>>>>>>>>        if
>>>>>>>>>>>        the target node is a data node.  Otherwise, the =
context node is
>>>>>>>>>>>        the closest ancestor node to the target node that is =
also a data
>>>>>>>>>>>        node. If no such node exists, the context node is the =
root node.
>>>>>>>>>>>=20
>>>>>>>>>> Good catch, I support this change.
>>>>>>>>>>=20
>>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when =
expression
>>>>>>>>>> must not reference nodes that are made conditional through =
that when
>>>>>>>>>> statement. I can=E2=80=99t find this rule in the text.
>>>>>>>>> The "no referencing the initial context node and its =
descendants" text
>>>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>>>> seriously broken and could lead to deadlocks.
>>>>>>> I think that was the purpose of the change in 3rd bullet. A =
"dummy"
>>>>>>> node
>>>>>>> with no value and child nodes has been introduced.
>>>>>> Not really, the dummy node solves the problem of a non-existent
>>>>>> context
>>>>>> node.
>>>>> Are you referring to "existence" in the instance document or the
>>>>> schema tree? Why is there no need for "no children, no value =
dummy" in
>>>>> 1st and 2nd bullet?
>>>> In these cases, the context node is well-defined anyway.  But I =
think
>>>> that also these bullets need to have text that make sure that the
>>>> outcome is deterministic in all cases, such as:
>>>>=20
>>>>   augement /foo {
>>>>     when "bar > 1";
>>>>     leaf bar { type int32; }
>>>>   }
>>>>=20
>>>> or
>>>>=20
>>>>   grouping foo {
>>>>     leaf bar { type int32; }
>>>>   }
>>>>   container x {
>>>>     uses foo {
>>>>       when "bar > 1";
>>>>     }
>>>>   }
>>>>=20
>>>>=20
>>>> etc.
>>>>=20
>>>> So I suggest this NEW text:
>>>>=20
>>>>=20
>>>>    o  If the "when" statement is a child of an "augment" statement, =
then
>>>>       the context node is the augment's target node in the data =
tree, if
>>>>       the target node is a data node.  Otherwise, the context node =
is
>>>>       the closest ancestor node to the target node that is also a =
data
>>>>       node.  If no such node exists, the context node is the root =
node.
>>>>       The accessible tree is tentatively altered during the =
processing
>>>>       of the XPath expression by removing all instances (if any) of =
the
>>>>       nodes added by the "augment" statement.
>>>>=20
>>>>    o  If the "when" statement is a child of a "uses", "choice", or
>>>>       "case" statement, then the context node is the closest =
ancestor
>>>>       node to the "uses", "choice", or "case" node that is also a =
data
>>>>       node.  If no such node exists, the context node is the root =
node.
>>>>       The accessible tree is tentatively altered during the =
processing
>>>>       of the XPath expression by removing all instances (if any) of =
the
>>>>       nodes added by the "uses", "choice", or "case" statement.
>>>>=20
>>>>    o  If the "when" statement is a child of any other data =
definition
>>>>       statement, the accessible tree is tentatively altered during =
the
>>>>       processing of the XPath expression by replacing all instances =
(if
>>>>       any) of the data node for which the "when" statement is =
defined
>>>>       with a single dummy node with the same name, but with no =
value and
>>>>       no children.  The context node is this dummy node.
>>>>=20
>>>=20
>>> +1
>>>=20
>>>   container foo {
>>>     when "child::* or child::text() or not(self::*)"; // always =
false
>>>     leaf bar {
>>>       type string;
>>>     }
>>>   }
>>=20
>> I think it would be better to clearly state that a "when" expression
>> MUST NOT refer to nodes that are made conditional by the same "when"
>> statement - it's similar to the rule that forbids mutual references.
>> This would also cover all uses of "when".
>=20
> So what does this mean:
>=20
>  augment /a/b/c {
>    when "* =3D 42";
>    leaf foo {
>      type int32;
>    }
>  }
>=20
> Is this an error, since the "*" references a node made conditional?

Yes, because the nodeset represented by * includes the child =E2=80=9Cfoo=E2=
=80=9D.

>=20
>=20
>> The above example would be really confusing if the "bar" instance is
>> present. I also don't like the fact that "when" and "must" would give
>> different results in this case.
>=20
> I agree, but OTOH we're talking about a theoretical corner case.

For =E2=80=9Cmust=E2=80=9D no such restrictions exist (circular =
references are OK, too), and YANG beginners often don=E2=80=99t get the =
subtle difference between =E2=80=9Cmust=E2=80=9D and =E2=80=9Cwhen=E2=80=9D=
.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>> Jernej
>>>=20
>>>>=20
>>>> /martin
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--Apple-Mail=_D1BD3A2E-94E5-468F-B5E1-AE838D8A42E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 25 Sep =
2015, at 13:41, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhotka@nic.cz> wrote:
Jernej Tuljak <jernejt@mg-soft.si> writes:

Martin Bjorklund je =
24.9.2015 ob 13:54 napisal:
Jernej Tuljak <jernejt@mg-soft.si> wrote:
Ladislav Lhotka je 23.9.2015 ob 14:29 =
napisal:
Jernej =
Tuljak <jernejt@mg-soft.si> writes:

Ladislav Lhotka je =
23.9.2015 ob 12:52 napisal:
On 23 Sep 2015, at =
12:37, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
On 23 Sep 2015, at 11:45, Jernej Tuljak <jernejt@mg-soft.si> =
wrote:

Section 7.21.5., the first bullet =
describing the augmentation case
does not consider that an =
"augment" may specify a top-level "choice"
or a =
"choice"/"case" nested within a top-level "choice" as the target
node. There will be no initial context node for the =
expression in such
a case.

   leaf enable-foos {
    =
 type boolean;
   }
  =
 choice ch1 {
     case foo {
       choice foos {
  =
       when "enable-foos =3D 'true'";
         leaf foo1 {
           type string;
         }
  =
       leaf foo2 {
    =
       type string;
    =
     }
       }
     }
    =
 container meh;
   }

   augment "/ch1/foo/foos" {
  =
   when "enable-foos =3D 'true'";
    =
 leaf foo3 {
       type =
string;
     }
  =
 }

OLD:

    o If the "when" statement is a child of an =
"augment" statement,
    then
 =
      the context node is the augment's target node in =
the data tree,
       if
       the target node is a data node. =
 Otherwise, the context node is
      =
 the closest ancestor node to the target node that is also a =
data
       node.

NEW:

    o If the =
"when" statement is a child of an "augment" statement,
    then
      =
 the context node is the augment's target node in the data tree,
       if
    =
   the target node is a data node.  Otherwise, the =
context node is
       the closest =
ancestor node to the target node that is also a data
  =
     node. If no such node exists, the context node is =
the root node.

Good catch, I =
support this change.

Also regarding sec. =
7.21.5, I think we agreed that a when expression
must not =
reference nodes that are made conditional through that when
statement. I can=E2=80=99t find this rule in the text.
The "no referencing the initial context node and =
its descendants" text
is currently in the guidelines draft =
only (6087bis).
IMO this should be a hard =
rule in 6020bis. Such expressions are
seriously broken and =
could lead to deadlocks.
I think that was the =
purpose of the change in 3rd bullet. A "dummy"
node
with no value and child nodes has been introduced.
Not really, the dummy node solves the problem of =
a non-existent
context
node.
Are you referring to "existence" in the instance =
document or the
schema tree? Why is there no need for "no =
children, no value dummy" in
1st and 2nd bullet?
In these cases, the context node is well-defined =
anyway.  But I think
that also these bullets need to =
have text that make sure that the
outcome is deterministic =
in all cases, such as:

  augement /foo =
{
    when "bar > 1";
  =
  leaf bar { type int32; }
  }

or

  grouping foo {
    leaf bar { type int32; }
  =
}
  container x {
    uses =
foo {
      when "bar > 1";
    }
  }


etc.

So I suggest =
this NEW text:


  =
 o  If the "when" statement is a child of an "augment" =
statement, then
      the context node is =
the augment's target node in the data tree, if
  =
    the target node is a data node.  Otherwise, the =
context node is
      the closest ancestor =
node to the target node that is also a data
    =
  node.  If no such node exists, the context node is the root =
node.
      The accessible tree is =
tentatively altered during the processing
    =
  of the XPath expression by removing all instances (if any) of =
the
      nodes added by the "augment" =
statement.

   o  If the =
"when" statement is a child of a "uses", "choice", or
 =
     "case" statement, then the context node is the closest =
ancestor
      node to the "uses", =
"choice", or "case" node that is also a data
    =
  node.  If no such node exists, the context node is the root =
node.
      The accessible tree is =
tentatively altered during the processing
    =
  of the XPath expression by removing all instances (if any) of =
the
      nodes added by the "uses", =
"choice", or "case" statement.

  =
 o  If the "when" statement is a child of any other data =
definition
      statement, the accessible =
tree is tentatively altered during the
    =
  processing of the XPath expression by replacing all instances =
(if
      any) of the data node for which =
the "when" statement is defined
      with =
a single dummy node with the same name, but with no value and
      no children.  The context node is =
this dummy node.


+1

  container foo {
    when "child::* or child::text() or =
not(self::*)"; // always false
    leaf bar {
      type string;
    =
}
  }

I =
think it would be better to clearly state that a "when" expression
MUST NOT refer to nodes that are made conditional by the same =
"when"
statement - it's similar to the rule that forbids =
mutual references.
This would also cover all uses of =
"when".

So what does this =
mean:

 augment /a/b/c {
   when "* =3D 42";
   leaf =
foo {
     type int32;
  =
 }
 }

Is this an =
error, since the "*" references a node made conditional?

Yes, because the nodeset represented by * includes the child =
=E2=80=9Cfoo=E2=80=9D.



The =
above example would be really confusing if the "bar" instance is
present. I also don't like the fact that "when" and "must" =
would give
different results in this case.

I agree, but OTOH we're talking =
about a theoretical corner case.

For =E2=80=9Cmust=E2=80=9D=
 no such restrictions exist (circular references are OK, too), and YANG =
beginners often don=E2=80=99t get the subtle difference between =
=E2=80=9Cmust=E2=80=9D and =E2=80=9Cwhen=E2=80=9D.

Lada



/martin





Lada


Jernej


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

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

-- 
Ladislav =
Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: =
E74E8C0C




=

--Apple-Mail=_D1BD3A2E-94E5-468F-B5E1-AE838D8A42E8--


From nobody Fri Sep 25 05:03:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FC41B30BB for ; Fri, 25 Sep 2015 05:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohROrYqKY0rm for ; Fri, 25 Sep 2015 05:03:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CCDD41B30B4 for ; Fri, 25 Sep 2015 05:03:13 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id E30D71AE07F0; Fri, 25 Sep 2015 14:03:12 +0200 (CEST)
Date: Fri, 25 Sep 2015 14:03:12 +0200 (CEST)
Message-Id: <20150925.140312.866880633499924608.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <1BB04314-9FD7-4007-8EFE-5A21EA3D7241@nic.cz>
References:  <20150925.134110.1680423075885764349.mbj@tail-f.com> <1BB04314-9FD7-4007-8EFE-5A21EA3D7241@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 12:03:16 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjUgU2Vw
IDIwMTUsIGF0IDEzOjQxLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6
DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g
SmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPiB3cml0ZXM6DQo+ID4+IA0KPiA+Pj4g
TWFydGluIEJqb3JrbHVuZCBqZSAyNC45LjIwMTUgb2IgMTM6NTQgbmFwaXNhbDoNCj4gPj4+PiBK
ZXJuZWogVHVsamFrIDxqZXJuZWp0QG1nLXNvZnQuc2k+IHdyb3RlOg0KPiA+Pj4+PiBMYWRpc2xh
diBMaG90a2EgamUgMjMuOS4yMDE1IG9iIDE0OjI5IG5hcGlzYWw6DQo+ID4+Pj4+PiBKZXJuZWog
VHVsamFrIDxqZXJuZWp0QG1nLXNvZnQuc2k+IHdyaXRlczoNCj4gPj4+Pj4+IA0KPiA+Pj4+Pj4+
IExhZGlzbGF2IExob3RrYSBqZSAyMy45LjIwMTUgb2IgMTI6NTIgbmFwaXNhbDoNCj4gPj4+Pj4+
Pj4+IE9uIDIzIFNlcCAyMDE1LCBhdCAxMjozNywgSmVybmVqIFR1bGphayA8amVybmVqdEBtZy1z
b2Z0LnNpPiB3cm90ZToNCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGth
IGplIDIzLjkuMjAxNSBvYiAxMTo1OCBuYXBpc2FsOg0KPiA+Pj4+Pj4+Pj4+PiBPbiAyMyBTZXAg
MjAxNSwgYXQgMTE6NDUsIEplcm5laiBUdWxqYWsgPGplcm5lanRAbWctc29mdC5zaT4gd3JvdGU6
DQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBTZWN0aW9uIDcuMjEuNS4sIHRoZSBmaXJz
dCBidWxsZXQgZGVzY3JpYmluZyB0aGUgYXVnbWVudGF0aW9uIGNhc2UNCj4gPj4+Pj4+Pj4+Pj4g
ZG9lcyBub3QgY29uc2lkZXIgdGhhdCBhbiAiYXVnbWVudCIgbWF5IHNwZWNpZnkgYSB0b3AtbGV2
ZWwgImNob2ljZSINCj4gPj4+Pj4+Pj4+Pj4gb3IgYSAiY2hvaWNlIi8iY2FzZSIgbmVzdGVkIHdp
dGhpbiBhIHRvcC1sZXZlbCAiY2hvaWNlIiBhcyB0aGUgdGFyZ2V0DQo+ID4+Pj4+Pj4+Pj4+IG5v
ZGUuIFRoZXJlIHdpbGwgYmUgbm8gaW5pdGlhbCBjb250ZXh0IG5vZGUgZm9yIHRoZSBleHByZXNz
aW9uIGluIHN1Y2gNCj4gPj4+Pj4+Pj4+Pj4gYSBjYXNlLg0KPiA+Pj4+Pj4+Pj4+PiANCj4gPj4+
Pj4+Pj4+Pj4gICAgbGVhZiBlbmFibGUtZm9vcyB7DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgdHlwZSBi
b29sZWFuOw0KPiA+Pj4+Pj4+Pj4+PiAgICB9DQo+ID4+Pj4+Pj4+Pj4+ICAgIGNob2ljZSBjaDEg
ew0KPiA+Pj4+Pj4+Pj4+PiAgICAgIGNhc2UgZm9vIHsNCj4gPj4+Pj4+Pj4+Pj4gICAgICAgIGNo
b2ljZSBmb29zIHsNCj4gPj4+Pj4+Pj4+Pj4gICAgICAgICAgd2hlbiAiZW5hYmxlLWZvb3MgPSAn
dHJ1ZSciOw0KPiA+Pj4+Pj4+Pj4+PiAgICAgICAgICBsZWFmIGZvbzEgew0KPiA+Pj4+Pj4+Pj4+
PiAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPiA+Pj4+Pj4+Pj4+PiAgICAgICAgICB9DQo+ID4+
Pj4+Pj4+Pj4+ICAgICAgICAgIGxlYWYgZm9vMiB7DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICAgICAg
dHlwZSBzdHJpbmc7DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICAgIH0NCj4gPj4+Pj4+Pj4+Pj4gICAg
ICAgIH0NCj4gPj4+Pj4+Pj4+Pj4gICAgICB9DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgY29udGFpbmVy
IG1laDsNCj4gPj4+Pj4+Pj4+Pj4gICAgfQ0KPiA+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4g
ICAgYXVnbWVudCAiL2NoMS9mb28vZm9vcyIgew0KPiA+Pj4+Pj4+Pj4+PiAgICAgIHdoZW4gImVu
YWJsZS1mb29zID0gJ3RydWUnIjsNCj4gPj4+Pj4+Pj4+Pj4gICAgICBsZWFmIGZvbzMgew0KPiA+
Pj4+Pj4+Pj4+PiAgICAgICAgdHlwZSBzdHJpbmc7DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgfQ0KPiA+
Pj4+Pj4+Pj4+PiAgICB9DQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiBPTEQ6DQo+ID4+
Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiAgICAgbyBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBp
cyBhIGNoaWxkIG9mIGFuICJhdWdtZW50IiBzdGF0ZW1lbnQsDQo+ID4+Pj4+Pj4+Pj4+ICAgICB0
aGVuDQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBhdWdtZW50
J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwNCj4gPj4+Pj4+Pj4+Pj4gICAgICAgIGlm
DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICB0aGUgdGFyZ2V0IG5vZGUgaXMgYSBkYXRhIG5vZGUuICBP
dGhlcndpc2UsIHRoZSBjb250ZXh0IG5vZGUgaXMNCj4gPj4+Pj4+Pj4+Pj4gICAgICAgIHRoZSBj
bG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMgYWxzbyBhIGRh
dGENCj4gPj4+Pj4+Pj4+Pj4gICAgICAgIG5vZGUuDQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+
Pj4+PiBORVc6DQo+ID4+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+PiAgICAgbyBJZiB0aGUgIndo
ZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFuICJhdWdtZW50IiBzdGF0ZW1lbnQsDQo+ID4+
Pj4+Pj4+Pj4+ICAgICB0aGVuDQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICB0aGUgY29udGV4dCBub2Rl
IGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwNCj4gPj4+Pj4+
Pj4+Pj4gICAgICAgIGlmDQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICB0aGUgdGFyZ2V0IG5vZGUgaXMg
YSBkYXRhIG5vZGUuICBPdGhlcndpc2UsIHRoZSBjb250ZXh0IG5vZGUgaXMNCj4gPj4+Pj4+Pj4+
Pj4gICAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRo
YXQgaXMgYWxzbyBhIGRhdGENCj4gPj4+Pj4+Pj4+Pj4gICAgICAgIG5vZGUuIElmIG5vIHN1Y2gg
bm9kZSBleGlzdHMsIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIHJvb3Qgbm9kZS4NCj4gPj4+Pj4+
Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gR29vZCBjYXRjaCwgSSBzdXBwb3J0IHRoaXMgY2hhbmdlLg0K
PiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IEFsc28gcmVnYXJkaW5nIHNlYy4gNy4yMS41LCBJ
IHRoaW5rIHdlIGFncmVlZCB0aGF0IGEgd2hlbiBleHByZXNzaW9uDQo+ID4+Pj4+Pj4+Pj4gbXVz
dCBub3QgcmVmZXJlbmNlIG5vZGVzIHRoYXQgYXJlIG1hZGUgY29uZGl0aW9uYWwgdGhyb3VnaCB0
aGF0IHdoZW4NCj4gPj4+Pj4+Pj4+PiBzdGF0ZW1lbnQuIEkgY2Fu4oCZdCBmaW5kIHRoaXMgcnVs
ZSBpbiB0aGUgdGV4dC4NCj4gPj4+Pj4+Pj4+IFRoZSAibm8gcmVmZXJlbmNpbmcgdGhlIGluaXRp
YWwgY29udGV4dCBub2RlIGFuZCBpdHMgZGVzY2VuZGFudHMiIHRleHQNCj4gPj4+Pj4+Pj4+IGlz
IGN1cnJlbnRseSBpbiB0aGUgZ3VpZGVsaW5lcyBkcmFmdCBvbmx5ICg2MDg3YmlzKS4NCj4gPj4+
Pj4+Pj4gSU1PIHRoaXMgc2hvdWxkIGJlIGEgaGFyZCBydWxlIGluIDYwMjBiaXMuIFN1Y2ggZXhw
cmVzc2lvbnMgYXJlDQo+ID4+Pj4+Pj4+IHNlcmlvdXNseSBicm9rZW4gYW5kIGNvdWxkIGxlYWQg
dG8gZGVhZGxvY2tzLg0KPiA+Pj4+Pj4+IEkgdGhpbmsgdGhhdCB3YXMgdGhlIHB1cnBvc2Ugb2Yg
dGhlIGNoYW5nZSBpbiAzcmQgYnVsbGV0LiBBICJkdW1teSINCj4gPj4+Pj4+PiBub2RlDQo+ID4+
Pj4+Pj4gd2l0aCBubyB2YWx1ZSBhbmQgY2hpbGQgbm9kZXMgaGFzIGJlZW4gaW50cm9kdWNlZC4N
Cj4gPj4+Pj4+IE5vdCByZWFsbHksIHRoZSBkdW1teSBub2RlIHNvbHZlcyB0aGUgcHJvYmxlbSBv
ZiBhIG5vbi1leGlzdGVudA0KPiA+Pj4+Pj4gY29udGV4dA0KPiA+Pj4+Pj4gbm9kZS4NCj4gPj4+
Pj4gQXJlIHlvdSByZWZlcnJpbmcgdG8gImV4aXN0ZW5jZSIgaW4gdGhlIGluc3RhbmNlIGRvY3Vt
ZW50IG9yIHRoZQ0KPiA+Pj4+PiBzY2hlbWEgdHJlZT8gV2h5IGlzIHRoZXJlIG5vIG5lZWQgZm9y
ICJubyBjaGlsZHJlbiwgbm8gdmFsdWUgZHVtbXkiIGluDQo+ID4+Pj4+IDFzdCBhbmQgMm5kIGJ1
bGxldD8NCj4gPj4+PiBJbiB0aGVzZSBjYXNlcywgdGhlIGNvbnRleHQgbm9kZSBpcyB3ZWxsLWRl
ZmluZWQgYW55d2F5LiAgQnV0IEkgdGhpbmsNCj4gPj4+PiB0aGF0IGFsc28gdGhlc2UgYnVsbGV0
cyBuZWVkIHRvIGhhdmUgdGV4dCB0aGF0IG1ha2Ugc3VyZSB0aGF0IHRoZQ0KPiA+Pj4+IG91dGNv
bWUgaXMgZGV0ZXJtaW5pc3RpYyBpbiBhbGwgY2FzZXMsIHN1Y2ggYXM6DQo+ID4+Pj4gDQo+ID4+
Pj4gICBhdWdlbWVudCAvZm9vIHsNCj4gPj4+PiAgICAgd2hlbiAiYmFyID4gMSI7DQo+ID4+Pj4g
ICAgIGxlYWYgYmFyIHsgdHlwZSBpbnQzMjsgfQ0KPiA+Pj4+ICAgfQ0KPiA+Pj4+IA0KPiA+Pj4+
IG9yDQo+ID4+Pj4gDQo+ID4+Pj4gICBncm91cGluZyBmb28gew0KPiA+Pj4+ICAgICBsZWFmIGJh
ciB7IHR5cGUgaW50MzI7IH0NCj4gPj4+PiAgIH0NCj4gPj4+PiAgIGNvbnRhaW5lciB4IHsNCj4g
Pj4+PiAgICAgdXNlcyBmb28gew0KPiA+Pj4+ICAgICAgIHdoZW4gImJhciA+IDEiOw0KPiA+Pj4+
ICAgICB9DQo+ID4+Pj4gICB9DQo+ID4+Pj4gDQo+ID4+Pj4gDQo+ID4+Pj4gZXRjLg0KPiA+Pj4+
IA0KPiA+Pj4+IFNvIEkgc3VnZ2VzdCB0aGlzIE5FVyB0ZXh0Og0KPiA+Pj4+IA0KPiA+Pj4+IA0K
PiA+Pj4+ICAgIG8gIElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1
Z21lbnQiIHN0YXRlbWVudCwgdGhlbg0KPiA+Pj4+ICAgICAgIHRoZSBjb250ZXh0IG5vZGUgaXMg
dGhlIGF1Z21lbnQncyB0YXJnZXQgbm9kZSBpbiB0aGUgZGF0YSB0cmVlLCBpZg0KPiA+Pj4+ICAg
ICAgIHRoZSB0YXJnZXQgbm9kZSBpcyBhIGRhdGEgbm9kZS4gIE90aGVyd2lzZSwgdGhlIGNvbnRl
eHQgbm9kZSBpcw0KPiA+Pj4+ICAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhl
IHRhcmdldCBub2RlIHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gPj4+PiAgICAgICBub2RlLiAgSWYg
bm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgcm9vdCBub2RlLg0K
PiA+Pj4+ICAgICAgIFRoZSBhY2Nlc3NpYmxlIHRyZWUgaXMgdGVudGF0aXZlbHkgYWx0ZXJlZCBk
dXJpbmcgdGhlIHByb2Nlc3NpbmcNCj4gPj4+PiAgICAgICBvZiB0aGUgWFBhdGggZXhwcmVzc2lv
biBieSByZW1vdmluZyBhbGwgaW5zdGFuY2VzIChpZiBhbnkpIG9mIHRoZQ0KPiA+Pj4+ICAgICAg
IG5vZGVzIGFkZGVkIGJ5IHRoZSAiYXVnbWVudCIgc3RhdGVtZW50Lg0KPiA+Pj4+IA0KPiA+Pj4+
ICAgIG8gIElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYSAidXNlcyIsICJj
aG9pY2UiLCBvcg0KPiA+Pj4+ICAgICAgICJjYXNlIiBzdGF0ZW1lbnQsIHRoZW4gdGhlIGNvbnRl
eHQgbm9kZSBpcyB0aGUgY2xvc2VzdCBhbmNlc3Rvcg0KPiA+Pj4+ICAgICAgIG5vZGUgdG8gdGhl
ICJ1c2VzIiwgImNob2ljZSIsIG9yICJjYXNlIiBub2RlIHRoYXQgaXMgYWxzbyBhIGRhdGENCj4g
Pj4+PiAgICAgICBub2RlLiAgSWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9k
ZSBpcyB0aGUgcm9vdCBub2RlLg0KPiA+Pj4+ICAgICAgIFRoZSBhY2Nlc3NpYmxlIHRyZWUgaXMg
dGVudGF0aXZlbHkgYWx0ZXJlZCBkdXJpbmcgdGhlIHByb2Nlc3NpbmcNCj4gPj4+PiAgICAgICBv
ZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBieSByZW1vdmluZyBhbGwgaW5zdGFuY2VzIChpZiBhbnkp
IG9mIHRoZQ0KPiA+Pj4+ICAgICAgIG5vZGVzIGFkZGVkIGJ5IHRoZSAidXNlcyIsICJjaG9pY2Ui
LCBvciAiY2FzZSIgc3RhdGVtZW50Lg0KPiA+Pj4+IA0KPiA+Pj4+ICAgIG8gIElmIHRoZSAid2hl
biIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW55IG90aGVyIGRhdGEgZGVmaW5pdGlvbg0KPiA+
Pj4+ICAgICAgIHN0YXRlbWVudCwgdGhlIGFjY2Vzc2libGUgdHJlZSBpcyB0ZW50YXRpdmVseSBh
bHRlcmVkIGR1cmluZyB0aGUNCj4gPj4+PiAgICAgICBwcm9jZXNzaW5nIG9mIHRoZSBYUGF0aCBl
eHByZXNzaW9uIGJ5IHJlcGxhY2luZyBhbGwgaW5zdGFuY2VzIChpZg0KPiA+Pj4+ICAgICAgIGFu
eSkgb2YgdGhlIGRhdGEgbm9kZSBmb3Igd2hpY2ggdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgZGVm
aW5lZA0KPiA+Pj4+ICAgICAgIHdpdGggYSBzaW5nbGUgZHVtbXkgbm9kZSB3aXRoIHRoZSBzYW1l
IG5hbWUsIGJ1dCB3aXRoIG5vIHZhbHVlIGFuZA0KPiA+Pj4+ICAgICAgIG5vIGNoaWxkcmVuLiAg
VGhlIGNvbnRleHQgbm9kZSBpcyB0aGlzIGR1bW15IG5vZGUuDQo+ID4+Pj4gDQo+ID4+PiANCj4g
Pj4+ICsxDQo+ID4+PiANCj4gPj4+ICAgY29udGFpbmVyIGZvbyB7DQo+ID4+PiAgICAgd2hlbiAi
Y2hpbGQ6Oiogb3IgY2hpbGQ6OnRleHQoKSBvciBub3Qoc2VsZjo6KikiOyAvLyBhbHdheXMgZmFs
c2UNCj4gPj4+ICAgICBsZWFmIGJhciB7DQo+ID4+PiAgICAgICB0eXBlIHN0cmluZzsNCj4gPj4+
ICAgICB9DQo+ID4+PiAgIH0NCj4gPj4gDQo+ID4+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVy
IHRvIGNsZWFybHkgc3RhdGUgdGhhdCBhICJ3aGVuIiBleHByZXNzaW9uDQo+ID4+IE1VU1QgTk9U
IHJlZmVyIHRvIG5vZGVzIHRoYXQgYXJlIG1hZGUgY29uZGl0aW9uYWwgYnkgdGhlIHNhbWUgIndo
ZW4iDQo+ID4+IHN0YXRlbWVudCAtIGl0J3Mgc2ltaWxhciB0byB0aGUgcnVsZSB0aGF0IGZvcmJp
ZHMgbXV0dWFsIHJlZmVyZW5jZXMuDQo+ID4+IFRoaXMgd291bGQgYWxzbyBjb3ZlciBhbGwgdXNl
cyBvZiAid2hlbiIuDQo+ID4gDQo+ID4gU28gd2hhdCBkb2VzIHRoaXMgbWVhbjoNCj4gPiANCj4g
PiAgYXVnbWVudCAvYS9iL2Mgew0KPiA+ICAgIHdoZW4gIiogPSA0MiI7DQo+ID4gICAgbGVhZiBm
b28gew0KPiA+ICAgICAgdHlwZSBpbnQzMjsNCj4gPiAgICB9DQo+ID4gIH0NCj4gPiANCj4gPiBJ
cyB0aGlzIGFuIGVycm9yLCBzaW5jZSB0aGUgIioiIHJlZmVyZW5jZXMgYSBub2RlIG1hZGUgY29u
ZGl0aW9uYWw/DQo+IA0KPiBZZXMsIGJlY2F1c2UgdGhlIG5vZGVzZXQgcmVwcmVzZW50ZWQgYnkg
KiBpbmNsdWRlcyB0aGUgY2hpbGQg4oCcZm9v4oCdLg0KDQpXZWxsLCBpZiAiZm9vIiBkb2Vzbid0
IGV4aXN0LCAiKiIgb2J2aW91c2x5IGRvZXMgbm90IGluY2x1ZGUgImZvbyIuDQpTbyB0aGlzIHdv
dWxkIG1lYW4gdGhhdCBkZXBlbmRpbmcgb24gd2hlbiB0aGlzIGV4cHJlc3Npb24gaXMNCmV2YWx1
YXRlZCwgaXQgbWF5IG9yIG1heSBub3QgYmUgaWxsZWdhbC4uLg0KDQoNCg0KL21hcnRpbg0K


From nobody Fri Sep 25 05:21:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2491B3116 for ; Fri, 25 Sep 2015 05:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlfxJk63-vfH for ; Fri, 25 Sep 2015 05:21:34 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 08F371B3113 for ; Fri, 25 Sep 2015 05:21:34 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id AE1AB1CC0049; Fri, 25 Sep 2015 14:21:42 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund 
In-Reply-To: <20150925.140312.866880633499924608.mbj@tail-f.com>
References:  <20150925.134110.1680423075885764349.mbj@tail-f.com> <1BB04314-9FD7-4007-8EFE-5A21EA3D7241@nic.cz> <20150925.140312.866880633499924608.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 25 Sep 2015 14:21:29 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 12:21:36 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>>=20
>> > On 25 Sep 2015, at 13:41, Martin Bjorklund  wrote:
>> >=20
>> > Ladislav Lhotka  wrote:
>> >> Jernej Tuljak  writes:
>> >>=20
>> >>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>> >>>> Jernej Tuljak  wrote:
>> >>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>> >>>>>> Jernej Tuljak  writes:
>> >>>>>>=20
>> >>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>> >>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  w=
rote:
>> >>>>>>>>>=20
>> >>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>> >>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak =
 wrote:
>> >>>>>>>>>>>=20
>> >>>>>>>>>>> Section 7.21.5., the first bullet describing the augmentatio=
n case
>> >>>>>>>>>>> does not consider that an "augment" may specify a top-level =
"choice"
>> >>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as t=
he target
>> >>>>>>>>>>> node. There will be no initial context node for the expressi=
on in such
>> >>>>>>>>>>> a case.
>> >>>>>>>>>>>=20
>> >>>>>>>>>>>    leaf enable-foos {
>> >>>>>>>>>>>      type boolean;
>> >>>>>>>>>>>    }
>> >>>>>>>>>>>    choice ch1 {
>> >>>>>>>>>>>      case foo {
>> >>>>>>>>>>>        choice foos {
>> >>>>>>>>>>>          when "enable-foos =3D 'true'";
>> >>>>>>>>>>>          leaf foo1 {
>> >>>>>>>>>>>            type string;
>> >>>>>>>>>>>          }
>> >>>>>>>>>>>          leaf foo2 {
>> >>>>>>>>>>>            type string;
>> >>>>>>>>>>>          }
>> >>>>>>>>>>>        }
>> >>>>>>>>>>>      }
>> >>>>>>>>>>>      container meh;
>> >>>>>>>>>>>    }
>> >>>>>>>>>>>=20
>> >>>>>>>>>>>    augment "/ch1/foo/foos" {
>> >>>>>>>>>>>      when "enable-foos =3D 'true'";
>> >>>>>>>>>>>      leaf foo3 {
>> >>>>>>>>>>>        type string;
>> >>>>>>>>>>>      }
>> >>>>>>>>>>>    }
>> >>>>>>>>>>>=20
>> >>>>>>>>>>> OLD:
>> >>>>>>>>>>>=20
>> >>>>>>>>>>>     o If the "when" statement is a child of an "augment" sta=
tement,
>> >>>>>>>>>>>     then
>> >>>>>>>>>>>        the context node is the augment's target node in the =
data tree,
>> >>>>>>>>>>>        if
>> >>>>>>>>>>>        the target node is a data node.  Otherwise, the conte=
xt node is
>> >>>>>>>>>>>        the closest ancestor node to the target node that is =
also a data
>> >>>>>>>>>>>        node.
>> >>>>>>>>>>>=20
>> >>>>>>>>>>> NEW:
>> >>>>>>>>>>>=20
>> >>>>>>>>>>>     o If the "when" statement is a child of an "augment" sta=
tement,
>> >>>>>>>>>>>     then
>> >>>>>>>>>>>        the context node is the augment's target node in the =
data tree,
>> >>>>>>>>>>>        if
>> >>>>>>>>>>>        the target node is a data node.  Otherwise, the conte=
xt node is
>> >>>>>>>>>>>        the closest ancestor node to the target node that is =
also a data
>> >>>>>>>>>>>        node. If no such node exists, the context node is the=
 root node.
>> >>>>>>>>>>>=20
>> >>>>>>>>>> Good catch, I support this change.
>> >>>>>>>>>>=20
>> >>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when exp=
ression
>> >>>>>>>>>> must not reference nodes that are made conditional through th=
at when
>> >>>>>>>>>> statement. I can=E2=80=99t find this rule in the text.
>> >>>>>>>>> The "no referencing the initial context node and its descendan=
ts" text
>> >>>>>>>>> is currently in the guidelines draft only (6087bis).
>> >>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>> >>>>>>>> seriously broken and could lead to deadlocks.
>> >>>>>>> I think that was the purpose of the change in 3rd bullet. A "dum=
my"
>> >>>>>>> node
>> >>>>>>> with no value and child nodes has been introduced.
>> >>>>>> Not really, the dummy node solves the problem of a non-existent
>> >>>>>> context
>> >>>>>> node.
>> >>>>> Are you referring to "existence" in the instance document or the
>> >>>>> schema tree? Why is there no need for "no children, no value dummy=
" in
>> >>>>> 1st and 2nd bullet?
>> >>>> In these cases, the context node is well-defined anyway.  But I thi=
nk
>> >>>> that also these bullets need to have text that make sure that the
>> >>>> outcome is deterministic in all cases, such as:
>> >>>>=20
>> >>>>   augement /foo {
>> >>>>     when "bar > 1";
>> >>>>     leaf bar { type int32; }
>> >>>>   }
>> >>>>=20
>> >>>> or
>> >>>>=20
>> >>>>   grouping foo {
>> >>>>     leaf bar { type int32; }
>> >>>>   }
>> >>>>   container x {
>> >>>>     uses foo {
>> >>>>       when "bar > 1";
>> >>>>     }
>> >>>>   }
>> >>>>=20
>> >>>>=20
>> >>>> etc.
>> >>>>=20
>> >>>> So I suggest this NEW text:
>> >>>>=20
>> >>>>=20
>> >>>>    o  If the "when" statement is a child of an "augment" statement,=
 then
>> >>>>       the context node is the augment's target node in the data tre=
e, if
>> >>>>       the target node is a data node.  Otherwise, the context node =
is
>> >>>>       the closest ancestor node to the target node that is also a d=
ata
>> >>>>       node.  If no such node exists, the context node is the root n=
ode.
>> >>>>       The accessible tree is tentatively altered during the process=
ing
>> >>>>       of the XPath expression by removing all instances (if any) of=
 the
>> >>>>       nodes added by the "augment" statement.
>> >>>>=20
>> >>>>    o  If the "when" statement is a child of a "uses", "choice", or
>> >>>>       "case" statement, then the context node is the closest ancest=
or
>> >>>>       node to the "uses", "choice", or "case" node that is also a d=
ata
>> >>>>       node.  If no such node exists, the context node is the root n=
ode.
>> >>>>       The accessible tree is tentatively altered during the process=
ing
>> >>>>       of the XPath expression by removing all instances (if any) of=
 the
>> >>>>       nodes added by the "uses", "choice", or "case" statement.
>> >>>>=20
>> >>>>    o  If the "when" statement is a child of any other data definiti=
on
>> >>>>       statement, the accessible tree is tentatively altered during =
the
>> >>>>       processing of the XPath expression by replacing all instances=
 (if
>> >>>>       any) of the data node for which the "when" statement is defin=
ed
>> >>>>       with a single dummy node with the same name, but with no valu=
e and
>> >>>>       no children.  The context node is this dummy node.
>> >>>>=20
>> >>>=20
>> >>> +1
>> >>>=20
>> >>>   container foo {
>> >>>     when "child::* or child::text() or not(self::*)"; // always false
>> >>>     leaf bar {
>> >>>       type string;
>> >>>     }
>> >>>   }
>> >>=20
>> >> I think it would be better to clearly state that a "when" expression
>> >> MUST NOT refer to nodes that are made conditional by the same "when"
>> >> statement - it's similar to the rule that forbids mutual references.
>> >> This would also cover all uses of "when".
>> >=20
>> > So what does this mean:
>> >=20
>> >  augment /a/b/c {
>> >    when "* =3D 42";
>> >    leaf foo {
>> >      type int32;
>> >    }
>> >  }
>> >=20
>> > Is this an error, since the "*" references a node made conditional?
>>=20
>> Yes, because the nodeset represented by * includes the child =E2=80=9Cfo=
o=E2=80=9D.
>
> Well, if "foo" doesn't exist, "*" obviously does not include "foo".
> So this would mean that depending on when this expression is
> evaluated, it may or may not be illegal...

This is a consequence of the fact that we are using results of XPath
expressions (that can only be evaluated in the context of a concrete
instance document) for modifying the schema.

I could similarly ask whether this is a circular reference if either
"foo" or "bar" instance doesn't exist:

leaf foo {
  when "not(../bar)";
  ...
}

leaf bar {
  when "not(../foo)";
  ...
}

Yes, we are on a rather slippery slope here.

Lada

>
>
>
> /martin

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 25 05:45:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5FF1B31A0 for ; Fri, 25 Sep 2015 05:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgUHWFCdwEtV for ; Fri, 25 Sep 2015 05:45:17 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7B1B319A for ; Fri, 25 Sep 2015 05:45:17 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 7FF6F1CC0049; Fri, 25 Sep 2015 14:45:26 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , netmod@ietf.org
In-Reply-To: <20150925.135221.46626345962009176.mbj@tail-f.com>
References:  <20150925.135221.46626345962009176.mbj@tail-f.com>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 25 Sep 2015 14:45:13 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 12:45:22 -0000

Hi Martin,

thanks for the review.

Martin Bjorklund  writes:

> Hi,
>
> Kent Watsen  wrote:
>> 
>> This is a notice to start a NETMOD WG last call for the document "JSON
>> Encoding of Data Modeled with YANG":
>> 
>> 	https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05
>
> I have reviewed this document, and I only have some minor comments.
> Once this document is published, we will update our existing JSON
> implementation to match this document (it *almost* matches it
> today...)
>
> o  Section 1
>
>    The text mentions the JSON media type "application/yang.data+json".
>
>    Where is this media type defined?  I think it should be defined in
>    this document (add an IANA Considerations section).

application/yang.data is defined in draft-ietf-netconf-restconf, and
"+json" is the structured syntax suffix as defined in RFC 6839. Any
problem with it?

>
>    (Also the string "application/yang+json is missing the ending ")

Fixed.

>
>
> o  Section 5.5
>
>    Remove the sentence "Anydata data node is a new feature in YANG
>    1.1.".

OK.

>
>
> o  Section 5.5
>
>    OLD: "event-class: "fault",
>    NEW: "event-class": "fault",

Fixed.

>
>
> o  Section 6.2
>
>    OLD:    A "string" value represented 
>    NEW:    A "string" value is represented 
>

Fixed.

>
> o  Section 6.10
>
>   With the union defined here, is this legal:
>
>      "bar": "1"

Yes, it is legal, and it means it will be interpreted as string.

>
>   If it is not legal, it should be noted.
>
>   If it is legal, it should be noted that this is more expressive than
>   the XML encoding.

OK.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Sep 25 05:50:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32C1A0108 for ; Fri, 25 Sep 2015 05:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nly4ryHgskpk for ; Fri, 25 Sep 2015 05:50: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 C84A91A00F4 for ; Fri, 25 Sep 2015 05:50:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 7603B1AE07F0; Fri, 25 Sep 2015 14:50:11 +0200 (CEST)
Date: Fri, 25 Sep 2015 14:50:10 +0200 (CEST)
Message-Id: <20150925.145010.866442311032836962.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20150925.135221.46626345962009176.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 12:50:14 -0000

Ladislav Lhotka  wrote:
> Hi Martin,
> 
> thanks for the review.
> 
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > Kent Watsen  wrote:
> >> 
> >> This is a notice to start a NETMOD WG last call for the document "JSON
> >> Encoding of Data Modeled with YANG":
> >> 
> >> 	https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05
> >
> > I have reviewed this document, and I only have some minor comments.
> > Once this document is published, we will update our existing JSON
> > implementation to match this document (it *almost* matches it
> > today...)
> >
> > o  Section 1
> >
> >    The text mentions the JSON media type "application/yang.data+json".
> >
> >    Where is this media type defined?  I think it should be defined in
> >    this document (add an IANA Considerations section).
> 
> application/yang.data is defined in draft-ietf-netconf-restconf, and
> "+json" is the structured syntax suffix as defined in RFC 6839. Any
> problem with it?

Ah, ok, sorry I was confused.  This is fine!


/martin


From nobody Fri Sep 25 06:15:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580661A01E2 for ; Fri, 25 Sep 2015 06:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHF3z2wIRzo2 for ; Fri, 25 Sep 2015 06:15:39 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id A7ACD1A0252 for ; Fri, 25 Sep 2015 06:15:38 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 71F7EC4175C1; Fri, 25 Sep 2015 15:15:37 +0200 (CEST)
To: Ladislav Lhotka , Martin Bjorklund 
References: <560287D1.9050905@mg-soft.si>  <5603BEC4.8050803@mg-soft.si> <20150924.135449.1944322803447003762.mbj@tail-f.com> <5603F0FE.6000808@mg-soft.si>  <56052F11.3010903@mg-soft.si> 
From: Jernej Tuljak 
Message-ID: <560548F4.8080505@mg-soft.si>
Date: Fri, 25 Sep 2015 15:15:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080008080300080701080401"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 13:15:43 -0000

This is a multi-part message in MIME format.
--------------080008080300080701080401
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Ladislav Lhotka je 25.9.2015 ob 13:44 napisal:
> Jernej Tuljak  writes:
>
>> Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
>>> Jernej Tuljak  writes:
>>>
>>>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>>>>> Jernej Tuljak  wrote:
>>>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>>>>> Jernej Tuljak  writes:
>>>>>>>
>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>>>>>>>
>>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation case
>>>>>>>>>>>> does not consider that an "augment" may specify a top-level "choice"
>>>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the target
>>>>>>>>>>>> node. There will be no initial context node for the expression in such
>>>>>>>>>>>> a case.
>>>>>>>>>>>>
>>>>>>>>>>>>       leaf enable-foos {
>>>>>>>>>>>>         type boolean;
>>>>>>>>>>>>       }
>>>>>>>>>>>>       choice ch1 {
>>>>>>>>>>>>         case foo {
>>>>>>>>>>>>           choice foos {
>>>>>>>>>>>>             when "enable-foos = 'true'";
>>>>>>>>>>>>             leaf foo1 {
>>>>>>>>>>>>               type string;
>>>>>>>>>>>>             }
>>>>>>>>>>>>             leaf foo2 {
>>>>>>>>>>>>               type string;
>>>>>>>>>>>>             }
>>>>>>>>>>>>           }
>>>>>>>>>>>>         }
>>>>>>>>>>>>         container meh;
>>>>>>>>>>>>       }
>>>>>>>>>>>>
>>>>>>>>>>>>       augment "/ch1/foo/foos" {
>>>>>>>>>>>>         when "enable-foos = 'true'";
>>>>>>>>>>>>         leaf foo3 {
>>>>>>>>>>>>           type string;
>>>>>>>>>>>>         }
>>>>>>>>>>>>       }
>>>>>>>>>>>>
>>>>>>>>>>>> OLD:
>>>>>>>>>>>>
>>>>>>>>>>>>        o If the "when" statement is a child of an "augment" statement,
>>>>>>>>>>>>        then
>>>>>>>>>>>>           the context node is the augment's target node in the data tree,
>>>>>>>>>>>>           if
>>>>>>>>>>>>           the target node is a data node.  Otherwise, the context node is
>>>>>>>>>>>>           the closest ancestor node to the target node that is also a data
>>>>>>>>>>>>           node.
>>>>>>>>>>>>
>>>>>>>>>>>> NEW:
>>>>>>>>>>>>
>>>>>>>>>>>>        o If the "when" statement is a child of an "augment" statement,
>>>>>>>>>>>>        then
>>>>>>>>>>>>           the context node is the augment's target node in the data tree,
>>>>>>>>>>>>           if
>>>>>>>>>>>>           the target node is a data node.  Otherwise, the context node is
>>>>>>>>>>>>           the closest ancestor node to the target node that is also a data
>>>>>>>>>>>>           node. If no such node exists, the context node is the root node.
>>>>>>>>>>>>
>>>>>>>>>>> Good catch, I support this change.
>>>>>>>>>>>
>>>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when expression
>>>>>>>>>>> must not reference nodes that are made conditional through that when
>>>>>>>>>>> statement. I can’t find this rule in the text.
>>>>>>>>>> The "no referencing the initial context node and its descendants" text
>>>>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>>>>> seriously broken and could lead to deadlocks.
>>>>>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>>>>>> node
>>>>>>>> with no value and child nodes has been introduced.
>>>>>>> Not really, the dummy node solves the problem of a non-existent
>>>>>>> context
>>>>>>> node.
>>>>>> Are you referring to "existence" in the instance document or the
>>>>>> schema tree? Why is there no need for "no children, no value dummy" in
>>>>>> 1st and 2nd bullet?
>>>>> In these cases, the context node is well-defined anyway.  But I think
>>>>> that also these bullets need to have text that make sure that the
>>>>> outcome is deterministic in all cases, such as:
>>>>>
>>>>>      augement /foo {
>>>>>        when "bar > 1";
>>>>>        leaf bar { type int32; }
>>>>>      }
>>>>>
>>>>> or
>>>>>
>>>>>      grouping foo {
>>>>>        leaf bar { type int32; }
>>>>>      }
>>>>>      container x {
>>>>>        uses foo {
>>>>>          when "bar > 1";
>>>>>        }
>>>>>      }
>>>>>
>>>>>
>>>>> etc.
>>>>>
>>>>> So I suggest this NEW text:
>>>>>
>>>>>
>>>>>       o  If the "when" statement is a child of an "augment" statement, then
>>>>>          the context node is the augment's target node in the data tree, if
>>>>>          the target node is a data node.  Otherwise, the context node is
>>>>>          the closest ancestor node to the target node that is also a data
>>>>>          node.  If no such node exists, the context node is the root node.
>>>>>          The accessible tree is tentatively altered during the processing
>>>>>          of the XPath expression by removing all instances (if any) of the
>>>>>          nodes added by the "augment" statement.
>>>>>
>>>>>       o  If the "when" statement is a child of a "uses", "choice", or
>>>>>          "case" statement, then the context node is the closest ancestor
>>>>>          node to the "uses", "choice", or "case" node that is also a data
>>>>>          node.  If no such node exists, the context node is the root node.
>>>>>          The accessible tree is tentatively altered during the processing
>>>>>          of the XPath expression by removing all instances (if any) of the
>>>>>          nodes added by the "uses", "choice", or "case" statement.
>>>>>
>>>>>       o  If the "when" statement is a child of any other data definition
>>>>>          statement, the accessible tree is tentatively altered during the
>>>>>          processing of the XPath expression by replacing all instances (if
>>>>>          any) of the data node for which the "when" statement is defined
>>>>>          with a single dummy node with the same name, but with no value and
>>>>>          no children.  The context node is this dummy node.
>>>>>
>>>> +1
>>>>
>>>>      container foo {
>>>>        when "child::* or child::text() or not(self::*)"; // always false
>>>>        leaf bar {
>>>>          type string;
>>>>        }
>>>>      }
>>> I think it would be better to clearly state that a "when" expression
>>> MUST NOT refer to nodes that are made conditional by the same "when"
>>> statement - it's similar to the rule that forbids mutual references.
>>> This would also cover all uses of "when".
>>>
>>> The above example would be really confusing if the "bar" instance is
>>> present.
>> It is true that this introduces a caveat that is bound to confuse end
>> YANG users.
>>
>>>    I also don't like the fact that "when" and "must" would give
>>> different results in this case.
>> Just to be clear, you would like this, right?
>>
>> NEW:
>>
>>      The XPath expression is conceptually evaluated in the following
>>      context, in addition to the definition inSection 6.4.1
>> :
>>
>>      o  If the "when" statement is a child of an "augment" statement, then
>>         the context node is the augment's target node in the data tree, if
>>         the target node is a data node.  Otherwise, the context node is
>>         the closest ancestor node to the target node that is also a data
>>         node. If no such node exists, the context node is the root node.
>>
>>      o  If the "when" statement is a child of a "uses", "choice", or
>>         "case" statement, then the context node is the closest ancestor
>>         node to the "uses", "choice", or "case" node that is also a data
>>         node.  If no such node exists, the context node is the root node.
>>
>>      o  If the "when" statement is a child of any other data definition
>>         statement, the context node is the node in the accessible tree for
>>         which the "when" statement is defined.
>>      
>>      An XPath expression MUST NOT reference nodes that are made conditional
>>      by the "when" statement that defines it.
> Yes, plus the other two rules that are already in 6020bis:
>
> If the XPath expression references any node that also has associated
> "when" statements, these "when" expressions MUST be evaluated first.
>
> There MUST NOT be any circular dependencies in these "when" expressions.
>> I don't see a case in which the context node is non-existent (in the
>> schema tree) in any of the three bullets, even without "no value, no
>> descendants" dummy node.
> The third bullet is aimed at cases like this:
>
> leaf foo {
>      when "../bar > 0";
>      mandatory true;
>      ...
> }
>
> If there is no instance of "foo", a validator has to find out whether
> the "mandatory" statement applies (and the absence of "foo" is thus a
> schema error), or whether it is overruled by the "when" expression being
> false. But in order to be able to evaluate that expression, XPath
> requires a context node in the instance document, so we need to
> tentatively add one.

Then the dummy node text is broken all together. It instructs to modify 
the accessible tree (schema), instead of instructing to instantiate a 
dummy if an instance of the context node does not exist. A context node 
always exists in the schema tree. IMO, this needs to be fixed in order 
to prevent the interpretation I came up with (and also Balazs, 
independently). This interpretation was clearly not the intention.

NEW:

    The XPath expression is conceptually evaluated in the following
    context, in addition to the definition inSection 6.4.1 
:

    o  If the "when" statement is a child of an "augment" statement, then
       the context node is the augment's target node in the data tree, if
       the target node is a data node.  Otherwise, the context node is
       the closest ancestor node to the target node that is also a data
       node. If no such node exists, the context node is the root node.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.

    o  If the "when" statement is a child of any other data definition
       statement, the context node is the node in the accessible tree for
       which the "when" statement is defined.
       
    If an instance of the context node does not exist during processing
    of the XPath expression, the context node is tentatively instantiated
    as a single dummy node with the same name, but with no value and no
    children, and merged into the instance of the accessible tree.

    The result of the XPath expression is converted to a boolean value
    using the standard XPath rules.

    An XPath expression MUST NOT reference nodes that are made conditional
    by the "when" statement that defines it.

    If the XPath expression references any node that also has associated
    "when" statements, these "when" expressions MUST be evaluated first.

    There MUST NOT be any circular dependencies in these "when"
    expressions.

Something like this also takes care of Martin's example ("* = 42").

Jernej

>
> Lada
>
>> This text implies that:
>>
>>     container foo {
>>       when "descendant-or-self::node()"; // semantic error
>>       leaf bar {
>>         type string;
>>       }
>>     }
>>
>> This is actually what our YANG 1.0 implementation currently does, though
>> it only generates a warning.
>>
>> Jernej
>>
>>> Lada
>>>
>>>> Jernej
>>>>
>>>>> /martin
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod


--------------080008080300080701080401
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Ladislav Lhotka je 25.9.2015 ob
      13:44 napisal:

    

    

      
Jernej Tuljak <jernejt@mg-soft.si> writes:



      

        
Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:


        

          
Jernej Tuljak <jernejt@mg-soft.si> writes:



          

            
Martin Bjorklund je 24.9.2015 ob 13:54 napisal:


            

              
Jernej Tuljak <jernejt@mg-soft.si> wrote:


              

                
Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:


                

                  
Jernej Tuljak <jernejt@mg-soft.si> writes:



                  

                    
Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:


                    

                      

                        
On 23 Sep 2015, at 12:37, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:


                        

                          

                            
On 23 Sep 2015, at 11:45, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Section 7.21.5., the first bullet describing the augmentation case
does not consider that an "augment" may specify a top-level "choice"
or a "choice"/"case" nested within a top-level "choice" as the target
node. There will be no initial context node for the expression in such
a case.

     leaf enable-foos {
       type boolean;
     }
     choice ch1 {
       case foo {
         choice foos {
           when "enable-foos = 'true'";
           leaf foo1 {
             type string;
           }
           leaf foo2 {
             type string;
           }
         }
       }
       container meh;
     }

     augment "/ch1/foo/foos" {
       when "enable-foos = 'true'";
       leaf foo3 {
         type string;
       }
     }

OLD:

      o If the "when" statement is a child of an "augment" statement,
      then
         the context node is the augment's target node in the data tree,
         if
         the target node is a data node.  Otherwise, the context node is
         the closest ancestor node to the target node that is also a data
         node.

NEW:

      o If the "when" statement is a child of an "augment" statement,
      then
         the context node is the augment's target node in the data tree,
         if
         the target node is a data node.  Otherwise, the context node is
         the closest ancestor node to the target node that is also a data
         node. If no such node exists, the context node is the root node.



                          

                          
Good catch, I support this change.

Also regarding sec. 7.21.5, I think we agreed that a when expression
must not reference nodes that are made conditional through that when
statement. I can’t find this rule in the text.


                        

                        
The "no referencing the initial context node and its descendants" text
is currently in the guidelines draft only (6087bis).


                      

                      
IMO this should be a hard rule in 6020bis. Such expressions are
seriously broken and could lead to deadlocks.


                    

                    
I think that was the purpose of the change in 3rd bullet. A "dummy"
node
with no value and child nodes has been introduced.


                  

                  
Not really, the dummy node solves the problem of a non-existent
context
node.


                

                
Are you referring to "existence" in the instance document or the
schema tree? Why is there no need for "no children, no value dummy" in
1st and 2nd bullet?


              

              
In these cases, the context node is well-defined anyway.  But I think
that also these bullets need to have text that make sure that the
outcome is deterministic in all cases, such as:

    augement /foo {
      when "bar > 1";
      leaf bar { type int32; }
    }

or

    grouping foo {
      leaf bar { type int32; }
    }
    container x {
      uses foo {
        when "bar > 1";
      }
    }


etc.

So I suggest this NEW text:


     o  If the "when" statement is a child of an "augment" statement, then
        the context node is the augment's target node in the data tree, if
        the target node is a data node.  Otherwise, the context node is
        the closest ancestor node to the target node that is also a data
        node.  If no such node exists, the context node is the root node.
        The accessible tree is tentatively altered during the processing
        of the XPath expression by removing all instances (if any) of the
        nodes added by the "augment" statement.

     o  If the "when" statement is a child of a "uses", "choice", or
        "case" statement, then the context node is the closest ancestor
        node to the "uses", "choice", or "case" node that is also a data
        node.  If no such node exists, the context node is the root node.
        The accessible tree is tentatively altered during the processing
        of the XPath expression by removing all instances (if any) of the
        nodes added by the "uses", "choice", or "case" statement.

     o  If the "when" statement is a child of any other data definition
        statement, the accessible tree is tentatively altered during the
        processing of the XPath expression by replacing all instances (if
        any) of the data node for which the "when" statement is defined
        with a single dummy node with the same name, but with no value and
        no children.  The context node is this dummy node.



            

            
+1

    container foo {
      when "child::* or child::text() or not(self::*)"; // always false
      leaf bar {
        type string;
      }
    }


          

          
I think it would be better to clearly state that a "when" expression
MUST NOT refer to nodes that are made conditional by the same "when"
statement - it's similar to the rule that forbids mutual references.
This would also cover all uses of "when".

The above example would be really confusing if the "bar" instance is
present.


        

        
It is true that this introduces a caveat that is bound to confuse end 
YANG users.



        

          
  I also don't like the fact that "when" and "must" would give
different results in this case.


        

        
Just to be clear, you would like this, right?

NEW:

    The XPath expression is conceptually evaluated in the following
    context, in addition to the definition inSection 6.4.1 
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07#section-6.4.1>:

    o  If the "when" statement is a child of an "augment" statement, then
       the context node is the augment's target node in the data tree, if
       the target node is a data node.  Otherwise, the context node is
       the closest ancestor node to the target node that is also a data
       node. If no such node exists, the context node is the root node.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.

    o  If the "when" statement is a child of any other data definition
       statement, the context node is the node in the accessible tree for
       which the "when" statement is defined.
    
    An XPath expression MUST NOT reference nodes that are made conditional
    by the "when" statement that defines it.


      

      
Yes, plus the other two rules that are already in 6020bis:

If the XPath expression references any node that also has associated
"when" statements, these "when" expressions MUST be evaluated first.

There MUST NOT be any circular dependencies in these "when" expressions.


      

        
I don't see a case in which the context node is non-existent (in the 
schema tree) in any of the three bullets, even without "no value, no 
descendants" dummy node.


      

      
The third bullet is aimed at cases like this:

leaf foo {
    when "../bar > 0";
    mandatory true;
    ...
}

If there is no instance of "foo", a validator has to find out whether
the "mandatory" statement applies (and the absence of "foo" is thus a
schema error), or whether it is overruled by the "when" expression being
false. But in order to be able to evaluate that expression, XPath
requires a context node in the instance document, so we need to
tentatively add one.

    

    

    Then the dummy node text is broken all together. It instructs to
    modify the accessible tree (schema), instead of instructing to
    instantiate a dummy if an instance of the context node does not
    exist. A context node always exists in the schema tree. IMO, this
    needs to be fixed in order to prevent the interpretation I came up
    with (and also Balazs, independently). This interpretation was
    clearly not the intention.

    

    NEW:

    
   The XPath expression is conceptually evaluated in the following
   context, in addition to the definition in Section 6.4.1:

   o  If the "when" statement is a child of an "augment" statement, then
      the context node is the augment's target node in the data tree, if
      the target node is a data node.  Otherwise, the context node is
      the closest ancestor node to the target node that is also a data
      node. If no such node exists, the context node is the root node.

   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the "uses", "choice", or "case" node that is also a data
      node.  If no such node exists, the context node is the root node.

   o  If the "when" statement is a child of any other data definition
      statement, the context node is the node in the accessible tree for
      which the "when" statement is defined.
      
   If an instance of the context node does not exist during processing
   of the XPath expression, the context node is tentatively instantiated
   as a single dummy node with the same name, but with no value and no 
   children, and merged into the instance of the accessible tree.

   The result of the XPath expression is converted to a boolean value
   using the standard XPath rules.

   An XPath expression MUST NOT reference nodes that are made conditional
   by the "when" statement that defines it.

   If the XPath expression references any node that also has associated
   "when" statements, these "when" expressions MUST be evaluated first.

   There MUST NOT be any circular dependencies in these "when"
   expressions.


    Something like this also takes care of Martin's example ("* = 42").

    

    Jernej 

    

    

      

Lada



      

        
This text implies that:

   container foo {
     when "descendant-or-self::node()"; // semantic error
     leaf bar {
       type string;
     }
   }

This is actually what our YANG 1.0 implementation currently does, though 
it only generates a warning.

Jernej



        

          
Lada



          

            
Jernej



            

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


            

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


          

        

        

      

      

    

    

  


--------------080008080300080701080401--


From nobody Fri Sep 25 06:22:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EFE1A02F1 for ; Fri, 25 Sep 2015 06:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu1EO29Ib1H5 for ; Fri, 25 Sep 2015 06:22:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 64A651A0275 for ; Fri, 25 Sep 2015 06:22:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 912BF1AE07F0; Fri, 25 Sep 2015 15:22:24 +0200 (CEST)
Date: Fri, 25 Sep 2015 15:22:24 +0200 (CEST)
Message-Id: <20150925.152224.1416615960207331298.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <560548F4.8080505@mg-soft.si>
References: <56052F11.3010903@mg-soft.si>  <560548F4.8080505@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 13:22:29 -0000

SmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPiB3cm90ZToNCj4gTGFkaXNsYXYgTGhv
dGthIGplIDI1LjkuMjAxNSBvYiAxMzo0NCBuYXBpc2FsOg0KPiA+IEplcm5laiBUdWxqYWsgPGpl
cm5lanRAbWctc29mdC5zaT4gd3JpdGVzOg0KPiA+DQo+ID4+IExhZGlzbGF2IExob3RrYSBqZSAy
NS45LjIwMTUgb2IgOTo1OCBuYXBpc2FsOg0KPiA+Pj4gSmVybmVqIFR1bGphayA8amVybmVqdEBt
Zy1zb2Z0LnNpPiB3cml0ZXM6DQo+ID4+Pg0KPiA+Pj4+IE1hcnRpbiBCam9ya2x1bmQgamUgMjQu
OS4yMDE1IG9iIDEzOjU0IG5hcGlzYWw6DQo+ID4+Pj4+IEplcm5laiBUdWxqYWsgPGplcm5lanRA
bWctc29mdC5zaT4gd3JvdGU6DQo+ID4+Pj4+PiBMYWRpc2xhdiBMaG90a2EgamUgMjMuOS4yMDE1
IG9iIDE0OjI5IG5hcGlzYWw6DQo+ID4+Pj4+Pj4gSmVybmVqIFR1bGphayA8amVybmVqdEBtZy1z
b2Z0LnNpPiB3cml0ZXM6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGthIGpl
IDIzLjkuMjAxNSBvYiAxMjo1MiBuYXBpc2FsOg0KPiA+Pj4+Pj4+Pj4+IE9uIDIzIFNlcCAyMDE1
LCBhdCAxMjozNywgSmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPiB3cm90ZToNCj4g
Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IExhZGlzbGF2IExob3RrYSBqZSAyMy45LjIwMTUgb2Ig
MTE6NTggbmFwaXNhbDoNCj4gPj4+Pj4+Pj4+Pj4+IE9uIDIzIFNlcCAyMDE1LCBhdCAxMTo0NSwg
SmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPg0KPiA+Pj4+Pj4+Pj4+Pj4gd3JvdGU6
DQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gU2VjdGlvbiA3LjIxLjUuLCB0aGUgZmly
c3QgYnVsbGV0IGRlc2NyaWJpbmcgdGhlIGF1Z21lbnRhdGlvbg0KPiA+Pj4+Pj4+Pj4+Pj4gY2Fz
ZQ0KPiA+Pj4+Pj4+Pj4+Pj4gZG9lcyBub3QgY29uc2lkZXIgdGhhdCBhbiAiYXVnbWVudCIgbWF5
IHNwZWNpZnkgYSB0b3AtbGV2ZWwNCj4gPj4+Pj4+Pj4+Pj4+ICJjaG9pY2UiDQo+ID4+Pj4+Pj4+
Pj4+PiBvciBhICJjaG9pY2UiLyJjYXNlIiBuZXN0ZWQgd2l0aGluIGEgdG9wLWxldmVsICJjaG9p
Y2UiIGFzIHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4gdGFyZ2V0DQo+ID4+Pj4+Pj4+Pj4+PiBub2RlLiBU
aGVyZSB3aWxsIGJlIG5vIGluaXRpYWwgY29udGV4dCBub2RlIGZvciB0aGUgZXhwcmVzc2lvbiBp
bg0KPiA+Pj4+Pj4+Pj4+Pj4gc3VjaA0KPiA+Pj4+Pj4+Pj4+Pj4gYSBjYXNlLg0KPiA+Pj4+Pj4+
Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgIGxlYWYgZW5hYmxlLWZvb3Mgew0KPiA+Pj4+Pj4+
Pj4+Pj4gICAgICAgICB0eXBlIGJvb2xlYW47DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICB9DQo+ID4+
Pj4+Pj4+Pj4+PiAgICAgICBjaG9pY2UgY2gxIHsNCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICAgY2Fz
ZSBmb28gew0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIGNob2ljZSBmb29zIHsNCj4gPj4+Pj4+
Pj4+Pj4+ICAgICAgICAgICAgIHdoZW4gImVuYWJsZS1mb29zID0gJ3RydWUnIjsNCj4gPj4+Pj4+
Pj4+Pj4+ICAgICAgICAgICAgIGxlYWYgZm9vMSB7DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg
ICAgIHR5cGUgc3RyaW5nOw0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgfQ0KPiA+Pj4+Pj4+
Pj4+Pj4gICAgICAgICAgICAgbGVhZiBmb28yIHsNCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAg
ICAgdHlwZSBzdHJpbmc7DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICB9DQo+ID4+Pj4+Pj4+
Pj4+PiAgICAgICAgICAgfQ0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICB9DQo+ID4+Pj4+Pj4+Pj4+
PiAgICAgICAgIGNvbnRhaW5lciBtZWg7DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICB9DQo+ID4+Pj4+
Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgYXVnbWVudCAiL2NoMS9mb28vZm9vcyIgew0K
PiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICB3aGVuICJlbmFibGUtZm9vcyA9ICd0cnVlJyI7DQo+ID4+
Pj4+Pj4+Pj4+PiAgICAgICAgIGxlYWYgZm9vMyB7DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg
dHlwZSBzdHJpbmc7DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgIH0NCj4gPj4+Pj4+Pj4+Pj4+ICAg
ICAgIH0NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBPTEQ6DQo+ID4+Pj4+Pj4+Pj4+
Pg0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgIG8gSWYgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgYSBj
aGlsZCBvZiBhbiAiYXVnbWVudCINCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICBzdGF0ZW1lbnQsDQo+
ID4+Pj4+Pj4+Pj4+PiAgICAgICAgdGhlbg0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIHRoZSBj
b250ZXh0IG5vZGUgaXMgdGhlIGF1Z21lbnQncyB0YXJnZXQgbm9kZSBpbiB0aGUNCj4gPj4+Pj4+
Pj4+Pj4+ICAgICAgICAgICBkYXRhIHRyZWUsDQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgaWYN
Cj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICB0aGUgdGFyZ2V0IG5vZGUgaXMgYSBkYXRhIG5vZGUu
ICBPdGhlcndpc2UsIHRoZSBjb250ZXh0DQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgbm9kZSBp
cw0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8g
dGhlIHRhcmdldCBub2RlIHRoYXQgaXMNCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICBhbHNvIGEg
ZGF0YQ0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIG5vZGUuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+
Pj4+Pj4+Pj4+Pj4gTkVXOg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICBv
IElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiDQo+ID4+
Pj4+Pj4+Pj4+PiAgICAgICAgc3RhdGVtZW50LA0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgIHRoZW4N
Cj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBhdWdtZW50
J3MgdGFyZ2V0IG5vZGUgaW4gdGhlDQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgZGF0YSB0cmVl
LA0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIGlmDQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg
dGhlIHRhcmdldCBub2RlIGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0aGUgY29udGV4dA0K
PiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIG5vZGUgaXMNCj4gPj4+Pj4+Pj4+Pj4+ICAgICAgICAg
ICB0aGUgY2xvc2VzdCBhbmNlc3RvciBub2RlIHRvIHRoZSB0YXJnZXQgbm9kZSB0aGF0IGlzDQo+
ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgYWxzbyBhIGRhdGENCj4gPj4+Pj4+Pj4+Pj4+ICAgICAg
ICAgICBub2RlLiBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBub2RlIGlzIHRo
ZQ0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgIHJvb3Qgbm9kZS4NCj4gPj4+Pj4+Pj4+Pj4+DQo+
ID4+Pj4+Pj4+Pj4+IEdvb2QgY2F0Y2gsIEkgc3VwcG9ydCB0aGlzIGNoYW5nZS4NCj4gPj4+Pj4+
Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gQWxzbyByZWdhcmRpbmcgc2VjLiA3LjIxLjUsIEkgdGhpbmsg
d2UgYWdyZWVkIHRoYXQgYSB3aGVuDQo+ID4+Pj4+Pj4+Pj4+IGV4cHJlc3Npb24NCj4gPj4+Pj4+
Pj4+Pj4gbXVzdCBub3QgcmVmZXJlbmNlIG5vZGVzIHRoYXQgYXJlIG1hZGUgY29uZGl0aW9uYWwg
dGhyb3VnaCB0aGF0DQo+ID4+Pj4+Pj4+Pj4+IHdoZW4NCj4gPj4+Pj4+Pj4+Pj4gc3RhdGVtZW50
LiBJIGNhbuKAmXQgZmluZCB0aGlzIHJ1bGUgaW4gdGhlIHRleHQuDQo+ID4+Pj4+Pj4+Pj4gVGhl
ICJubyByZWZlcmVuY2luZyB0aGUgaW5pdGlhbCBjb250ZXh0IG5vZGUgYW5kIGl0cyBkZXNjZW5k
YW50cyINCj4gPj4+Pj4+Pj4+PiB0ZXh0DQo+ID4+Pj4+Pj4+Pj4gaXMgY3VycmVudGx5IGluIHRo
ZSBndWlkZWxpbmVzIGRyYWZ0IG9ubHkgKDYwODdiaXMpLg0KPiA+Pj4+Pj4+Pj4gSU1PIHRoaXMg
c2hvdWxkIGJlIGEgaGFyZCBydWxlIGluIDYwMjBiaXMuIFN1Y2ggZXhwcmVzc2lvbnMgYXJlDQo+
ID4+Pj4+Pj4+PiBzZXJpb3VzbHkgYnJva2VuIGFuZCBjb3VsZCBsZWFkIHRvIGRlYWRsb2Nrcy4N
Cj4gPj4+Pj4+Pj4gSSB0aGluayB0aGF0IHdhcyB0aGUgcHVycG9zZSBvZiB0aGUgY2hhbmdlIGlu
IDNyZCBidWxsZXQuIEEgImR1bW15Ig0KPiA+Pj4+Pj4+PiBub2RlDQo+ID4+Pj4+Pj4+IHdpdGgg
bm8gdmFsdWUgYW5kIGNoaWxkIG5vZGVzIGhhcyBiZWVuIGludHJvZHVjZWQuDQo+ID4+Pj4+Pj4g
Tm90IHJlYWxseSwgdGhlIGR1bW15IG5vZGUgc29sdmVzIHRoZSBwcm9ibGVtIG9mIGEgbm9uLWV4
aXN0ZW50DQo+ID4+Pj4+Pj4gY29udGV4dA0KPiA+Pj4+Pj4+IG5vZGUuDQo+ID4+Pj4+PiBBcmUg
eW91IHJlZmVycmluZyB0byAiZXhpc3RlbmNlIiBpbiB0aGUgaW5zdGFuY2UgZG9jdW1lbnQgb3Ig
dGhlDQo+ID4+Pj4+PiBzY2hlbWEgdHJlZT8gV2h5IGlzIHRoZXJlIG5vIG5lZWQgZm9yICJubyBj
aGlsZHJlbiwgbm8gdmFsdWUgZHVtbXkiIGluDQo+ID4+Pj4+PiAxc3QgYW5kIDJuZCBidWxsZXQ/
DQo+ID4+Pj4+IEluIHRoZXNlIGNhc2VzLCB0aGUgY29udGV4dCBub2RlIGlzIHdlbGwtZGVmaW5l
ZCBhbnl3YXkuICBCdXQgSSB0aGluaw0KPiA+Pj4+PiB0aGF0IGFsc28gdGhlc2UgYnVsbGV0cyBu
ZWVkIHRvIGhhdmUgdGV4dCB0aGF0IG1ha2Ugc3VyZSB0aGF0IHRoZQ0KPiA+Pj4+PiBvdXRjb21l
IGlzIGRldGVybWluaXN0aWMgaW4gYWxsIGNhc2VzLCBzdWNoIGFzOg0KPiA+Pj4+Pg0KPiA+Pj4+
PiAgICAgIGF1Z2VtZW50IC9mb28gew0KPiA+Pj4+PiAgICAgICAgd2hlbiAiYmFyID4gMSI7DQo+
ID4+Pj4+ICAgICAgICBsZWFmIGJhciB7IHR5cGUgaW50MzI7IH0NCj4gPj4+Pj4gICAgICB9DQo+
ID4+Pj4+DQo+ID4+Pj4+IG9yDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgZ3JvdXBpbmcgZm9vIHsN
Cj4gPj4+Pj4gICAgICAgIGxlYWYgYmFyIHsgdHlwZSBpbnQzMjsgfQ0KPiA+Pj4+PiAgICAgIH0N
Cj4gPj4+Pj4gICAgICBjb250YWluZXIgeCB7DQo+ID4+Pj4+ICAgICAgICB1c2VzIGZvbyB7DQo+
ID4+Pj4+ICAgICAgICAgIHdoZW4gImJhciA+IDEiOw0KPiA+Pj4+PiAgICAgICAgfQ0KPiA+Pj4+
PiAgICAgIH0NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gZXRjLg0KPiA+Pj4+Pg0KPiA+Pj4+
PiBTbyBJIHN1Z2dlc3QgdGhpcyBORVcgdGV4dDoNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4g
ICAgICAgbyBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFuICJhdWdtZW50
IiBzdGF0ZW1lbnQsDQo+ID4+Pj4+ICAgICAgIHRoZW4NCj4gPj4+Pj4gICAgICAgICAgdGhlIGNv
bnRleHQgbm9kZSBpcyB0aGUgYXVnbWVudCdzIHRhcmdldCBub2RlIGluIHRoZSBkYXRhIHRyZWUs
DQo+ID4+Pj4+ICAgICAgICAgIGlmDQo+ID4+Pj4+ICAgICAgICAgIHRoZSB0YXJnZXQgbm9kZSBp
cyBhIGRhdGEgbm9kZS4gIE90aGVyd2lzZSwgdGhlIGNvbnRleHQgbm9kZSBpcw0KPiA+Pj4+PiAg
ICAgICAgICB0aGUgY2xvc2VzdCBhbmNlc3RvciBub2RlIHRvIHRoZSB0YXJnZXQgbm9kZSB0aGF0
IGlzIGFsc28gYQ0KPiA+Pj4+PiAgICAgICAgICBkYXRhDQo+ID4+Pj4+ICAgICAgICAgIG5vZGUu
ICBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBub2RlIGlzIHRoZSByb290DQo+
ID4+Pj4+ICAgICAgICAgIG5vZGUuDQo+ID4+Pj4+ICAgICAgICAgIFRoZSBhY2Nlc3NpYmxlIHRy
ZWUgaXMgdGVudGF0aXZlbHkgYWx0ZXJlZCBkdXJpbmcgdGhlDQo+ID4+Pj4+ICAgICAgICAgIHBy
b2Nlc3NpbmcNCj4gPj4+Pj4gICAgICAgICAgb2YgdGhlIFhQYXRoIGV4cHJlc3Npb24gYnkgcmVt
b3ZpbmcgYWxsIGluc3RhbmNlcyAoaWYgYW55KSBvZg0KPiA+Pj4+PiAgICAgICAgICB0aGUNCj4g
Pj4+Pj4gICAgICAgICAgbm9kZXMgYWRkZWQgYnkgdGhlICJhdWdtZW50IiBzdGF0ZW1lbnQuDQo+
ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIG8gIElmIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGEgY2hp
bGQgb2YgYSAidXNlcyIsICJjaG9pY2UiLCBvcg0KPiA+Pj4+PiAgICAgICAgICAiY2FzZSIgc3Rh
dGVtZW50LCB0aGVuIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIGNsb3Nlc3QgYW5jZXN0b3INCj4g
Pj4+Pj4gICAgICAgICAgbm9kZSB0byB0aGUgInVzZXMiLCAiY2hvaWNlIiwgb3IgImNhc2UiIG5v
ZGUgdGhhdCBpcyBhbHNvIGENCj4gPj4+Pj4gICAgICAgICAgZGF0YQ0KPiA+Pj4+PiAgICAgICAg
ICBub2RlLiAgSWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUg
cm9vdA0KPiA+Pj4+PiAgICAgICAgICBub2RlLg0KPiA+Pj4+PiAgICAgICAgICBUaGUgYWNjZXNz
aWJsZSB0cmVlIGlzIHRlbnRhdGl2ZWx5IGFsdGVyZWQgZHVyaW5nIHRoZQ0KPiA+Pj4+PiAgICAg
ICAgICBwcm9jZXNzaW5nDQo+ID4+Pj4+ICAgICAgICAgIG9mIHRoZSBYUGF0aCBleHByZXNzaW9u
IGJ5IHJlbW92aW5nIGFsbCBpbnN0YW5jZXMgKGlmIGFueSkgb2YNCj4gPj4+Pj4gICAgICAgICAg
dGhlDQo+ID4+Pj4+ICAgICAgICAgIG5vZGVzIGFkZGVkIGJ5IHRoZSAidXNlcyIsICJjaG9pY2Ui
LCBvciAiY2FzZSIgc3RhdGVtZW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBvICBJZiB0aGUg
IndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFueSBvdGhlciBkYXRhIGRlZmluaXRpb24N
Cj4gPj4+Pj4gICAgICAgICAgc3RhdGVtZW50LCB0aGUgYWNjZXNzaWJsZSB0cmVlIGlzIHRlbnRh
dGl2ZWx5IGFsdGVyZWQgZHVyaW5nDQo+ID4+Pj4+ICAgICAgICAgIHRoZQ0KPiA+Pj4+PiAgICAg
ICAgICBwcm9jZXNzaW5nIG9mIHRoZSBYUGF0aCBleHByZXNzaW9uIGJ5IHJlcGxhY2luZyBhbGwg
aW5zdGFuY2VzDQo+ID4+Pj4+ICAgICAgICAgIChpZg0KPiA+Pj4+PiAgICAgICAgICBhbnkpIG9m
IHRoZSBkYXRhIG5vZGUgZm9yIHdoaWNoIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGRlZmluZWQN
Cj4gPj4+Pj4gICAgICAgICAgd2l0aCBhIHNpbmdsZSBkdW1teSBub2RlIHdpdGggdGhlIHNhbWUg
bmFtZSwgYnV0IHdpdGggbm8gdmFsdWUNCj4gPj4+Pj4gICAgICAgICAgYW5kDQo+ID4+Pj4+ICAg
ICAgICAgIG5vIGNoaWxkcmVuLiAgVGhlIGNvbnRleHQgbm9kZSBpcyB0aGlzIGR1bW15IG5vZGUu
DQo+ID4+Pj4+DQo+ID4+Pj4gKzENCj4gPj4+Pg0KPiA+Pj4+ICAgICAgY29udGFpbmVyIGZvbyB7
DQo+ID4+Pj4gICAgICAgIHdoZW4gImNoaWxkOjoqIG9yIGNoaWxkOjp0ZXh0KCkgb3Igbm90KHNl
bGY6OiopIjsgLy8gYWx3YXlzIGZhbHNlDQo+ID4+Pj4gICAgICAgIGxlYWYgYmFyIHsNCj4gPj4+
PiAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPj4+PiAgICAgICAgfQ0KPiA+Pj4+ICAgICAgfQ0K
PiA+Pj4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2xlYXJseSBzdGF0ZSB0aGF0IGEg
IndoZW4iIGV4cHJlc3Npb24NCj4gPj4+IE1VU1QgTk9UIHJlZmVyIHRvIG5vZGVzIHRoYXQgYXJl
IG1hZGUgY29uZGl0aW9uYWwgYnkgdGhlIHNhbWUgIndoZW4iDQo+ID4+PiBzdGF0ZW1lbnQgLSBp
dCdzIHNpbWlsYXIgdG8gdGhlIHJ1bGUgdGhhdCBmb3JiaWRzIG11dHVhbCByZWZlcmVuY2VzLg0K
PiA+Pj4gVGhpcyB3b3VsZCBhbHNvIGNvdmVyIGFsbCB1c2VzIG9mICJ3aGVuIi4NCj4gPj4+DQo+
ID4+PiBUaGUgYWJvdmUgZXhhbXBsZSB3b3VsZCBiZSByZWFsbHkgY29uZnVzaW5nIGlmIHRoZSAi
YmFyIiBpbnN0YW5jZSBpcw0KPiA+Pj4gcHJlc2VudC4NCj4gPj4gSXQgaXMgdHJ1ZSB0aGF0IHRo
aXMgaW50cm9kdWNlcyBhIGNhdmVhdCB0aGF0IGlzIGJvdW5kIHRvIGNvbmZ1c2UgZW5kDQo+ID4+
IFlBTkcgdXNlcnMuDQo+ID4+DQo+ID4+PiAgICBJIGFsc28gZG9uJ3QgbGlrZSB0aGUgZmFjdCB0
aGF0ICJ3aGVuIiBhbmQgIm11c3QiIHdvdWxkIGdpdmUNCj4gPj4+IGRpZmZlcmVudCByZXN1bHRz
IGluIHRoaXMgY2FzZS4NCj4gPj4gSnVzdCB0byBiZSBjbGVhciwgeW91IHdvdWxkIGxpa2UgdGhp
cywgcmlnaHQ/DQo+ID4+DQo+ID4+IE5FVzoNCj4gPj4NCj4gPj4gICAgICBUaGUgWFBhdGggZXhw
cmVzc2lvbiBpcyBjb25jZXB0dWFsbHkgZXZhbHVhdGVkIGluIHRoZSBmb2xsb3dpbmcNCj4gPj4g
ICAgICBjb250ZXh0LCBpbiBhZGRpdGlvbiB0byB0aGUgZGVmaW5pdGlvbiBpblNlY3Rpb24gNi40
LjENCj4gPj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1y
ZmM2MDIwYmlzLTA3I3NlY3Rpb24tNi40LjE+Og0KPiA+Pg0KPiA+PiAgICAgIG8gIElmIHRoZSAi
d2hlbiIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVudCwgdGhl
bg0KPiA+PiAgICAgICAgIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIGF1Z21lbnQncyB0YXJnZXQg
bm9kZSBpbiB0aGUgZGF0YSB0cmVlLCBpZg0KPiA+PiAgICAgICAgIHRoZSB0YXJnZXQgbm9kZSBp
cyBhIGRhdGEgbm9kZS4gIE90aGVyd2lzZSwgdGhlIGNvbnRleHQgbm9kZSBpcw0KPiA+PiAgICAg
ICAgIHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMg
YWxzbyBhIGRhdGENCj4gPj4gICAgICAgICBub2RlLiBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0
aGUgY29udGV4dCBub2RlIGlzIHRoZSByb290IG5vZGUuDQo+ID4+DQo+ID4+ICAgICAgbyAgSWYg
dGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBvZiBhICJ1c2VzIiwgImNob2ljZSIsIG9y
DQo+ID4+ICAgICAgICAgImNhc2UiIHN0YXRlbWVudCwgdGhlbiB0aGUgY29udGV4dCBub2RlIGlz
IHRoZSBjbG9zZXN0IGFuY2VzdG9yDQo+ID4+ICAgICAgICAgbm9kZSB0byB0aGUgInVzZXMiLCAi
Y2hvaWNlIiwgb3IgImNhc2UiIG5vZGUgdGhhdCBpcyBhbHNvIGEgZGF0YQ0KPiA+PiAgICAgICAg
IG5vZGUuICBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBy
b290IG5vZGUuDQo+ID4+DQo+ID4+ICAgICAgbyAgSWYgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMg
YSBjaGlsZCBvZiBhbnkgb3RoZXIgZGF0YSBkZWZpbml0aW9uDQo+ID4+ICAgICAgICAgc3RhdGVt
ZW50LCB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBub2RlIGluIHRoZSBhY2Nlc3NpYmxlIHRyZWUg
Zm9yDQo+ID4+ICAgICAgICAgd2hpY2ggdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgZGVmaW5lZC4N
Cj4gPj4gICAgICAgICAgIEFuIFhQYXRoIGV4cHJlc3Npb24gTVVTVCBOT1QgcmVmZXJlbmNlIG5v
ZGVzIHRoYXQgYXJlIG1hZGUNCj4gPj4gICAgICAgICAgIGNvbmRpdGlvbmFsDQo+ID4+ICAgICAg
YnkgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgdGhhdCBkZWZpbmVzIGl0Lg0KPiA+IFllcywgcGx1cyB0
aGUgb3RoZXIgdHdvIHJ1bGVzIHRoYXQgYXJlIGFscmVhZHkgaW4gNjAyMGJpczoNCj4gPg0KPiA+
IElmIHRoZSBYUGF0aCBleHByZXNzaW9uIHJlZmVyZW5jZXMgYW55IG5vZGUgdGhhdCBhbHNvIGhh
cyBhc3NvY2lhdGVkDQo+ID4gIndoZW4iIHN0YXRlbWVudHMsIHRoZXNlICJ3aGVuIiBleHByZXNz
aW9ucyBNVVNUIGJlIGV2YWx1YXRlZCBmaXJzdC4NCj4gPg0KPiA+IFRoZXJlIE1VU1QgTk9UIGJl
IGFueSBjaXJjdWxhciBkZXBlbmRlbmNpZXMgaW4gdGhlc2UgIndoZW4iDQo+ID4gZXhwcmVzc2lv
bnMuDQo+ID4+IEkgZG9uJ3Qgc2VlIGEgY2FzZSBpbiB3aGljaCB0aGUgY29udGV4dCBub2RlIGlz
IG5vbi1leGlzdGVudCAoaW4gdGhlDQo+ID4+IHNjaGVtYSB0cmVlKSBpbiBhbnkgb2YgdGhlIHRo
cmVlIGJ1bGxldHMsIGV2ZW4gd2l0aG91dCAibm8gdmFsdWUsIG5vDQo+ID4+IGRlc2NlbmRhbnRz
IiBkdW1teSBub2RlLg0KPiA+IFRoZSB0aGlyZCBidWxsZXQgaXMgYWltZWQgYXQgY2FzZXMgbGlr
ZSB0aGlzOg0KPiA+DQo+ID4gbGVhZiBmb28gew0KPiA+ICAgICAgd2hlbiAiLi4vYmFyID4gMCI7
DQo+ID4gICAgICBtYW5kYXRvcnkgdHJ1ZTsNCj4gPiAgICAgIC4uLg0KPiA+IH0NCj4gPg0KPiA+
IElmIHRoZXJlIGlzIG5vIGluc3RhbmNlIG9mICJmb28iLCBhIHZhbGlkYXRvciBoYXMgdG8gZmlu
ZCBvdXQgd2hldGhlcg0KPiA+IHRoZSAibWFuZGF0b3J5IiBzdGF0ZW1lbnQgYXBwbGllcyAoYW5k
IHRoZSBhYnNlbmNlIG9mICJmb28iIGlzIHRodXMgYQ0KPiA+IHNjaGVtYSBlcnJvciksIG9yIHdo
ZXRoZXIgaXQgaXMgb3ZlcnJ1bGVkIGJ5IHRoZSAid2hlbiIgZXhwcmVzc2lvbg0KPiA+IGJlaW5n
DQo+ID4gZmFsc2UuIEJ1dCBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGV2YWx1YXRlIHRoYXQgZXhw
cmVzc2lvbiwgWFBhdGgNCj4gPiByZXF1aXJlcyBhIGNvbnRleHQgbm9kZSBpbiB0aGUgaW5zdGFu
Y2UgZG9jdW1lbnQsIHNvIHdlIG5lZWQgdG8NCj4gPiB0ZW50YXRpdmVseSBhZGQgb25lLg0KPiAN
Cj4gVGhlbiB0aGUgZHVtbXkgbm9kZSB0ZXh0IGlzIGJyb2tlbiBhbGwgdG9nZXRoZXIuIEl0IGlu
c3RydWN0cyB0bw0KPiBtb2RpZnkgdGhlIGFjY2Vzc2libGUgdHJlZSAoc2NoZW1hKQ0KDQpUaGUg
YWNjZXNzaWJsZSB0cmVlIGlzIG5vdCB0aGUgc2NoZW1hLCBpdCBpcyB0aGUgaW5zdGFuY2UgZGF0
YS4NCg0KPiBpbnN0ZWFkIG9mIGluc3RydWN0aW5nIHRvDQo+IGluc3RhbnRpYXRlIGEgZHVtbXkg
aWYgYW4gaW5zdGFuY2Ugb2YgdGhlIGNvbnRleHQgbm9kZSBkb2VzIG5vdA0KPiBleGlzdC4NCg0K
Tm8sIHRoZSB0ZXh0IHNheXMgKnJlcGxhY2UqIGFueSBpbnN0YW5jZXMgd2l0aCB0aGUgZHVtbXkg
aW5zdGFuY2U7DQp0aGlzIGVuc3VyZXMgdGhhdCB0aGUgcmVzdWx0IGlzIHRoZSBzYW1lIHJlZ2Fy
ZGxlc3Mgb2YgaWYgdGhlIG5vZGUNCmV4aXN0cyBvciBub3QuDQoNCj4gQSBjb250ZXh0IG5vZGUg
YWx3YXlzIGV4aXN0cyBpbiB0aGUgc2NoZW1hIHRyZWUuDQoNClRoZSBjb250ZXh0IG5vZGUgaXMg
aW4gdGhlIGRhdGEgdHJlZS4NCg0KPiBJTU8sIHRoaXMNCj4gbmVlZHMgdG8gYmUgZml4ZWQgaW4g
b3JkZXIgdG8gcHJldmVudCB0aGUgaW50ZXJwcmV0YXRpb24gSSBjYW1lIHVwDQo+IHdpdGggKGFu
ZCBhbHNvIEJhbGF6cywgaW5kZXBlbmRlbnRseSkuIFRoaXMgaW50ZXJwcmV0YXRpb24gd2FzIGNs
ZWFybHkNCj4gbm90IHRoZSBpbnRlbnRpb24uDQo+IA0KPiBORVc6DQo+IA0KPiAgICBUaGUgWFBh
dGggZXhwcmVzc2lvbiBpcyBjb25jZXB0dWFsbHkgZXZhbHVhdGVkIGluIHRoZSBmb2xsb3dpbmcN
Cj4gICAgY29udGV4dCwgaW4gYWRkaXRpb24gdG8gdGhlIGRlZmluaXRpb24gaW5TZWN0aW9uIDYu
NC4xDQo+ICAgIDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qt
cmZjNjAyMGJpcy0wNyNzZWN0aW9uLTYuNC4xPjoNCj4gDQo+ICAgIG8gIElmIHRoZSAid2hlbiIg
c3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVudCwgdGhlbg0KPiAg
ICAgICB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhl
IGRhdGEgdHJlZSwgaWYNCj4gICAgICAgdGhlIHRhcmdldCBub2RlIGlzIGEgZGF0YSBub2RlLiAg
T3RoZXJ3aXNlLCB0aGUgY29udGV4dCBub2RlIGlzDQo+ICAgICAgIHRoZSBjbG9zZXN0IGFuY2Vz
dG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gICAgICAg
bm9kZS4gSWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgcm9v
dCBub2RlLg0KPiANCj4gICAgbyAgSWYgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBv
ZiBhICJ1c2VzIiwgImNob2ljZSIsIG9yDQo+ICAgICAgICJjYXNlIiBzdGF0ZW1lbnQsIHRoZW4g
dGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgY2xvc2VzdCBhbmNlc3Rvcg0KPiAgICAgICBub2RlIHRv
IHRoZSAidXNlcyIsICJjaG9pY2UiLCBvciAiY2FzZSIgbm9kZSB0aGF0IGlzIGFsc28gYSBkYXRh
DQo+ICAgICAgIG5vZGUuICBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBub2Rl
IGlzIHRoZSByb290IG5vZGUuDQo+IA0KPiAgICBvICBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBp
cyBhIGNoaWxkIG9mIGFueSBvdGhlciBkYXRhIGRlZmluaXRpb24NCj4gICAgICAgc3RhdGVtZW50
LCB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBub2RlIGluIHRoZSBhY2Nlc3NpYmxlIHRyZWUgZm9y
DQo+ICAgICAgIHdoaWNoIHRoZSAid2hlbiIgc3RhdGVtZW50IGlzIGRlZmluZWQuDQo+ICAgICAg
ICAgICBJZiBhbiBpbnN0YW5jZSBvZiB0aGUgY29udGV4dCBub2RlIGRvZXMgbm90IGV4aXN0IGR1
cmluZyBwcm9jZXNzaW5nDQo+ICAgIG9mIHRoZSBYUGF0aCBleHByZXNzaW9uLCB0aGUgY29udGV4
dCBub2RlIGlzIHRlbnRhdGl2ZWx5IGluc3RhbnRpYXRlZA0KPiAgICBhcyBhIHNpbmdsZSBkdW1t
eSBub2RlIHdpdGggdGhlIHNhbWUgbmFtZSwgYnV0IHdpdGggbm8gdmFsdWUgYW5kIG5vDQo+ICAg
IGNoaWxkcmVuLCBhbmQgbWVyZ2VkIGludG8gdGhlIGluc3RhbmNlIG9mIHRoZSBhY2Nlc3NpYmxl
IHRyZWUuDQo+IA0KPiAgICBUaGUgcmVzdWx0IG9mIHRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGNv
bnZlcnRlZCB0byBhIGJvb2xlYW4gdmFsdWUNCj4gICAgdXNpbmcgdGhlIHN0YW5kYXJkIFhQYXRo
IHJ1bGVzLg0KPiANCj4gICAgQW4gWFBhdGggZXhwcmVzc2lvbiBNVVNUIE5PVCByZWZlcmVuY2Ug
bm9kZXMgdGhhdCBhcmUgbWFkZSBjb25kaXRpb25hbA0KPiAgICBieSB0aGUgIndoZW4iIHN0YXRl
bWVudCB0aGF0IGRlZmluZXMgaXQuDQo+IA0KPiAgICBJZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBy
ZWZlcmVuY2VzIGFueSBub2RlIHRoYXQgYWxzbyBoYXMgYXNzb2NpYXRlZA0KPiAgICAid2hlbiIg
c3RhdGVtZW50cywgdGhlc2UgIndoZW4iIGV4cHJlc3Npb25zIE1VU1QgYmUgZXZhbHVhdGVkIGZp
cnN0Lg0KPiANCj4gICAgVGhlcmUgTVVTVCBOT1QgYmUgYW55IGNpcmN1bGFyIGRlcGVuZGVuY2ll
cyBpbiB0aGVzZSAid2hlbiINCj4gICAgZXhwcmVzc2lvbnMuDQo+IA0KPiBTb21ldGhpbmcgbGlr
ZSB0aGlzIGFsc28gdGFrZXMgY2FyZSBvZiBNYXJ0aW4ncyBleGFtcGxlICgiKiA9IDQyIikuDQoN
Ckhvdz8gIEl0IGlzIG5vdCBjbGVhciB0byBtZSBpZiB0aGUgJyonIGlzIGxlZ2FsIG9yIG5vdC4N
Cg0KDQovbWFydGluDQo=


From nobody Fri Sep 25 08:00:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236861A1EF9 for ; Fri, 25 Sep 2015 08:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReKnDM0rAoz7 for ; Fri, 25 Sep 2015 08:00:40 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4B11F1A1BF8 for ; Fri, 25 Sep 2015 08:00:40 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id E27DDC4175C1; Fri, 25 Sep 2015 17:00:38 +0200 (CEST)
To: Martin Bjorklund 
References: <56052F11.3010903@mg-soft.si>  <560548F4.8080505@mg-soft.si> <20150925.152224.1416615960207331298.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <56056192.7010301@mg-soft.si>
Date: Fri, 25 Sep 2015 17:00:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150925.152224.1416615960207331298.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 15:00:44 -0000

Martin Bjorklund je 25.9.2015 ob 15:22 napisal:
> Jernej Tuljak  wrote:
>> Ladislav Lhotka je 25.9.2015 ob 13:44 napisal:
>>> Jernej Tuljak  writes:
>>>
>>>> Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
>>>>> Jernej Tuljak  writes:
>>>>>
>>>>>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>>>>>>> Jernej Tuljak  wrote:
>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>>>>>>> Jernej Tuljak  writes:
>>>>>>>>>
>>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation
>>>>>>>>>>>>>> case
>>>>>>>>>>>>>> does not consider that an "augment" may specify a top-level
>>>>>>>>>>>>>> "choice"
>>>>>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the
>>>>>>>>>>>>>> target
>>>>>>>>>>>>>> node. There will be no initial context node for the expression in
>>>>>>>>>>>>>> such
>>>>>>>>>>>>>> a case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        leaf enable-foos {
>>>>>>>>>>>>>>          type boolean;
>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>        choice ch1 {
>>>>>>>>>>>>>>          case foo {
>>>>>>>>>>>>>>            choice foos {
>>>>>>>>>>>>>>              when "enable-foos = 'true'";
>>>>>>>>>>>>>>              leaf foo1 {
>>>>>>>>>>>>>>                type string;
>>>>>>>>>>>>>>              }
>>>>>>>>>>>>>>              leaf foo2 {
>>>>>>>>>>>>>>                type string;
>>>>>>>>>>>>>>              }
>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>          container meh;
>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        augment "/ch1/foo/foos" {
>>>>>>>>>>>>>>          when "enable-foos = 'true'";
>>>>>>>>>>>>>>          leaf foo3 {
>>>>>>>>>>>>>>            type string;
>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OLD:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         o If the "when" statement is a child of an "augment"
>>>>>>>>>>>>>>         statement,
>>>>>>>>>>>>>>         then
>>>>>>>>>>>>>>            the context node is the augment's target node in the
>>>>>>>>>>>>>>            data tree,
>>>>>>>>>>>>>>            if
>>>>>>>>>>>>>>            the target node is a data node.  Otherwise, the context
>>>>>>>>>>>>>>            node is
>>>>>>>>>>>>>>            the closest ancestor node to the target node that is
>>>>>>>>>>>>>>            also a data
>>>>>>>>>>>>>>            node.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NEW:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         o If the "when" statement is a child of an "augment"
>>>>>>>>>>>>>>         statement,
>>>>>>>>>>>>>>         then
>>>>>>>>>>>>>>            the context node is the augment's target node in the
>>>>>>>>>>>>>>            data tree,
>>>>>>>>>>>>>>            if
>>>>>>>>>>>>>>            the target node is a data node.  Otherwise, the context
>>>>>>>>>>>>>>            node is
>>>>>>>>>>>>>>            the closest ancestor node to the target node that is
>>>>>>>>>>>>>>            also a data
>>>>>>>>>>>>>>            node. If no such node exists, the context node is the
>>>>>>>>>>>>>>            root node.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Good catch, I support this change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when
>>>>>>>>>>>>> expression
>>>>>>>>>>>>> must not reference nodes that are made conditional through that
>>>>>>>>>>>>> when
>>>>>>>>>>>>> statement. I can’t find this rule in the text.
>>>>>>>>>>>> The "no referencing the initial context node and its descendants"
>>>>>>>>>>>> text
>>>>>>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>>>>>>> seriously broken and could lead to deadlocks.
>>>>>>>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>>>>>>>> node
>>>>>>>>>> with no value and child nodes has been introduced.
>>>>>>>>> Not really, the dummy node solves the problem of a non-existent
>>>>>>>>> context
>>>>>>>>> node.
>>>>>>>> Are you referring to "existence" in the instance document or the
>>>>>>>> schema tree? Why is there no need for "no children, no value dummy" in
>>>>>>>> 1st and 2nd bullet?
>>>>>>> In these cases, the context node is well-defined anyway.  But I think
>>>>>>> that also these bullets need to have text that make sure that the
>>>>>>> outcome is deterministic in all cases, such as:
>>>>>>>
>>>>>>>       augement /foo {
>>>>>>>         when "bar > 1";
>>>>>>>         leaf bar { type int32; }
>>>>>>>       }
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>>       grouping foo {
>>>>>>>         leaf bar { type int32; }
>>>>>>>       }
>>>>>>>       container x {
>>>>>>>         uses foo {
>>>>>>>           when "bar > 1";
>>>>>>>         }
>>>>>>>       }
>>>>>>>
>>>>>>>
>>>>>>> etc.
>>>>>>>
>>>>>>> So I suggest this NEW text:
>>>>>>>
>>>>>>>
>>>>>>>        o If the "when" statement is a child of an "augment" statement,
>>>>>>>        then
>>>>>>>           the context node is the augment's target node in the data tree,
>>>>>>>           if
>>>>>>>           the target node is a data node.  Otherwise, the context node is
>>>>>>>           the closest ancestor node to the target node that is also a
>>>>>>>           data
>>>>>>>           node.  If no such node exists, the context node is the root
>>>>>>>           node.
>>>>>>>           The accessible tree is tentatively altered during the
>>>>>>>           processing
>>>>>>>           of the XPath expression by removing all instances (if any) of
>>>>>>>           the
>>>>>>>           nodes added by the "augment" statement.
>>>>>>>
>>>>>>>        o  If the "when" statement is a child of a "uses", "choice", or
>>>>>>>           "case" statement, then the context node is the closest ancestor
>>>>>>>           node to the "uses", "choice", or "case" node that is also a
>>>>>>>           data
>>>>>>>           node.  If no such node exists, the context node is the root
>>>>>>>           node.
>>>>>>>           The accessible tree is tentatively altered during the
>>>>>>>           processing
>>>>>>>           of the XPath expression by removing all instances (if any) of
>>>>>>>           the
>>>>>>>           nodes added by the "uses", "choice", or "case" statement.
>>>>>>>
>>>>>>>        o  If the "when" statement is a child of any other data definition
>>>>>>>           statement, the accessible tree is tentatively altered during
>>>>>>>           the
>>>>>>>           processing of the XPath expression by replacing all instances
>>>>>>>           (if
>>>>>>>           any) of the data node for which the "when" statement is defined
>>>>>>>           with a single dummy node with the same name, but with no value
>>>>>>>           and
>>>>>>>           no children.  The context node is this dummy node.
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>>       container foo {
>>>>>>         when "child::* or child::text() or not(self::*)"; // always false
>>>>>>         leaf bar {
>>>>>>           type string;
>>>>>>         }
>>>>>>       }
>>>>> I think it would be better to clearly state that a "when" expression
>>>>> MUST NOT refer to nodes that are made conditional by the same "when"
>>>>> statement - it's similar to the rule that forbids mutual references.
>>>>> This would also cover all uses of "when".
>>>>>
>>>>> The above example would be really confusing if the "bar" instance is
>>>>> present.
>>>> It is true that this introduces a caveat that is bound to confuse end
>>>> YANG users.
>>>>
>>>>>     I also don't like the fact that "when" and "must" would give
>>>>> different results in this case.
>>>> Just to be clear, you would like this, right?
>>>>
>>>> NEW:
>>>>
>>>>       The XPath expression is conceptually evaluated in the following
>>>>       context, in addition to the definition inSection 6.4.1
>>>> :
>>>>
>>>>       o  If the "when" statement is a child of an "augment" statement, then
>>>>          the context node is the augment's target node in the data tree, if
>>>>          the target node is a data node.  Otherwise, the context node is
>>>>          the closest ancestor node to the target node that is also a data
>>>>          node. If no such node exists, the context node is the root node.
>>>>
>>>>       o  If the "when" statement is a child of a "uses", "choice", or
>>>>          "case" statement, then the context node is the closest ancestor
>>>>          node to the "uses", "choice", or "case" node that is also a data
>>>>          node.  If no such node exists, the context node is the root node.
>>>>
>>>>       o  If the "when" statement is a child of any other data definition
>>>>          statement, the context node is the node in the accessible tree for
>>>>          which the "when" statement is defined.
>>>>            An XPath expression MUST NOT reference nodes that are made
>>>>            conditional
>>>>       by the "when" statement that defines it.
>>> Yes, plus the other two rules that are already in 6020bis:
>>>
>>> If the XPath expression references any node that also has associated
>>> "when" statements, these "when" expressions MUST be evaluated first.
>>>
>>> There MUST NOT be any circular dependencies in these "when"
>>> expressions.
>>>> I don't see a case in which the context node is non-existent (in the
>>>> schema tree) in any of the three bullets, even without "no value, no
>>>> descendants" dummy node.
>>> The third bullet is aimed at cases like this:
>>>
>>> leaf foo {
>>>       when "../bar > 0";
>>>       mandatory true;
>>>       ...
>>> }
>>>
>>> If there is no instance of "foo", a validator has to find out whether
>>> the "mandatory" statement applies (and the absence of "foo" is thus a
>>> schema error), or whether it is overruled by the "when" expression
>>> being
>>> false. But in order to be able to evaluate that expression, XPath
>>> requires a context node in the instance document, so we need to
>>> tentatively add one.
>> Then the dummy node text is broken all together. It instructs to
>> modify the accessible tree (schema)
> The accessible tree is not the schema, it is the instance data.
>
>> instead of instructing to
>> instantiate a dummy if an instance of the context node does not
>> exist.
> No, the text says *replace* any instances with the dummy instance;
> this ensures that the result is the same regardless of if the node
> exists or not.

Okay, the accessible tree is instantiated data nodes.

container top {
     leaf foo {
         when "../bar > 0";
         mandatory true;
         ...
     }
}

"top": {}

"top": { "foo": "" }

How is a context node ensured for the two instances, if replacing 
something that may not exist? You would need to create a dummy if there 
is no "foo" instance, right? The text only says "replace".

>> A context node always exists in the schema tree.
> The context node is in the data tree.
>
>> IMO, this
>> needs to be fixed in order to prevent the interpretation I came up
>> with (and also Balazs, independently). This interpretation was clearly
>> not the intention.
>>
>> NEW:
>>
>>     The XPath expression is conceptually evaluated in the following
>>     context, in addition to the definition inSection 6.4.1
>>     :
>>
>>     o  If the "when" statement is a child of an "augment" statement, then
>>        the context node is the augment's target node in the data tree, if
>>        the target node is a data node.  Otherwise, the context node is
>>        the closest ancestor node to the target node that is also a data
>>        node. If no such node exists, the context node is the root node.
>>
>>     o  If the "when" statement is a child of a "uses", "choice", or
>>        "case" statement, then the context node is the closest ancestor
>>        node to the "uses", "choice", or "case" node that is also a data
>>        node.  If no such node exists, the context node is the root node.
>>
>>     o  If the "when" statement is a child of any other data definition
>>        statement, the context node is the node in the accessible tree for
>>        which the "when" statement is defined.
>>            If an instance of the context node does not exist during processing
>>     of the XPath expression, the context node is tentatively instantiated
>>     as a single dummy node with the same name, but with no value and no
>>     children, and merged into the instance of the accessible tree.
>>
>>     The result of the XPath expression is converted to a boolean value
>>     using the standard XPath rules.
>>
>>     An XPath expression MUST NOT reference nodes that are made conditional
>>     by the "when" statement that defines it.
>>
>>     If the XPath expression references any node that also has associated
>>     "when" statements, these "when" expressions MUST be evaluated first.
>>
>>     There MUST NOT be any circular dependencies in these "when"
>>     expressions.
>>
>> Something like this also takes care of Martin's example ("* = 42").
> How?  It is not clear to me if the '*' is legal or not.

It just occurred to me that it is very hard to not reference the context 
node in a "when" XPath expression, since the context node is always your 
initial XPath context (you always start with a node-set of size 1, 
containing the context node).

"../bar" says, select the parent of the context node, then select "bar" 
child
"*" says, select the children of the context node that are also element 
nodes

So, yeah, "MUST NOT reference conditional nodes" doesn't work.

Jernej

>
> /martin


From nobody Fri Sep 25 09:35:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F111ACDE3 for ; Fri, 25 Sep 2015 09:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYHqDz1AMawu for ; Fri, 25 Sep 2015 09:35:05 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B011ACDD9 for ; Fri, 25 Sep 2015 09:35:05 -0700 (PDT)
Received: from BL2PR05MB065.namprd05.prod.outlook.com (10.255.232.16) by BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 25 Sep 2015 16:35:03 +0000
Received: from BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.117]) by BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.117]) with mapi id 15.01.0274.009; Fri, 25 Sep 2015 16:35:03 +0000
From: "Lisa (Yi) Huang" 
To: "Sterne, Jason (Jason)" , "netmod@ietf.org" 
Thread-Topic: [netmod] ACL Model 03 - ACL Type should be mandatory
Thread-Index: AQHQ9yE2yvAvmExmc0av6Oc3Yl9U6g==
Date: Fri, 25 Sep 2015 16:35:03 +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=lyihuang@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.10]
x-microsoft-exchange-diagnostics: 1; BL2PR05MB068; 5:8745I77X3DwpcTJ6LRRfnd+9UrhGK9Vy9EzEkuQujw6FDF7ep3DwmLl0OOhDErJ5WpTImD+2BB2UHXhQD8TlXUzRcxXWCpFYQGS/NPgmKCCF03xVJqv0/2yyXN9WEUNRTnEq61421Makh5jCEq+7cQ==; 24:qmiqPn+gwA/rZDKGSD9f+FuiwbwaZyocT7jSfkuii9HUvcrMtThN9tT48YkUHGcxWgFQOFAO1CBMm7fKp25a8uawLsr4PaiHfoNWCW9yKXE=; 20:GZmsNSzXOUbQeXKC469zeD5HAyE1F9CM/+iEVSTBvI8G4zEQ9+oP2cJnZdr5hdfXPyC8qRoSKMvl8dxq3S+VxA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB068;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BL2PR05MB068; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB068; 
x-forefront-prvs: 07106EF9B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(189002)(479174004)(164054003)(377454003)(24454002)(199003)(13464003)(54356999)(99286002)(66066001)(106356001)(46102003)(106116001)(105586002)(2501003)(87936001)(64706001)(561944003)(101416001)(11100500001)(15975445007)(19580405001)(97736004)(77156002)(62966003)(92566002)(2900100001)(68736005)(40100003)(19580395003)(102836002)(5001860100001)(4001540100001)(50986999)(5001830100001)(81156007)(5001770100001)(122556002)(10400500002)(36756003)(5004730100002)(189998001)(86362001)(5007970100001)(5001920100001)(107886002)(5001960100002)(5002640100001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB068; H:BL2PR05MB065.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="euc-kr"
Content-ID: <9B5793B15CA94A4DA577D78F4F726212@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2015 16:35:03.7960 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB068
Archived-At: 
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Sep 2015 16:35:11 -0000

SmFzb24sDQoNCldlIGludmVzdGlnYXRlIHlvdXIgcHJvcG9zYWwgYW5kIHdpbGwgYWRkIGFjbC10
eXBlIGFzIGtleSB0byBhY2wgbGlzdCBpbg0Kb3VyIG5leHQgdmVyc2lvbiBvZiBkcmFmdC4NCmFj
bCBpbiB0aGUgZHJhZnQuDQoNCmxpc3QgYWNsIHsNCiAga2V5ICJhY2wtdHlwZSBhY2wtbmFtZSI7
DQogIC4uLg0KDQpMZWFmIGFjbC1uYW1lIHuhpn0NCmxlYWYgYWNsLXR5cGUgey4uLn0NCi4uLg0K
fQ0KDQoNClRoYW5rcywNCg0KTGlzYQ0KDQoNCk9uIDkvMjAvMTUsIDE6MjMgUE0sICJuZXRtb2Qg
b24gYmVoYWxmIG9mIFN0ZXJuZSwgSmFzb24gKEphc29uKSINCjxuZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZyBvbiBiZWhhbGYgb2YgamFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbT4NCndyb3Rl
Og0KDQo+SGkgYWxsLA0KPg0KPkkgbWV0IHdpdGggRGVhbiBhdCBJRVRGOTMgYW5kIHdlIGFncmVl
ZCB0aGF0IEkgc2hvdWxkIHNlbmQgYSBzcGVjaWZpYw0KPnByb3Bvc2FsIHRvIHRoZSBsaXN0IGZv
ciB0aGlzLiAgSGVyZSBpdCBpczoNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlJlcGxhY2UgdGhlIGZvbGxvd2luZyBjdXJyZW50IHNu
aXBwZXRzIGZyb20gbW9kZWwtMDM6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5saXN0IGFjbCB7DQo+ICBrZXkgImFjbC1uYW1lIjsN
Cj4gIC4uLg0KPn0NCj4NCj5sZWFmIGFjbC10eXBlIHsNCj4gIHR5cGUgYWNsLXR5cGU7DQo+ICBk
ZXNjcmlwdGlvbg0KPiAgICAiSXQgaXMgcmVjb21tZW5kZWQgdG8gaGF2ZSBhbiBBY2Nlc3MgQ29u
dHJvbCBMaXN0IHdpdGgNCj4gICAgIHVuaWZvcm0gYWNjZXNzIGxpc3QgZW50cmllcywgYWxsIG9m
IHRoZSBzYW1lIHR5cGUuIFdoZW4NCj4gICAgIHRoaXMgdHlwZSBpcyBub3QgZXhwbGljaXRseSBz
cGVjaWZpZWQsIGlmIHZlbmRvcg0KPiAgICAgaW1wbGVtZW50YXRpb24gcGVybWl0cywgdGhlIGFj
Y2VzcyBjb250cm9sIGVudHJpZXMNCj4gICAgIGluIHRoZSBsaXN0IGNhbiBiZSBtaXhlZCwNCj4g
ICAgIGJ5IGNvbnRhaW5pbmcgTDIsIEwzIGFuZCBMNCBlbnRyaWVzIjsNCj59DQo+DQo+aWRlbnRp
dHkgaXAtYWNsIHsNCj4gIGJhc2UgYWNsOmFjbC1iYXNlOw0KPiAgZGVzY3JpcHRpb24NCj4gICAg
IklQIEFjY2VzcyBDb250cm9sIExpc3QgaXMgYSBjb21tb24gbmFtZSBmb3IgbGlzdHMgdGhhdCBj
b250YWluDQo+ICAgICBsYXllciAzIGFuZC9vciBsYXllciA0IG1hdGNoIGNvbmRpdGlvbnMuIjsN
Cj59DQo+DQo+aWRlbnRpdHkgZXRoLWFjbCB7DQo+ICBiYXNlIGFjbDphY2wtYmFzZTsNCj4gIGRl
c2NyaXB0aW9uDQo+ICAgICJFdGhlcm5ldCBBY2Nlc3MgQ29udHJvbCBMaXN0IGlzIG5hbWUgZm9y
IGxheWVyIDIgRXRoZXJuZXQNCj4gICAgIHRlY2hub2xvZ3kgQWNjZXNzIENvbnRyb2wgTGlzdCB0
eXBlcywgbGlrZSAxMC8xMDAvMTAwMGJhc2VUIG9yDQo+ICAgICBXaUZpIEFjY2VzcyBDb250cm9s
IExpc3QiOw0KPn0NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPndpdGggdGhlIGZvbGxvd2lu
ZzoNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPmxpc3QgYWNsIHsNCj4gIGtleSAiYWNsLXR5
cGUgYWNsLW5hbWUiOw0KPiAgLi4uDQo+fQ0KPihub3RlIHRoaXMgaXMgc2ltaWxhciBjb25zdHJ1
Y3QgdG8gdGhlIHJvdXRpbmcgbW9kZWw6DQo+ICAgbGlzdCByb3V0aW5nLXByb3RvY29sIHtrZXkg
InR5cGUgbmFtZSIuLi4gKQ0KPg0KPmxlYWYgYWNsLXR5cGUgew0KPiAgdHlwZSBhY2wtdHlwZTsN
Cj4gIGRlc2NyaXB0aW9uDQo+ICAgICJUeXBlIG9mIGFjY2VzcyBjb250cm9sIGxpc3QuIEluZGlj
YXRlcyB0aGUgcHJpbWFyeSBpbnRlbmRlZA0KPiAgICAgdHlwZSBvZiBtYXRjaCBjcml0ZXJpYSAo
ZS5nLiBldGhlcm5ldCwgSVB2NCwgSVB2NiwgbWl4ZWQsIGV0YykNCj4gICAgIHVzZWQgaW4gdGhl
IGxpc3QgaW5zdGFuY2UuIjsNCj59DQo+DQo+aWRlbnRpdHkgaXB2NC1hY2wgew0KPiAgYmFzZSBh
Y2w6YWNsLWJhc2U7DQo+ICBkZXNjcmlwdGlvbiANCj4gICAgIkFDTCB0aGF0IHByaW1hcmlseSBt
YXRjaGVzIG9uIGZpZWxkcyBmcm9tIHRoZSBJUHY0IGhlYWRlcg0KPiAgICAoZS5nLiBJUHY0IGRl
c3RpbmF0aW9uIGFkZHJlc3MpIGFuZCBsYXllciA0IGhlYWRlcnMgKGUuZy4gVENQDQo+ZGVzdGlu
YXRpb24NCj4gICAgcG9ydCkuICBBbiBhY2wgb2YgdHlwZSBpcHY0LWFjbCBkb2VzIG5vdCBjb250
YWluIG1hdGNoZXMgb24gZmllbGRzIGluDQo+ICAgIHRoZSBldGhlcm5ldCBoZWFkZXIgb3IgdGhl
IElQdjYgaGVhZGVyLiI7DQo+fQ0KPg0KPmlkZW50aXR5IGlwdjYtYWNsIHsNCj4gIGJhc2UgYWNs
OmFjbC1iYXNlOw0KPiAgZGVzY3JpcHRpb24NCj4gICAgIkFDTCB0aGF0IHByaW1hcmlseSBtYXRj
aGVzIG9uIGZpZWxkcyBmcm9tIHRoZSBJUHY2IGhlYWRlcg0KPiAgICAoZS5nLiBJUHY2IGRlc3Rp
bmF0aW9uIGFkZHJlc3MpIGFuZCBsYXllciA0IGhlYWRlcnMgKGUuZy4gVENQDQo+ZGVzdGluYXRp
b24NCj4gICAgcG9ydCkuIEFuIGFjbCBvZiB0eXBlIGlwdjYtYWNsIGRvZXMgbm90IGNvbnRhaW4g
bWF0Y2hlcyBvbiBmaWVsZHMgaW4NCj4gICAgdGhlIGV0aGVybmV0IGhlYWRlciBvciB0aGUgSVB2
NCBoZWFkZXIuIjsNCj59DQo+ICANCj5pZGVudGl0eSBldGgtYWNsIHsNCj4gIGJhc2UgYWNsOmFj
bC1iYXNlOw0KPiAgZGVzY3JpcHRpb24NCj4gICAgIkFDTCB0aGF0IHByaW1hcmlseSBtYXRjaGVz
IG9uIGZpZWxkcyBpbiB0aGUgZXRoZXJuZXQgaGVhZGVyLg0KPiAgICAgQW4gYWNsIG9mIHR5cGUg
ZXRoLWFjbCBkb2VzIG5vdCBjb250YWluIG1hdGNoZXMgb24gZmllbGRzIGluDQo+ICAgICB0aGUg
SVB2NCBoZWFkZXIsIElQdjYgaGVhZGVyIG9yIGxheWVyIDQgaGVhZGVycy4iOw0KPn0NCj4NCj4N
Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5Qb3RlbnRpYWwgZnV0
dXJlIGF1Z21lbnRhdGlvbiBvZiB0eXBlOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4NCj5Gb3IgZnV0dXJlIG1peGVkIHR5cGVzIHZlbmRvcnMgKG9yIHRoZSBp
ZXRmKSBjb3VsZCBhdWdtZW50IHRoZQ0KPmFjbC10eXBlLWJhc2Ugd2l0aCB0eXBlcyBsaWtlIHRo
ZSBmb2xsb3dpbmc6DQo+DQo+ICBpZGVudGl0eSBtaXhlZC1sMy1hY2wgew0KPiAgICBiYXNlICJh
Y2Nlc3MtY29udHJvbC1saXN0OmFjbC10eXBlLWJhc2UiOw0KPiAgICBkZXNjcmlwdGlvbiAiQUNM
IHRoYXQgY29udGFpbnMgYSBtaXggb2YgZW50cmllcyB0aGF0IHByaW1hcmlseSBtYXRjaA0KPm9u
IGZpZWxkcyANCj4gICAgICBpbiBJUHY0IGhlYWRlcnMgYW5kIGVudHJpZXMgdGhhdCBwcmltYXJp
bHkgbWF0Y2ggb24gZmllbGRzIGluIElQdjYNCj5oZWFkZXJzLg0KPiAgICAgIE1hdGNoaW5nIG9u
IGxheWVyIDQgaGVhZGVyIGZpZWxkcyBtYXkgYWxzbyBleGlzdCBpbiB0aGUgbGlzdC4NCj4gICAg
ICBBbiBhY2wgb2YgdHlwZSBtaXhlZC1sMy1hY2wgZG9lcyBub3QgY29udGFpbiBtYXRjaGVzIG9u
IGZpZWxkcyBpbg0KPiAgICAgIHRoZSBldGhlcm5ldCBoZWFkZXIuIjsNCj4gIH0NCj4gDQo+ICBp
ZGVudGl0eSBtaXhlZC1sMi1sMy1hY2wgew0KPiAgICBiYXNlICJhY2Nlc3MtY29udHJvbC1saXN0
OmFjbC10eXBlLWJhc2UiOw0KPiAgICBkZXNjcmlwdGlvbiAiQUNMIHRoYXQgY29udGFpbnMgYSBt
aXggb2YgZW50cmllcyB0aGF0IHByaW1hcmlseSBtYXRjaA0KPm9uIGZpZWxkcyANCj4gICAgICBp
biBldGhlcm5ldCBoZWFkZXJzLCBlbnRyaWVzIHRoYXQgcHJpbWFyaWx5IG1hdGNoIG9uIGZpZWxk
cyBpbiBJUHY0DQo+aGVhZGVycywNCj4gICAgICBhbmQgZW50cmllcyB0aGF0IHByaW1hcmlseSBt
YXRjaCBvbiBmaWVsZHMgaW4gSVB2NiBoZWFkZXJzLg0KPk1hdGNoaW5nIG9uIGxheWVyIDQNCj4g
ICAgICBoZWFkZXIgZmllbGRzIG1heSBhbHNvIGV4aXN0IGluIHRoZSBsaXN0LiI7DQo+ICB9DQo+
DQo+UmVnYXJkcywNCj5KYXNvbg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv
bTogU3Rlcm5lLCBKYXNvbiAoSmFzb24pDQo+U2VudDogU3VuZGF5LCBKdWx5IDE5LCAyMDE1IDEy
OjU4DQo+VG86IFN0ZXJuZSwgSmFzb24gKEphc29uKTsgbmV0bW9kQGlldGYub3JnDQo+U3ViamVj
dDogUkU6IEFDTCBNb2RlbCAwMyAtIEFDTCBUeXBlIHNob3VsZCBiZSBtYW5kYXRvcnkNCj4NCj5H
aXZlbiB0aGUgZGF0YSBtb2RlbHMgYmVsb3cgaW4gc29tZSBvZiB0aGUgbWFqb3IgaW1wbGVtZW50
YXRpb25zIGl0IGFsc28NCj5zZWVtcyBsaWtlIHdlIHNob3VsZCBhbHNvIChyZS0pY29uc2lkZXIg
aGF2aW5nIHRoZSAndHlwZScgYXMgcGFydCBvZiB0aGUNCj5BQ0wga2V5ICgidHlwZSBuYW1lIiku
DQo+DQo+SW4gYWxsIHRob3NlIGNhc2VzIGJlbG93IGl0IGxvb2tzIGxpa2UgYW4gb3BlcmF0b3Ig
Y2FuIGN1cnJlbnRseQ0KPmNvbmZpZ3VyZSB0d28gZGlmZmVyZW50IEFDTHMgKGUuZy4gYW4gSVB2
NCBhbmQgYW4gSVB2NiBBQ0wpIHdpdGggdGhlIHNhbWUNCj5uYW1lL2lkIHZpYSB0aGVpciBDTEkg
KGUuZy4gYSB2NCBBQ0wgY2FsbGVkICJteS1hY2wiIGFuZCBhIHY2IEFDTCBjYWxsZWQNCj4ibXkt
YWNsIikuICANCj4NCj5Ib3cgd291bGQgdGhvc2UgbGlzdHMgYmUgcmVhZCBpbiBhIDxnZXQtY29u
ZmlnPiB2aWEgdGhlIGlldGYgQUNMIFlBTkcNCj5tb2R1bGVzID8gIFdlJ2QgYWxsIGhhdmUgdG8g
bWFuZ2xlIHRoZSBuYW1lcyBhbmQgcmVzZXJ2ZSBzcGVjaWFsDQo+bmFtZXMvcHJlZml4LWNoYXJz
IChlLmcuIF9pcHY0LW15LWFjbCBhbmQgX2lwdjYtbXktYWNsKSB0byBzZW5kIHRoZW0gYmFjaw0K
PnRvIGEgTkMgY2xpZW50LiAgSSdtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIG11Y2ggb2YgYSBkaXNh
ZHZhbnRhZ2Ugb2YganVzdA0KPmhhdmluZyB0eXBlIGluIHRoZSBrZXkgKGFzc3VtaW5nIGl0IGlz
IG1hbmRhdG9yeSBhcyBhZHZvY2F0ZWQgYmVsb3cpLg0KPg0KPkkgYWxzbyBsb29rZWQgYnJpZWZs
eSBhdCB0aGUgQnJvY2FkZSBZQU5HIG1vZGVscyBvbiBnaXRodWIuICBJdCBsb29rcw0KPmxpa2Ug
dGhleSBoYXZlIG11bHRpcGxlIGxpc3RzIGFzIHdlbGwgZm9yIHY0IHZzIHY2IChhbmQgZXZlbiBv
ciBkaWZmZXJlbnQNCj50eXBlcyBvZiBub3JtYWwgdnMgZXh0ZW5kZWQgQUNMcyAtIHRoYXQgY291
bGQgYmUgaGFuZGxlZCBieSBhdWdtZW50aW5nDQo+dGhlIHR5cGUgd2l0aCBhICd2NC1leHRlbmRl
ZCcgdHlwZSBmb3IgZXhhbXBsZSkuDQo+DQo+UmVnYXJkcywNCj5KYXNvbg0KPg0KPi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVybmUsIEphc29uDQo+KEphc29uKQ0KPlNlbnQ6IEZy
aWRheSwgSnVseSAxNywgMjAxNSAyMzozNQ0KPlRvOiBuZXRtb2RAaWV0Zi5vcmcNCj5TdWJqZWN0
OiBbbmV0bW9kXSBBQ0wgTW9kZWwgMDMgLSBBQ0wgVHlwZSBzaG91bGQgYmUgbWFuZGF0b3J5DQo+
DQo+SGkgYWxsLA0KPg0KPkkgdGhpbmsgd2UgbmVlZCB0byByZXZpc2l0IHRoaXMgZGlzY3Vzc2lv
biBhYm91dCBob3cgQUNMIHR5cGUgd29ya3MgaW4NCj5kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9k
ZWwtMDMuDQo+DQo+SXQgc2hvdWxkIGJlIG1hbmRhdG9yeSBhbmQgd2Ugc2hvdWxkIHNlcGFyYXRl
IHY0IGZyb20gdjYuICBWZW5kb3JzIGNhbg0KPmF1Z21lbnQgZm9yIGZ1dHVyZSAibWl4ZWQiIHR5
cGVzIChvciBtYXliZSB3ZSBzaG91bGQgbWFrZSBhbiBpZi1mZWF0dXJlDQo+Zm9yIGEgIm1peGVk
IiB0eXBlIG5vdyB0aGF0IG1lYW5zICJhbnl0aGluZyBnb2VzIikuDQo+DQo+V2Ugc2hvdWxkIGZv
bGxvdyBleGlzdGluZyBjb21tb24gaW1wbGVtZW50YXRpb25zIGZvciB0aGlzIGluIG9yZGVyIHRv
DQo+Zm9zdGVyIGJldHRlciBhZG9wdGlvbi4NCj4NCj5DaXNjbyBJT1MtWFIgaGFzIHNlcGFyYXRl
IGxpc3RzIGZvciBpcHY0IGFuZCBpcHY2IGFuZCBwYXJ0IG9mIHNwZWNpZnlpbmcNCj50aGUgbGlz
dDoNCj5pcHY0IGFjY2Vzcy1saXN0IDxuYW1lPg0KPmlwdjYgYWNjZXNzLWxpc3QgPG5hbWU+DQo+
IA0KPkp1bm9zIGhhcyBzZXBhcmF0ZSBsaXN0cyBmb3IgdjQgYW5kIHY2Og0KPmFjY2Vzcy1saXN0
IDx4eXo+IC4uLg0KPmlwdjYgYWNjZXNzLWxpc3QgPGFiYz4gLi4uDQo+IA0KPkFMVSBTUiBPUyBo
YXMgc2VwYXJhdGUgbGlzdHMgZm9yIHY0LCB2NiBhbmQgbWFjOg0KPmNvbmZpZyBmaWx0ZXIgaXAt
ZmlsdGVyIDxhYmM+DQo+Y29uZmlnIGZpbHRlciBpcHY2LWZpbHRlciA8ZGVmPg0KPmNvbmZpZyBm
aWx0ZXIgbWFjLWZpbHRlciA8Z2hpPg0KPiANCj5IdWF3ZWkgdXNlcyBzZXBhcmF0ZSBsaXN0cyBm
b3IgdjQgYW5kIHY2Og0KPmFjbCBudW1iZXIgMzAwMA0KPmFjbCBpcHY2IG51bWJlciAzMDAwDQo+
DQo+UGxlYXNlIHNlZSBiZWxvdyB3aXRoIFs+PkpUU10NCj4NCj5SZWdhcmRzLA0KPkphc29uDQo+
DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBuZXRtb2QgW21haWx0bzpuZXRt
b2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KPlNlbnQ6IE1v
bmRheSwgSnVuZSAwMSwgMjAxNSAxNzowMA0KPlRvOiBOYWJpbCBNaWNocmFmDQo+Q2M6IG5ldG1v
ZEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbbmV0bW9kXSBtYW5kYXRvcnkgQUNMIHR5cGUgKHdh
cyAiY29tbWVudHMgb24gYWNsLW1vZGVsLTAyIikNCj4NCj5IaSwNCj4NCj4NCj5UaGF0IGFwcGVh
cnMgdG8gYmUgdGhlIGN1cnJlbnQgdmVyc2lvbiBvbiB0aGUgZGF0YS10cmFja2VyLg0KPkkgYWdy
ZWUgd2l0aCB5b3UgdGhhdCB0aGUgYWNjZXNzLWNvbnRyb2wtbGlzdC10eXBlIGxlYWYgc2hvdWxk
IGJlDQo+bWFuZGF0b3J5Lg0KPg0KPkkgbm90aWNlZCB0aGF0IHRoZSBleGFtcGxlIGluIEZpZ3Vy
ZSAyIGhhcyBhbiBleHRyYSAndG9wJw0KPmNvbnRhaW5lciBhbmQgdGhlIG5hbWVzcGFjZSBmb3Ig
J2FjY2Vzcy1saXN0cycgaXMgbWlzc2luZy4NCj4NCj4NCj5BbmR5DQo+DQo+T24gTW9uLCBKdW4g
MSwgMjAxNSBhdCAxMTozMSBBTSwgTmFiaWwgTWljaHJhZiA8bmFiaWwubWljaHJhZkBnbWFpbC5j
b20+DQo+d3JvdGU6DQo+PiBIaSBhbGwsDQo+Pg0KPj4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSBp
ZiB3ZSBhcmUgdGFsa2luZyBhYm91dA0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt
aWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTAyLnR4dCBvciBzb21lDQo+PiBvdGhlciBkcmFmdD8NCj4+
IEkganVzdCB3YW50IHRvIG1ha2Ugc3VyZSBJIGFtIGxvb2tpbmcgYXQgdGhlIHJpZ2h0IEFDTCBt
b2RlbCB2ZXJzaW9uLg0KPj4NCj4+IFRoYW5rIHlvdSwNCj4+IE5hYmlsDQo+Pg0KPj4gT24gTW9u
LCBKdW4gMSwgMjAxNSBhdCA3OjA2IEFNLCBEYW5hIEJsYWlyIChkYmxhaXIpIDxkYmxhaXJAY2lz
Y28uY29tPg0KPj4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gNC8xMy8xNSwgMTA6MTEg
QU0sICJTdGVybmUsIEphc29uIChKYXNvbikiDQo+Pj4gPGphc29uLnN0ZXJuZUBhbGNhdGVsLWx1
Y2VudC5jb20+IHdyb3RlOg0KPj4+DQo+Pj4gPkhpIGd1eXMsDQo+Pj4gPg0KPj4+ID5FeHRyYWN0
aW5nIG15IGNvbW1lbnRzIGFib3V0IEFDTCB0eXBlIGludG8gaXRzIG93biB0aHJlYWQuICBJIHNh
dw0KPj4+ID5NYXJ0aW4gYWxzbyBoYWQgc29tZSBjb21tZW50cyBvbiB0aGlzIHRvcGljLg0KPj4+
ID4NCj4+PiA+VGhlIEFDTCB0eXBlIHdhcyBtYW5kYXRvcnkgaW4gYW4gb2xkZXIgdmVyc2lvbiBv
ZiB0aGUgZHJhZnQgYW5kIEkNCj4+PiA+dGhpbmsgd2Ugc2hvdWxkIHB1dCBpdCBiYWNrIGFzIG1h
bmRhdG9yeS4gIEltcGxlbWVudGF0aW9ucyB0aGF0DQo+Pj4gPmRvbid0ICpuZWVkKiB0aGF0IGxl
YWYgdmFsdWUgY2FuIHdvcmsgZmluZSB3aGV0aGVyIHRoZXkgZ2V0IGl0DQo+Pj4gPmR1cmluZyBB
Q0wgY3JlYXRpb24gb3Igbm90IGJ1dCBzb21lIGltcGxlbWVudGF0aW9ucyBuZWVkIHRvIGtub3cg
dGhlDQo+Pj50eXBlLg0KPj4+DQo+Pj4gV2UgZG9uqfZ0IHdhbnQgdG8gbWFrZSB0aGUgQUNMIHR5
cGUgbWFuZGF0b3J5IGJlY2F1c2UgdGhlbiB3ZSBoYXZlIHRvDQo+Pj4gYSBjcmVhdGUgYSBuZXcg
dHlwZSBmb3IgZXZlcnkgY29tYmluYXRpb24gb2YgbWF0Y2ggY3JpdGVyaWEuICBUaGUNCj4+PiBt
b2RlbCBzaG91bGQgc3VwcG9ydCBhbnkgY29tYmluYXRpb24gb2YgbWF0Y2ggY3JpdGVyaWEgd2l0
aCB0eXBpbmcNCj4+PiBvcHRpb25hbCB0byBtYXAgdG8gcHJlLWV4aXN0aW5nIGltcGxlbWVudGF0
aW9ucy4gIFRoaXMgaXMgYSB0cmFkZW9mZg0KPj4+IGJldHdlZW4gbWFraW5nIHRoZSBtb2RlbCBi
YWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcNCj4+PiBpbXBsZW1lbnRhdGlvbnMgYnV0
IG1ha2UgaXQgZmxleGlibGUgZW5vdWdoIHNvIHRoYXQgYSBuZXcgbWF0Y2gNCj4+PiBjcml0ZXJp
YSBkb2Vzbqn2dCByZXF1aXJlIGEgbmV3IHR5cGUuDQo+DQo+Wz4+SlRTXSBXZSBjYW4ganVzdCBj
cmVhdGUgYSAibWl4ZWQiIChpLmUuIHVuc3BlY2lmaWVkKSB0eXBlIGFuZCBwdXQgaXQNCj51bmRl
ciBhbiBpZi1mZWF0dXJlLiBFeGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBhIHNpbmdsZSB0
eXBlIChhbmQNCj5yZXF1aXJlIGtub3dpbmcgdGhlIHR5cGUgYXQgbGlzdCBjcmVhdGlvbiB0aW1l
KS4NCj4NCj4+Pg0KPj4+ID4NCj4+PiA+SXQgd291bGQgYWxzbyBiZSBnb29kIHRvIGNyZWF0ZSBz
ZXBhcmF0ZSBpZGVudGl0aWVzIGZvcg0KPj4+ID5JUHY0LWFjY2Vzcy1jb250cm9sLWxpc3QgYW5k
IElQdjYtYWNjZXNzLWNvbnRyb2wtbGlzdCBpbnN0ZWFkIG9mDQo+Pj4gPmJ1bmRsaW5nIHRoZW0g
aW50byBJUC1hY2Nlc3MtY29udHJvbC1saXN0LiBJZiB3ZSdyZSBzZXBhcmF0aW5nIGludG8NCj4+
PiA+dHlwZXMgaW4gdGhlIG1vZGVsIGl0IHNob3VsZCBiZSB0aGUgMyBiYXNpYyB0eXBlcyBpbiB0
aGUgYmFzZSBtb2RlbDoNCj4+PnY0LCB2NiBhbmQgZW5ldC4NCj4+Pg0KPj4+IEEgdmVuZG9yIHNw
ZWNpZmljIGF1Z21lbnRhdGlvbi9pbXBsZW1lbnRhdGlvbiBjb3VsZCBkbyB0aGlzLCBidXQgdGhl
DQo+Pj4gbW9kZWwgbmVlZHMgdG8gc3VwcG9ydCBpbmNsdXNpb24gb2YgaXB2NCBhbmQgaXB2NiBp
biB0aGUgc2FtZSBhY2wuDQo+Pj4gSan2bSBhd2FyZSBvZiBvdXRzdGFuZGluZyBjdXN0b21lcnMg
cmVxdWVzdHMgZm9yIGNvbWJpbmluZyBpcHY0IHJ1bGVzDQo+Pj4gYW5kIGlwdjYgcnVsZXMgaW4g
dGhlIHNhbWUgYWNsLCBidXQgbW9zdCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBub3QNCj4+PiBjYXVn
aHQgdXAgdG8gdGhpcy4gIFdoZW4gaXQgY29tZXMgdG8gbWFuYWdpbmcgYWNscyB0aGVyZSBzaG91
bGRuqfZ0IGJlDQo+Pj4gdGhpcyBkaXN0aW5jdGlvbiBiZXR3ZWVuIElQdjYgYW5kIElQdjQuICBU
aGV5IGFyZSBib3RoIElQIGFkZHJlc3Nlcy4NCj4NCj4NCj5bPj5KVFNdIEFnYWluIC0gbGV0J3Mg
Zm9jdXMgb24gY2FwdHVyaW5nIGNvbW1vbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMNCj5pbiB0
aGVzZSBzdGFuZGFyZCBtb2RlbHMgKHdoaWxlIGFsc28gYWxsb3dpbmcgZm9yIGF1Z21lbnRhdGlv
biBhbmQNCj5mbGV4aWJpbGl0eSkuICBWNCBhbmQgVjYgYXJlIGluIHNlcGFyYXRlIGxpc3RzIHRv
ZGF5LiAgQSBmdXR1cmUgbWl4ZWQNCj5saXN0IGNhbiB1c2UgdGhlICJtaXhlZCIgdHlwZSBvciBp
bnZlbnQgYSBuZXcgInY0K3Y2IiB0eXBlLg0KPg0KPj4+DQo+Pj4gPg0KPj4+ID5UaGF0IHdvdWxk
IGFsc28gaGVscCBpZiB3ZSBkZWNpZGUgdG8gcHV0IHNvbWUgY29uc3RyYWludHMgdGhhdA0KPj4+
ID5hbGxvdy9kaXNhbGxvdyBjZXJ0YWluIG1hdGNoaW5nIGNyaXRlcmlhIHdoZW4gdGhlIHR5cGUg
aXMgYSBzcGVjaWZpYw0KPj4+ID52YWx1ZSAoZS5nLiBkb24ndCBhbGxvdyBhIHY2IGFkZHJlc3Mg
bWF0Y2ggaW4gYSB2NCBsaXN0KS4NCj4+PiA+ICBXZSdkIGhhdmUgdG8gYmUgY2FyZWZ1bCBhYm91
dCBob3cgdGhvc2UgY29uc3RyYWludHMgYXJlIGZvcm11bGF0ZWQNCj4+PiA+dGhvdWdoIC0gZXNw
ZWNpYWxseSBpZiB3ZSB3YW50IHRvIGFsbG93IGF1Z21lbnRhdGlvbnMgb2YgdGhlDQo+Pj4gPmxp
c3QtdHlwZSBmb3IgIm1peGVkIiBBQ0xzLiBBIG5ldyAibWl4ZWQtdjQtZW5ldCIgdHlwZSAoaWRl
bnRpdHkpDQo+Pj4gPndvdWxkIGFsc28gbmVlZCB0byB1c2UgdGhlIGRlc3RpbmF0aW9uLWlwdjQt
bmV0d29yayBtYXRjaGluZw0KPj4+ID5jcml0ZXJpYSAoY2FuICJ3aGVuIiBvciAibXVzdCIgbG9n
aWMgYmUgY2hhbmdlZCBieSBhbiBhdWdtZW50YXRpb24gPw0KPj4+SSdtIG5vdCBzdXJlIHRoYXQg
d29ya3MpLg0KPj4+DQo+Pj4gWWVzLCB3b3VsZCBoYXZlIHRvIGJlIGNhcmVmdWwsIGFuZCBkZWZp
bmluZyBjb25zdHJhaW50cyBiYXNlZCBvbg0KPj4+ZXhpc3RpbmcNCj4+PiBpbXBsZW1lbnRhdGlv
bnMgY291bGQgYmUgYSB2ZXJ5IHNsaXBwZXJ5IHNsb3BlLiAgIFZlbmRvcnMgc2hvdWxkIGJlDQo+
Pj5hYmxlDQo+Pj4gdG8gbWFwIHRvIHRoZWlyIGltcGxlbWVudGF0aW9ucyBhbmQvb3IgaGF2ZSBh
IHByb3ByaWV0YXJ5DQo+Pj4gYXVnbWVudGF0aW9uIHRoYXQgY29uc3RyYWlucyB0aGluZ3MgbW9y
ZSBhY2NvcmRpbmcgdG8NCj4+PiB0aGVpciBpbXBsZW1lbnRhdGlvbi4gICBQcm9wcmlldGFyeSBh
dWdtZW50YXRpb25zIGNvdWxkIGJlIHByb3Bvc2VkLA0KPj4+YW5kDQo+Pj4gcmV2aWV3ZWQgZm9y
IHN0YW5kYXJkaXphdGlvbi4NCj4NCj4NCj5bPj5KVFNdIFRoZSBkcmFmdCBkb2Vzbid0IGhhdmUg
YW55IGNvbnN0cmFpbnRzIGJhc2VkIG9uIHR5cGUgc28gSSBzdXBwb3NlDQo+dGhpcyBwb2ludCBp
cyBtb290Lg0KPg0KPj4+DQo+Pj4gdGhhbmtzLA0KPj4+IERhbmENCj4+Pg0KPj4+ID4NCj4+PiA+
UmVnYXJkcywNCj4+PiA+SmFzb24NCj4+PiA+DQo+Pj4gPg0KPj4+ID5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID5uZXRtb2QgbWFpbGluZyBsaXN0
DQo+Pj4gPm5ldG1vZEBpZXRmLm9yZw0KPj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGll
dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN
Cj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pg0KPg0KPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxp
bmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5u
ZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KDQoNCg==


From nobody Sun Sep 27 23:55:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B11A6F9A for ; Sun, 27 Sep 2015 23:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.16
X-Spam-Level: 
X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsgoWIwps9os for ; Sun, 27 Sep 2015 23:55:20 -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 E09F31B3168 for ; Sun, 27 Sep 2015 23:55:18 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 96B2A9E4; Mon, 28 Sep 2015 08:55:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wlns2s9KxkYW; Mon, 28 Sep 2015 08:55:14 +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; Mon, 28 Sep 2015 08:55:14 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C2F420079; Mon, 28 Sep 2015 08:55:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8DVckwf5USJi; Mon, 28 Sep 2015 08:55:13 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7557F20056; Mon, 28 Sep 2015 08:55:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 4F045376871C; Mon, 28 Sep 2015 08:55:04 +0200 (CEST)
Date: Mon, 28 Sep 2015 08:55:04 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150928065504.GA95250@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , NETMOD Working Group 
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local>  <20150923131119.GA1945@elstar.local> <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz>
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: <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 06:55:22 -0000

On Wed, Sep 23, 2015 at 03:46:27PM +0200, Ladislav Lhotka wrote:
> 
> > On 23 Sep 2015, at 15:11, Juergen Schoenwaelder  wrote:
> > 
> > On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote:
> >>>> 
> >>>> I must admit I am getting lost in these discussions. It seems to me there is a lot of hand-waving and hidden assumptions that moreover differ from one person to another. As I already said in Prague, both anyxml and anydata are IMO constructs of marginal utility and it is frustrating we spend so much effort on them.
> >>>> 
> >>> 
> >>> I agree that anyxml is of marginal utility, anydata however is needed
> >>> for any rpc/action/notification or future language construct that can
> >>> work with generic YANG content and hence I think its behaviour and
> >>> encoding should be well defined.
> >> 
> >> But then I believe we should have stricter rules for anydata than just
> >> "an unknown set of nodes that can be modelled with YANG" - it should be
> >> stated that the data model for an anydata instance MUST be known at
> >> run-time. Otherwise I think anyxml can cover all use cases you mention
> >> as well (as it has done in the past), and there is no need to introduce
> >> a new data node type with a definition that allows for multiple
> >> interpretations.
> >> 
> > 
> > Lada, we are not repeating the discussion. It was long and painful
> > enough and we finally accepted and verified Y34-05. If you have better
> > wording to propose, feel free to make a proposal. But I am not going
> > to open Y34 again just because you still do not like it.
> 
> Experience has shown that the current formulation is understood differently by different people.
> 
> Earlier in this thread, you proposed this text to be added to the yang-json spec:
> 
>      An anydata data node can contain an unknown set of nodes that can
>      be modelled by YANG. A data model for anydata content may or may
>      not exist at run time.  If the data model for anydata content is
>      available, then the anydata content MUST be encoded according to
>      the rules of this specification. If the data model for anydata
>      content is not available, the encoding MUST follow the rules of
>      this specification except for rules that require data model
>      knowledge (and as a consequence, numbers may appear as strings or
>      namespace qualifiers may not match module names).
> 
> So let me repeat: shouldn’t this text really go to 6020bis? Or do you think that XML encoding needn’t abide by the data model if it is known?
>

Are you suggesting there should be similar text for the XML encoding or
are you suggesting there should be abstract text for all encodings?
RFC6020bis says currently:

   An anydata node is encoded as an XML element.  The element's local
   name is the anydata's identifier, and its namespace is the module's
   XML namespace (see Section 7.1.3).  The value of the anydata node is
   a set of nodes, which are encoded as XML subelements to the anydata
   element.

Perhaps it means 'set of data nodes' where it says 'set of nodes'. The
main difference here is that encoding anydata into XML is somewhat
easier since you do not need to know whether 42 has to be encoded as a
string or a number etc.

> > That said, "MUST be known at run-time" may already fall apart with the
> > mount proposals discussed in NETCONF (or it is sufficiently unclear to
> > whom it MUST be known).
> 
> To the server and client so that they both work with the same data model. Of course, it is true that currently there are no means for passing this information (either way) but I guess your text above suffers from the same problem: how can you tell whether the data model for anydata content is available or not? 
>

The example is a RESTCONF server mounting data from a remove datastore
and using JSON encoding when talking to RESTCONF clients. Do we
require that such a server has to have knowledge about the data model
mounted in order to get the encoding right? Or do we expect that the
RESTCONF client can deal with situations where encodings may not 100%
match the data model (e.g. lack of type knowledge, lack of namespace
to module name mappings).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 28 01:40:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BCD1B3263 for ; Mon, 28 Sep 2015 01:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.46
X-Spam-Level: 
X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqOTKv58P24c for ; Mon, 28 Sep 2015 01:40:17 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8733A1B325C for ; Mon, 28 Sep 2015 01:40:17 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51CB49E4; Mon, 28 Sep 2015 10:40:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id I-qrq03MvMGM; Mon, 28 Sep 2015 10:40:15 +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; Mon, 28 Sep 2015 10:40:15 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C94F20053; Mon, 28 Sep 2015 10:40:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rsdBOQrKyG6v; Mon, 28 Sep 2015 10:40:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38ADD2004E; Mon, 28 Sep 2015 10:40:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 768F837689A4; Mon, 28 Sep 2015 10:40:13 +0200 (CEST)
Date: Mon, 28 Sep 2015 10:40:13 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150928084013.GB95620@elstar.local>
Mail-Followup-To: Kent Watsen , Robert Wilton , Andy Bierman , "netmod@ietf.org" 
References:  <20150922142254.GB99134@elstar.local>   <20150922170012.GA99454@elstar.local>  <56027D26.8020801@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 08:40:19 -0000

On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
> 
> Popping the stack on this issue, the issue remains as to what to do with requirement 3:
> 
>    3.  Support for both transactional, synchronous management systems
>         as well as distributed, asynchronous management systems
>

I fail to understand 'transactional' and 'distributed' here. And
frankly, I am not sure why the management _systems_ are classified to
be synchronous or asynchronous - I think we are talking about
protocols between a management system and a device. In NETCONF as well
as RESTCONF are, you can pipeline YANG operations but all operations
are processed sequentially in order.

There are apparently other proprietary protocols that do things
differently but so far we have not seen a specification of how this
works.

Anyway, I am not sure 3. is properly worded until someone defines
'transactional', 'distributed', 'synchronous management systems' and
'asynchronous management systems'.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 28 03:15:34 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF81B333A for ; Mon, 28 Sep 2015 03:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level: 
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVquhVUP0GHN for ; Mon, 28 Sep 2015 03:15:30 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9335B1B333B for ; Mon, 28 Sep 2015 03:15:29 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id D85C41AE0481; Mon, 28 Sep 2015 12:15:27 +0200 (CEST)
Date: Mon, 28 Sep 2015 12:15:27 +0200 (CEST)
Message-Id: <20150928.121527.98978972249244610.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <56056192.7010301@mg-soft.si>
References: <560548F4.8080505@mg-soft.si> <20150925.152224.1416615960207331298.mbj@tail-f.com> <56056192.7010301@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 10:15:33 -0000

SmVybmVqIFR1bGphayA8amVybmVqdEBtZy1zb2Z0LnNpPiB3cm90ZToNCj4gTWFydGluIEJqb3Jr
bHVuZCBqZSAyNS45LjIwMTUgb2IgMTU6MjIgbmFwaXNhbDoNCj4gPiBKZXJuZWogVHVsamFrIDxq
ZXJuZWp0QG1nLXNvZnQuc2k+IHdyb3RlOg0KPiA+PiBMYWRpc2xhdiBMaG90a2EgamUgMjUuOS4y
MDE1IG9iIDEzOjQ0IG5hcGlzYWw6DQo+ID4+PiBKZXJuZWogVHVsamFrIDxqZXJuZWp0QG1nLXNv
ZnQuc2k+IHdyaXRlczoNCj4gPj4+DQo+ID4+Pj4gTGFkaXNsYXYgTGhvdGthIGplIDI1LjkuMjAx
NSBvYiA5OjU4IG5hcGlzYWw6DQo+ID4+Pj4+IEplcm5laiBUdWxqYWsgPGplcm5lanRAbWctc29m
dC5zaT4gd3JpdGVzOg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gTWFydGluIEJqb3JrbHVuZCBqZSAyNC45
LjIwMTUgb2IgMTM6NTQgbmFwaXNhbDoNCj4gPj4+Pj4+PiBKZXJuZWogVHVsamFrIDxqZXJuZWp0
QG1nLXNvZnQuc2k+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBMYWRpc2xhdiBMaG90a2EgamUgMjMuOS4y
MDE1IG9iIDE0OjI5IG5hcGlzYWw6DQo+ID4+Pj4+Pj4+PiBKZXJuZWogVHVsamFrIDxqZXJuZWp0
QG1nLXNvZnQuc2k+IHdyaXRlczoNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gTGFkaXNsYXYg
TGhvdGthIGplIDIzLjkuMjAxNSBvYiAxMjo1MiBuYXBpc2FsOg0KPiA+Pj4+Pj4+Pj4+Pj4gT24g
MjMgU2VwIDIwMTUsIGF0IDEyOjM3LCBKZXJuZWogVHVsamFrIDxqZXJuZWp0QG1nLXNvZnQuc2k+
DQo+ID4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBM
YWRpc2xhdiBMaG90a2EgamUgMjMuOS4yMDE1IG9iIDExOjU4IG5hcGlzYWw6DQo+ID4+Pj4+Pj4+
Pj4+Pj4+IE9uIDIzIFNlcCAyMDE1LCBhdCAxMTo0NSwgSmVybmVqIFR1bGphayA8amVybmVqdEBt
Zy1zb2Z0LnNpPg0KPiA+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4+Pj4NCj4g
Pj4+Pj4+Pj4+Pj4+Pj4gU2VjdGlvbiA3LjIxLjUuLCB0aGUgZmlyc3QgYnVsbGV0IGRlc2NyaWJp
bmcgdGhlIGF1Z21lbnRhdGlvbg0KPiA+Pj4+Pj4+Pj4+Pj4+PiBjYXNlDQo+ID4+Pj4+Pj4+Pj4+
Pj4+IGRvZXMgbm90IGNvbnNpZGVyIHRoYXQgYW4gImF1Z21lbnQiIG1heSBzcGVjaWZ5IGEgdG9w
LWxldmVsDQo+ID4+Pj4+Pj4+Pj4+Pj4+ICJjaG9pY2UiDQo+ID4+Pj4+Pj4+Pj4+Pj4+IG9yIGEg
ImNob2ljZSIvImNhc2UiIG5lc3RlZCB3aXRoaW4gYSB0b3AtbGV2ZWwgImNob2ljZSIgYXMgdGhl
DQo+ID4+Pj4+Pj4+Pj4+Pj4+IHRhcmdldA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBub2RlLiBUaGVyZSB3
aWxsIGJlIG5vIGluaXRpYWwgY29udGV4dCBub2RlIGZvciB0aGUgZXhwcmVzc2lvbg0KPiA+Pj4+
Pj4+Pj4+Pj4+PiBpbg0KPiA+Pj4+Pj4+Pj4+Pj4+PiBzdWNoDQo+ID4+Pj4+Pj4+Pj4+Pj4+IGEg
Y2FzZS4NCj4gPj4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgIGxlYWYgZW5h
YmxlLWZvb3Mgew0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICB0eXBlIGJvb2xlYW47DQo+ID4+
Pj4+Pj4+Pj4+Pj4+ICAgICAgICB9DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICBjaG9pY2UgY2gx
IHsNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgY2FzZSBmb28gew0KPiA+Pj4+Pj4+Pj4+Pj4+
PiAgICAgICAgICAgIGNob2ljZSBmb29zIHsNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAg
IHdoZW4gImVuYWJsZS1mb29zID0gJ3RydWUnIjsNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAg
ICAgIGxlYWYgZm9vMSB7DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgIHR5cGUgc3Ry
aW5nOw0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgfQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAg
ICAgICAgICAgICAgbGVhZiBmb28yIHsNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAg
dHlwZSBzdHJpbmc7DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICB9DQo+ID4+Pj4+Pj4+
Pj4+Pj4+ICAgICAgICAgICAgfQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICB9DQo+ID4+Pj4+
Pj4+Pj4+Pj4+ICAgICAgICAgIGNvbnRhaW5lciBtZWg7DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAg
ICB9DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICBhdWdtZW50ICIv
Y2gxL2Zvby9mb29zIiB7DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgIHdoZW4gImVuYWJsZS1m
b29zID0gJ3RydWUnIjsNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgbGVhZiBmb28zIHsNCj4g
Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPj4+Pj4+Pj4+Pj4+Pj4g
ICAgICAgICAgfQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgfQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pg0K
PiA+Pj4+Pj4+Pj4+Pj4+PiBPTEQ6DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+
ICAgICAgICAgbyBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFuICJhdWdt
ZW50Ig0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgIHN0YXRlbWVudCwNCj4gPj4+Pj4+Pj4+Pj4+
Pj4gICAgICAgICB0aGVuDQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgdGhlIGNvbnRleHQg
bm9kZSBpcyB0aGUgYXVnbWVudCdzIHRhcmdldCBub2RlIGluIHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4+
PiAgICAgICAgICAgIGRhdGEgdHJlZSwNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICBpZg0K
PiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgIHRoZSB0YXJnZXQgbm9kZSBpcyBhIGRhdGEgbm9k
ZS4gIE90aGVyd2lzZSwgdGhlDQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgY29udGV4dA0K
PiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgIG5vZGUgaXMNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAg
ICAgICAgICB0aGUgY2xvc2VzdCBhbmNlc3RvciBub2RlIHRvIHRoZSB0YXJnZXQgbm9kZSB0aGF0
IGlzDQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgYWxzbyBhIGRhdGENCj4gPj4+Pj4+Pj4+
Pj4+Pj4gICAgICAgICAgICBub2RlLg0KPiA+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+
PiBORVc6DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgbyBJZiB0
aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFuICJhdWdtZW50Ig0KPiA+Pj4+Pj4+
Pj4+Pj4+PiAgICAgICAgIHN0YXRlbWVudCwNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICB0aGVu
DQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgdGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgYXVn
bWVudCdzIHRhcmdldCBub2RlIGluIHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgIGRh
dGEgdHJlZSwNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICBpZg0KPiA+Pj4+Pj4+Pj4+Pj4+
PiAgICAgICAgICAgIHRoZSB0YXJnZXQgbm9kZSBpcyBhIGRhdGEgbm9kZS4gIE90aGVyd2lzZSwg
dGhlDQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgY29udGV4dA0KPiA+Pj4+Pj4+Pj4+Pj4+
PiAgICAgICAgICAgIG5vZGUgaXMNCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICB0aGUgY2xv
c2VzdCBhbmNlc3RvciBub2RlIHRvIHRoZSB0YXJnZXQgbm9kZSB0aGF0IGlzDQo+ID4+Pj4+Pj4+
Pj4+Pj4+ICAgICAgICAgICAgYWxzbyBhIGRhdGENCj4gPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAg
ICBub2RlLiBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBub2RlIGlzDQo+ID4+
Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgdGhlDQo+ID4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAg
cm9vdCBub2RlLg0KPiA+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+IEdvb2QgY2F0Y2gs
IEkgc3VwcG9ydCB0aGlzIGNoYW5nZS4NCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+
IEFsc28gcmVnYXJkaW5nIHNlYy4gNy4yMS41LCBJIHRoaW5rIHdlIGFncmVlZCB0aGF0IGEgd2hl
bg0KPiA+Pj4+Pj4+Pj4+Pj4+IGV4cHJlc3Npb24NCj4gPj4+Pj4+Pj4+Pj4+PiBtdXN0IG5vdCBy
ZWZlcmVuY2Ugbm9kZXMgdGhhdCBhcmUgbWFkZSBjb25kaXRpb25hbCB0aHJvdWdoIHRoYXQNCj4g
Pj4+Pj4+Pj4+Pj4+PiB3aGVuDQo+ID4+Pj4+Pj4+Pj4+Pj4gc3RhdGVtZW50LiBJIGNhbuKAmXQg
ZmluZCB0aGlzIHJ1bGUgaW4gdGhlIHRleHQuDQo+ID4+Pj4+Pj4+Pj4+PiBUaGUgIm5vIHJlZmVy
ZW5jaW5nIHRoZSBpbml0aWFsIGNvbnRleHQgbm9kZSBhbmQgaXRzIGRlc2NlbmRhbnRzIg0KPiA+
Pj4+Pj4+Pj4+Pj4gdGV4dA0KPiA+Pj4+Pj4+Pj4+Pj4gaXMgY3VycmVudGx5IGluIHRoZSBndWlk
ZWxpbmVzIGRyYWZ0IG9ubHkgKDYwODdiaXMpLg0KPiA+Pj4+Pj4+Pj4+PiBJTU8gdGhpcyBzaG91
bGQgYmUgYSBoYXJkIHJ1bGUgaW4gNjAyMGJpcy4gU3VjaCBleHByZXNzaW9ucyBhcmUNCj4gPj4+
Pj4+Pj4+Pj4gc2VyaW91c2x5IGJyb2tlbiBhbmQgY291bGQgbGVhZCB0byBkZWFkbG9ja3MuDQo+
ID4+Pj4+Pj4+Pj4gSSB0aGluayB0aGF0IHdhcyB0aGUgcHVycG9zZSBvZiB0aGUgY2hhbmdlIGlu
IDNyZCBidWxsZXQuIEEgImR1bW15Ig0KPiA+Pj4+Pj4+Pj4+IG5vZGUNCj4gPj4+Pj4+Pj4+PiB3
aXRoIG5vIHZhbHVlIGFuZCBjaGlsZCBub2RlcyBoYXMgYmVlbiBpbnRyb2R1Y2VkLg0KPiA+Pj4+
Pj4+Pj4gTm90IHJlYWxseSwgdGhlIGR1bW15IG5vZGUgc29sdmVzIHRoZSBwcm9ibGVtIG9mIGEg
bm9uLWV4aXN0ZW50DQo+ID4+Pj4+Pj4+PiBjb250ZXh0DQo+ID4+Pj4+Pj4+PiBub2RlLg0KPiA+
Pj4+Pj4+PiBBcmUgeW91IHJlZmVycmluZyB0byAiZXhpc3RlbmNlIiBpbiB0aGUgaW5zdGFuY2Ug
ZG9jdW1lbnQgb3IgdGhlDQo+ID4+Pj4+Pj4+IHNjaGVtYSB0cmVlPyBXaHkgaXMgdGhlcmUgbm8g
bmVlZCBmb3IgIm5vIGNoaWxkcmVuLCBubyB2YWx1ZSBkdW1teSINCj4gPj4+Pj4+Pj4gaW4NCj4g
Pj4+Pj4+Pj4gMXN0IGFuZCAybmQgYnVsbGV0Pw0KPiA+Pj4+Pj4+IEluIHRoZXNlIGNhc2VzLCB0
aGUgY29udGV4dCBub2RlIGlzIHdlbGwtZGVmaW5lZCBhbnl3YXkuICBCdXQgSSB0aGluaw0KPiA+
Pj4+Pj4+IHRoYXQgYWxzbyB0aGVzZSBidWxsZXRzIG5lZWQgdG8gaGF2ZSB0ZXh0IHRoYXQgbWFr
ZSBzdXJlIHRoYXQgdGhlDQo+ID4+Pj4+Pj4gb3V0Y29tZSBpcyBkZXRlcm1pbmlzdGljIGluIGFs
bCBjYXNlcywgc3VjaCBhczoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgIGF1Z2VtZW50IC9m
b28gew0KPiA+Pj4+Pj4+ICAgICAgICAgd2hlbiAiYmFyID4gMSI7DQo+ID4+Pj4+Pj4gICAgICAg
ICBsZWFmIGJhciB7IHR5cGUgaW50MzI7IH0NCj4gPj4+Pj4+PiAgICAgICB9DQo+ID4+Pj4+Pj4N
Cj4gPj4+Pj4+PiBvcg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICAgZ3JvdXBpbmcgZm9vIHsN
Cj4gPj4+Pj4+PiAgICAgICAgIGxlYWYgYmFyIHsgdHlwZSBpbnQzMjsgfQ0KPiA+Pj4+Pj4+ICAg
ICAgIH0NCj4gPj4+Pj4+PiAgICAgICBjb250YWluZXIgeCB7DQo+ID4+Pj4+Pj4gICAgICAgICB1
c2VzIGZvbyB7DQo+ID4+Pj4+Pj4gICAgICAgICAgIHdoZW4gImJhciA+IDEiOw0KPiA+Pj4+Pj4+
ICAgICAgICAgfQ0KPiA+Pj4+Pj4+ICAgICAgIH0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+
Pj4+Pj4gZXRjLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gU28gSSBzdWdnZXN0IHRoaXMgTkVXIHRl
eHQ6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgICBvIElmIHRoZSAid2hl
biIgc3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW4gImF1Z21lbnQiIHN0YXRlbWVudCwNCj4gPj4+
Pj4+PiAgICAgICAgdGhlbg0KPiA+Pj4+Pj4+ICAgICAgICAgICB0aGUgY29udGV4dCBub2RlIGlz
IHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGENCj4gPj4+Pj4+PiAgICAgICAg
ICAgdHJlZSwNCj4gPj4+Pj4+PiAgICAgICAgICAgaWYNCj4gPj4+Pj4+PiAgICAgICAgICAgdGhl
IHRhcmdldCBub2RlIGlzIGEgZGF0YSBub2RlLiAgT3RoZXJ3aXNlLCB0aGUgY29udGV4dCBub2Rl
DQo+ID4+Pj4+Pj4gICAgICAgICAgIGlzDQo+ID4+Pj4+Pj4gICAgICAgICAgIHRoZSBjbG9zZXN0
IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMgYWxzbyBhDQo+ID4+Pj4+
Pj4gICAgICAgICAgIGRhdGENCj4gPj4+Pj4+PiAgICAgICAgICAgbm9kZS4gIElmIG5vIHN1Y2gg
bm9kZSBleGlzdHMsIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIHJvb3QNCj4gPj4+Pj4+PiAgICAg
ICAgICAgbm9kZS4NCj4gPj4+Pj4+PiAgICAgICAgICAgVGhlIGFjY2Vzc2libGUgdHJlZSBpcyB0
ZW50YXRpdmVseSBhbHRlcmVkIGR1cmluZyB0aGUNCj4gPj4+Pj4+PiAgICAgICAgICAgcHJvY2Vz
c2luZw0KPiA+Pj4+Pj4+ICAgICAgICAgICBvZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBieSByZW1v
dmluZyBhbGwgaW5zdGFuY2VzIChpZiBhbnkpDQo+ID4+Pj4+Pj4gICAgICAgICAgIG9mDQo+ID4+
Pj4+Pj4gICAgICAgICAgIHRoZQ0KPiA+Pj4+Pj4+ICAgICAgICAgICBub2RlcyBhZGRlZCBieSB0
aGUgImF1Z21lbnQiIHN0YXRlbWVudC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgICBvICBJ
ZiB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGEgInVzZXMiLCAiY2hvaWNlIiwg
b3INCj4gPj4+Pj4+PiAgICAgICAgICAgImNhc2UiIHN0YXRlbWVudCwgdGhlbiB0aGUgY29udGV4
dCBub2RlIGlzIHRoZSBjbG9zZXN0DQo+ID4+Pj4+Pj4gICAgICAgICAgIGFuY2VzdG9yDQo+ID4+
Pj4+Pj4gICAgICAgICAgIG5vZGUgdG8gdGhlICJ1c2VzIiwgImNob2ljZSIsIG9yICJjYXNlIiBu
b2RlIHRoYXQgaXMgYWxzbyBhDQo+ID4+Pj4+Pj4gICAgICAgICAgIGRhdGENCj4gPj4+Pj4+PiAg
ICAgICAgICAgbm9kZS4gIElmIG5vIHN1Y2ggbm9kZSBleGlzdHMsIHRoZSBjb250ZXh0IG5vZGUg
aXMgdGhlIHJvb3QNCj4gPj4+Pj4+PiAgICAgICAgICAgbm9kZS4NCj4gPj4+Pj4+PiAgICAgICAg
ICAgVGhlIGFjY2Vzc2libGUgdHJlZSBpcyB0ZW50YXRpdmVseSBhbHRlcmVkIGR1cmluZyB0aGUN
Cj4gPj4+Pj4+PiAgICAgICAgICAgcHJvY2Vzc2luZw0KPiA+Pj4+Pj4+ICAgICAgICAgICBvZiB0
aGUgWFBhdGggZXhwcmVzc2lvbiBieSByZW1vdmluZyBhbGwgaW5zdGFuY2VzIChpZiBhbnkpDQo+
ID4+Pj4+Pj4gICAgICAgICAgIG9mDQo+ID4+Pj4+Pj4gICAgICAgICAgIHRoZQ0KPiA+Pj4+Pj4+
ICAgICAgICAgICBub2RlcyBhZGRlZCBieSB0aGUgInVzZXMiLCAiY2hvaWNlIiwgb3IgImNhc2Ui
IHN0YXRlbWVudC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAgICBvIElmIHRoZSAid2hlbiIg
c3RhdGVtZW50IGlzIGEgY2hpbGQgb2YgYW55IG90aGVyIGRhdGENCj4gPj4+Pj4+PiAgICAgICAg
ZGVmaW5pdGlvbg0KPiA+Pj4+Pj4+ICAgICAgICAgICBzdGF0ZW1lbnQsIHRoZSBhY2Nlc3NpYmxl
IHRyZWUgaXMgdGVudGF0aXZlbHkgYWx0ZXJlZCBkdXJpbmcNCj4gPj4+Pj4+PiAgICAgICAgICAg
dGhlDQo+ID4+Pj4+Pj4gICAgICAgICAgIHByb2Nlc3Npbmcgb2YgdGhlIFhQYXRoIGV4cHJlc3Np
b24gYnkgcmVwbGFjaW5nIGFsbA0KPiA+Pj4+Pj4+ICAgICAgICAgICBpbnN0YW5jZXMNCj4gPj4+
Pj4+PiAgICAgICAgICAgKGlmDQo+ID4+Pj4+Pj4gICAgICAgICAgIGFueSkgb2YgdGhlIGRhdGEg
bm9kZSBmb3Igd2hpY2ggdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMNCj4gPj4+Pj4+PiAgICAgICAg
ICAgZGVmaW5lZA0KPiA+Pj4+Pj4+ICAgICAgICAgICB3aXRoIGEgc2luZ2xlIGR1bW15IG5vZGUg
d2l0aCB0aGUgc2FtZSBuYW1lLCBidXQgd2l0aCBubw0KPiA+Pj4+Pj4+ICAgICAgICAgICB2YWx1
ZQ0KPiA+Pj4+Pj4+ICAgICAgICAgICBhbmQNCj4gPj4+Pj4+PiAgICAgICAgICAgbm8gY2hpbGRy
ZW4uICBUaGUgY29udGV4dCBub2RlIGlzIHRoaXMgZHVtbXkgbm9kZS4NCj4gPj4+Pj4+Pg0KPiA+
Pj4+Pj4gKzENCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICBjb250YWluZXIgZm9vIHsNCj4gPj4+
Pj4+ICAgICAgICAgd2hlbiAiY2hpbGQ6Oiogb3IgY2hpbGQ6OnRleHQoKSBvciBub3Qoc2VsZjo6
KikiOyAvLyBhbHdheXMNCj4gPj4+Pj4+ICAgICAgICAgZmFsc2UNCj4gPj4+Pj4+ICAgICAgICAg
bGVhZiBiYXIgew0KPiA+Pj4+Pj4gICAgICAgICAgIHR5cGUgc3RyaW5nOw0KPiA+Pj4+Pj4gICAg
ICAgICB9DQo+ID4+Pj4+PiAgICAgICB9DQo+ID4+Pj4+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0
dGVyIHRvIGNsZWFybHkgc3RhdGUgdGhhdCBhICJ3aGVuIiBleHByZXNzaW9uDQo+ID4+Pj4+IE1V
U1QgTk9UIHJlZmVyIHRvIG5vZGVzIHRoYXQgYXJlIG1hZGUgY29uZGl0aW9uYWwgYnkgdGhlIHNh
bWUgIndoZW4iDQo+ID4+Pj4+IHN0YXRlbWVudCAtIGl0J3Mgc2ltaWxhciB0byB0aGUgcnVsZSB0
aGF0IGZvcmJpZHMgbXV0dWFsIHJlZmVyZW5jZXMuDQo+ID4+Pj4+IFRoaXMgd291bGQgYWxzbyBj
b3ZlciBhbGwgdXNlcyBvZiAid2hlbiIuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBhYm92ZSBleGFt
cGxlIHdvdWxkIGJlIHJlYWxseSBjb25mdXNpbmcgaWYgdGhlICJiYXIiIGluc3RhbmNlIGlzDQo+
ID4+Pj4+IHByZXNlbnQuDQo+ID4+Pj4gSXQgaXMgdHJ1ZSB0aGF0IHRoaXMgaW50cm9kdWNlcyBh
IGNhdmVhdCB0aGF0IGlzIGJvdW5kIHRvIGNvbmZ1c2UgZW5kDQo+ID4+Pj4gWUFORyB1c2Vycy4N
Cj4gPj4+Pg0KPiA+Pj4+PiAgICAgSSBhbHNvIGRvbid0IGxpa2UgdGhlIGZhY3QgdGhhdCAid2hl
biIgYW5kICJtdXN0IiB3b3VsZCBnaXZlDQo+ID4+Pj4+IGRpZmZlcmVudCByZXN1bHRzIGluIHRo
aXMgY2FzZS4NCj4gPj4+PiBKdXN0IHRvIGJlIGNsZWFyLCB5b3Ugd291bGQgbGlrZSB0aGlzLCBy
aWdodD8NCj4gPj4+Pg0KPiA+Pj4+IE5FVzoNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgIFRoZSBYUGF0
aCBleHByZXNzaW9uIGlzIGNvbmNlcHR1YWxseSBldmFsdWF0ZWQgaW4gdGhlIGZvbGxvd2luZw0K
PiA+Pj4+ICAgICAgIGNvbnRleHQsIGluIGFkZGl0aW9uIHRvIHRoZSBkZWZpbml0aW9uIGluU2Vj
dGlvbiA2LjQuMQ0KPiA+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1uZXRtb2QtcmZjNjAyMGJpcy0wNyNzZWN0aW9uLTYuNC4xPjoNCj4gPj4+Pg0KPiA+Pj4+ICAg
ICAgIG8gSWYgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBvZiBhbiAiYXVnbWVudCIg
c3RhdGVtZW50LA0KPiA+Pj4+ICAgICAgIHRoZW4NCj4gPj4+PiAgICAgICAgICB0aGUgY29udGV4
dCBub2RlIGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUgaW4gdGhlIGRhdGEgdHJlZSwNCj4g
Pj4+PiAgICAgICAgICBpZg0KPiA+Pj4+ICAgICAgICAgIHRoZSB0YXJnZXQgbm9kZSBpcyBhIGRh
dGEgbm9kZS4gIE90aGVyd2lzZSwgdGhlIGNvbnRleHQgbm9kZSBpcw0KPiA+Pj4+ICAgICAgICAg
IHRoZSBjbG9zZXN0IGFuY2VzdG9yIG5vZGUgdG8gdGhlIHRhcmdldCBub2RlIHRoYXQgaXMgYWxz
byBhIGRhdGENCj4gPj4+PiAgICAgICAgICBub2RlLiBJZiBubyBzdWNoIG5vZGUgZXhpc3RzLCB0
aGUgY29udGV4dCBub2RlIGlzIHRoZSByb290IG5vZGUuDQo+ID4+Pj4NCj4gPj4+PiAgICAgICBv
ICBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGEgInVzZXMiLCAiY2hvaWNl
Iiwgb3INCj4gPj4+PiAgICAgICAgICAiY2FzZSIgc3RhdGVtZW50LCB0aGVuIHRoZSBjb250ZXh0
IG5vZGUgaXMgdGhlIGNsb3Nlc3QgYW5jZXN0b3INCj4gPj4+PiAgICAgICAgICBub2RlIHRvIHRo
ZSAidXNlcyIsICJjaG9pY2UiLCBvciAiY2FzZSIgbm9kZSB0aGF0IGlzIGFsc28gYSBkYXRhDQo+
ID4+Pj4gICAgICAgICAgbm9kZS4gIElmIG5vIHN1Y2ggbm9kZSBleGlzdHMsIHRoZSBjb250ZXh0
IG5vZGUgaXMgdGhlIHJvb3QNCj4gPj4+PiAgICAgICAgICBub2RlLg0KPiA+Pj4+DQo+ID4+Pj4g
ICAgICAgbyAgSWYgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBvZiBhbnkgb3RoZXIg
ZGF0YSBkZWZpbml0aW9uDQo+ID4+Pj4gICAgICAgICAgc3RhdGVtZW50LCB0aGUgY29udGV4dCBu
b2RlIGlzIHRoZSBub2RlIGluIHRoZSBhY2Nlc3NpYmxlIHRyZWUNCj4gPj4+PiAgICAgICAgICBm
b3INCj4gPj4+PiAgICAgICAgICB3aGljaCB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBkZWZpbmVk
Lg0KPiA+Pj4+ICAgICAgICAgICAgQW4gWFBhdGggZXhwcmVzc2lvbiBNVVNUIE5PVCByZWZlcmVu
Y2Ugbm9kZXMgdGhhdCBhcmUgbWFkZQ0KPiA+Pj4+ICAgICAgICAgICAgY29uZGl0aW9uYWwNCj4g
Pj4+PiAgICAgICBieSB0aGUgIndoZW4iIHN0YXRlbWVudCB0aGF0IGRlZmluZXMgaXQuDQo+ID4+
PiBZZXMsIHBsdXMgdGhlIG90aGVyIHR3byBydWxlcyB0aGF0IGFyZSBhbHJlYWR5IGluIDYwMjBi
aXM6DQo+ID4+Pg0KPiA+Pj4gSWYgdGhlIFhQYXRoIGV4cHJlc3Npb24gcmVmZXJlbmNlcyBhbnkg
bm9kZSB0aGF0IGFsc28gaGFzIGFzc29jaWF0ZWQNCj4gPj4+ICJ3aGVuIiBzdGF0ZW1lbnRzLCB0
aGVzZSAid2hlbiIgZXhwcmVzc2lvbnMgTVVTVCBiZSBldmFsdWF0ZWQgZmlyc3QuDQo+ID4+Pg0K
PiA+Pj4gVGhlcmUgTVVTVCBOT1QgYmUgYW55IGNpcmN1bGFyIGRlcGVuZGVuY2llcyBpbiB0aGVz
ZSAid2hlbiINCj4gPj4+IGV4cHJlc3Npb25zLg0KPiA+Pj4+IEkgZG9uJ3Qgc2VlIGEgY2FzZSBp
biB3aGljaCB0aGUgY29udGV4dCBub2RlIGlzIG5vbi1leGlzdGVudCAoaW4gdGhlDQo+ID4+Pj4g
c2NoZW1hIHRyZWUpIGluIGFueSBvZiB0aGUgdGhyZWUgYnVsbGV0cywgZXZlbiB3aXRob3V0ICJu
byB2YWx1ZSwgbm8NCj4gPj4+PiBkZXNjZW5kYW50cyIgZHVtbXkgbm9kZS4NCj4gPj4+IFRoZSB0
aGlyZCBidWxsZXQgaXMgYWltZWQgYXQgY2FzZXMgbGlrZSB0aGlzOg0KPiA+Pj4NCj4gPj4+IGxl
YWYgZm9vIHsNCj4gPj4+ICAgICAgIHdoZW4gIi4uL2JhciA+IDAiOw0KPiA+Pj4gICAgICAgbWFu
ZGF0b3J5IHRydWU7DQo+ID4+PiAgICAgICAuLi4NCj4gPj4+IH0NCj4gPj4+DQo+ID4+PiBJZiB0
aGVyZSBpcyBubyBpbnN0YW5jZSBvZiAiZm9vIiwgYSB2YWxpZGF0b3IgaGFzIHRvIGZpbmQgb3V0
IHdoZXRoZXINCj4gPj4+IHRoZSAibWFuZGF0b3J5IiBzdGF0ZW1lbnQgYXBwbGllcyAoYW5kIHRo
ZSBhYnNlbmNlIG9mICJmb28iIGlzIHRodXMgYQ0KPiA+Pj4gc2NoZW1hIGVycm9yKSwgb3Igd2hl
dGhlciBpdCBpcyBvdmVycnVsZWQgYnkgdGhlICJ3aGVuIiBleHByZXNzaW9uDQo+ID4+PiBiZWlu
Zw0KPiA+Pj4gZmFsc2UuIEJ1dCBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGV2YWx1YXRlIHRoYXQg
ZXhwcmVzc2lvbiwgWFBhdGgNCj4gPj4+IHJlcXVpcmVzIGEgY29udGV4dCBub2RlIGluIHRoZSBp
bnN0YW5jZSBkb2N1bWVudCwgc28gd2UgbmVlZCB0bw0KPiA+Pj4gdGVudGF0aXZlbHkgYWRkIG9u
ZS4NCj4gPj4gVGhlbiB0aGUgZHVtbXkgbm9kZSB0ZXh0IGlzIGJyb2tlbiBhbGwgdG9nZXRoZXIu
IEl0IGluc3RydWN0cyB0bw0KPiA+PiBtb2RpZnkgdGhlIGFjY2Vzc2libGUgdHJlZSAoc2NoZW1h
KQ0KPiA+IFRoZSBhY2Nlc3NpYmxlIHRyZWUgaXMgbm90IHRoZSBzY2hlbWEsIGl0IGlzIHRoZSBp
bnN0YW5jZSBkYXRhLg0KPiA+DQo+ID4+IGluc3RlYWQgb2YgaW5zdHJ1Y3RpbmcgdG8NCj4gPj4g
aW5zdGFudGlhdGUgYSBkdW1teSBpZiBhbiBpbnN0YW5jZSBvZiB0aGUgY29udGV4dCBub2RlIGRv
ZXMgbm90DQo+ID4+IGV4aXN0Lg0KPiA+IE5vLCB0aGUgdGV4dCBzYXlzICpyZXBsYWNlKiBhbnkg
aW5zdGFuY2VzIHdpdGggdGhlIGR1bW15IGluc3RhbmNlOw0KPiA+IHRoaXMgZW5zdXJlcyB0aGF0
IHRoZSByZXN1bHQgaXMgdGhlIHNhbWUgcmVnYXJkbGVzcyBvZiBpZiB0aGUgbm9kZQ0KPiA+IGV4
aXN0cyBvciBub3QuDQo+IA0KPiBPa2F5LCB0aGUgYWNjZXNzaWJsZSB0cmVlIGlzIGluc3RhbnRp
YXRlZCBkYXRhIG5vZGVzLg0KPiANCj4gY29udGFpbmVyIHRvcCB7DQo+ICAgICBsZWFmIGZvbyB7
DQo+ICAgICAgICAgd2hlbiAiLi4vYmFyID4gMCI7DQo+ICAgICAgICAgbWFuZGF0b3J5IHRydWU7
DQo+ICAgICAgICAgLi4uDQo+ICAgICB9DQo+IH0NCj4gDQo+ICJ0b3AiOiB7fQ0KPiANCj4gInRv
cCI6IHsgImZvbyI6ICIiIH0NCj4gDQo+IEhvdyBpcyBhIGNvbnRleHQgbm9kZSBlbnN1cmVkIGZv
ciB0aGUgdHdvIGluc3RhbmNlcywgaWYgcmVwbGFjaW5nDQo+IHNvbWV0aGluZyB0aGF0IG1heSBu
b3QgZXhpc3Q/IFlvdSB3b3VsZCBuZWVkIHRvIGNyZWF0ZSBhIGR1bW15IGlmDQo+IHRoZXJlIGlz
IG5vICJmb28iIGluc3RhbmNlLCByaWdodD8gVGhlIHRleHQgb25seSBzYXlzICJyZXBsYWNlIi4N
Cg0KT2s7IHRoZSBpbnRlbnRpb24gd2FzICJyZXBsYWNlIGlmIGl0IGV4aXN0cywgYW5kIGNyZWF0
ZSBvdGhlcndpc2UiDQooaS5lLiwgInJlcGxhY2UiIGFzIGluIE5FVENPTkYgZWRpdCBvcGVyYXRp
b24pLiAgIFdlIGNhbiBtYWtlIHRoaXMNCmV4cGxpY2l0Og0KDQpORVc6DQoNCi0gSWYgdGhlICJ3
aGVuIiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBvZiBhbnkgb3RoZXIgZGF0YSBkZWZpbml0aW9uDQog
IHN0YXRlbWVudCwgdGhlIGFjY2Vzc2libGUgdHJlZSBpcyB0ZW50YXRpdmVseSBhbHRlcmVkIGR1
cmluZyB0aGUNCiAgcHJvY2Vzc2luZyBvZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBieSByZXBsYWNp
bmcgYWxsIGluc3RhbmNlcyBvZiB0aGUNCiAgZGF0YSBub2RlIGZvciB3aGljaCB0aGUgIndoZW4i
IHN0YXRlbWVudCBpcyBkZWZpbmVkIHdpdGggYSBzaW5nbGUNCiAgZHVtbXkgbm9kZSB3aXRoIHRo
ZSBzYW1lIG5hbWUsIGJ1dCB3aXRoIG5vIHZhbHVlIGFuZCBubyBjaGlsZHJlbi4NCiAgSWYgbm8g
aW5zdGFuY2VzIG9mIHRoZSBkYXRhIG5vZGUgZXhpc3RzLCB0aGUgZHVtbXkgbm9kZSBpcyBjcmVh
dGVkLg0KICBUaGUgY29udGV4dCBub2RlIGlzIHRoaXMgZHVtbXkgbm9kZS4NCg0KDQoNCg0KPiA+
PiBBIGNvbnRleHQgbm9kZSBhbHdheXMgZXhpc3RzIGluIHRoZSBzY2hlbWEgdHJlZS4NCj4gPiBU
aGUgY29udGV4dCBub2RlIGlzIGluIHRoZSBkYXRhIHRyZWUuDQo+ID4NCj4gPj4gSU1PLCB0aGlz
DQo+ID4+IG5lZWRzIHRvIGJlIGZpeGVkIGluIG9yZGVyIHRvIHByZXZlbnQgdGhlIGludGVycHJl
dGF0aW9uIEkgY2FtZSB1cA0KPiA+PiB3aXRoIChhbmQgYWxzbyBCYWxhenMsIGluZGVwZW5kZW50
bHkpLiBUaGlzIGludGVycHJldGF0aW9uIHdhcyBjbGVhcmx5DQo+ID4+IG5vdCB0aGUgaW50ZW50
aW9uLg0KPiA+Pg0KPiA+PiBORVc6DQo+ID4+DQo+ID4+ICAgICBUaGUgWFBhdGggZXhwcmVzc2lv
biBpcyBjb25jZXB0dWFsbHkgZXZhbHVhdGVkIGluIHRoZSBmb2xsb3dpbmcNCj4gPj4gICAgIGNv
bnRleHQsIGluIGFkZGl0aW9uIHRvIHRoZSBkZWZpbml0aW9uIGluU2VjdGlvbiA2LjQuMQ0KPiA+
PiAgICAgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2
MDIwYmlzLTA3I3NlY3Rpb24tNi40LjE+Og0KPiA+Pg0KPiA+PiAgICAgbyAgSWYgdGhlICJ3aGVu
IiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBvZiBhbiAiYXVnbWVudCIgc3RhdGVtZW50LCB0aGVuDQo+
ID4+ICAgICAgICB0aGUgY29udGV4dCBub2RlIGlzIHRoZSBhdWdtZW50J3MgdGFyZ2V0IG5vZGUg
aW4gdGhlIGRhdGEgdHJlZSwgaWYNCj4gPj4gICAgICAgIHRoZSB0YXJnZXQgbm9kZSBpcyBhIGRh
dGEgbm9kZS4gIE90aGVyd2lzZSwgdGhlIGNvbnRleHQgbm9kZSBpcw0KPiA+PiAgICAgICAgdGhl
IGNsb3Nlc3QgYW5jZXN0b3Igbm9kZSB0byB0aGUgdGFyZ2V0IG5vZGUgdGhhdCBpcyBhbHNvIGEg
ZGF0YQ0KPiA+PiAgICAgICAgbm9kZS4gSWYgbm8gc3VjaCBub2RlIGV4aXN0cywgdGhlIGNvbnRl
eHQgbm9kZSBpcyB0aGUgcm9vdCBub2RlLg0KPiA+Pg0KPiA+PiAgICAgbyAgSWYgdGhlICJ3aGVu
IiBzdGF0ZW1lbnQgaXMgYSBjaGlsZCBvZiBhICJ1c2VzIiwgImNob2ljZSIsIG9yDQo+ID4+ICAg
ICAgICAiY2FzZSIgc3RhdGVtZW50LCB0aGVuIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIGNsb3Nl
c3QgYW5jZXN0b3INCj4gPj4gICAgICAgIG5vZGUgdG8gdGhlICJ1c2VzIiwgImNob2ljZSIsIG9y
ICJjYXNlIiBub2RlIHRoYXQgaXMgYWxzbyBhIGRhdGENCj4gPj4gICAgICAgIG5vZGUuICBJZiBu
byBzdWNoIG5vZGUgZXhpc3RzLCB0aGUgY29udGV4dCBub2RlIGlzIHRoZSByb290IG5vZGUuDQo+
ID4+DQo+ID4+ICAgICBvICBJZiB0aGUgIndoZW4iIHN0YXRlbWVudCBpcyBhIGNoaWxkIG9mIGFu
eSBvdGhlciBkYXRhIGRlZmluaXRpb24NCj4gPj4gICAgICAgIHN0YXRlbWVudCwgdGhlIGNvbnRl
eHQgbm9kZSBpcyB0aGUgbm9kZSBpbiB0aGUgYWNjZXNzaWJsZSB0cmVlIGZvcg0KPiA+PiAgICAg
ICAgd2hpY2ggdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaXMgZGVmaW5lZC4NCj4gPj4gICAgICAgICAg
ICBJZiBhbiBpbnN0YW5jZSBvZiB0aGUgY29udGV4dCBub2RlIGRvZXMgbm90IGV4aXN0IGR1cmlu
Zw0KPiA+PiAgICAgICAgICAgIHByb2Nlc3NpbmcNCj4gPj4gICAgIG9mIHRoZSBYUGF0aCBleHBy
ZXNzaW9uLCB0aGUgY29udGV4dCBub2RlIGlzIHRlbnRhdGl2ZWx5IGluc3RhbnRpYXRlZA0KPiA+
PiAgICAgYXMgYSBzaW5nbGUgZHVtbXkgbm9kZSB3aXRoIHRoZSBzYW1lIG5hbWUsIGJ1dCB3aXRo
IG5vIHZhbHVlIGFuZCBubw0KPiA+PiAgICAgY2hpbGRyZW4sIGFuZCBtZXJnZWQgaW50byB0aGUg
aW5zdGFuY2Ugb2YgdGhlIGFjY2Vzc2libGUgdHJlZS4NCj4gPj4NCj4gPj4gICAgIFRoZSByZXN1
bHQgb2YgdGhlIFhQYXRoIGV4cHJlc3Npb24gaXMgY29udmVydGVkIHRvIGEgYm9vbGVhbiB2YWx1
ZQ0KPiA+PiAgICAgdXNpbmcgdGhlIHN0YW5kYXJkIFhQYXRoIHJ1bGVzLg0KPiA+Pg0KPiA+PiAg
ICAgQW4gWFBhdGggZXhwcmVzc2lvbiBNVVNUIE5PVCByZWZlcmVuY2Ugbm9kZXMgdGhhdCBhcmUg
bWFkZSBjb25kaXRpb25hbA0KPiA+PiAgICAgYnkgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgdGhhdCBk
ZWZpbmVzIGl0Lg0KPiA+Pg0KPiA+PiAgICAgSWYgdGhlIFhQYXRoIGV4cHJlc3Npb24gcmVmZXJl
bmNlcyBhbnkgbm9kZSB0aGF0IGFsc28gaGFzIGFzc29jaWF0ZWQNCj4gPj4gICAgICJ3aGVuIiBz
dGF0ZW1lbnRzLCB0aGVzZSAid2hlbiIgZXhwcmVzc2lvbnMgTVVTVCBiZSBldmFsdWF0ZWQgZmly
c3QuDQo+ID4+DQo+ID4+ICAgICBUaGVyZSBNVVNUIE5PVCBiZSBhbnkgY2lyY3VsYXIgZGVwZW5k
ZW5jaWVzIGluIHRoZXNlICJ3aGVuIg0KPiA+PiAgICAgZXhwcmVzc2lvbnMuDQo+ID4+DQo+ID4+
IFNvbWV0aGluZyBsaWtlIHRoaXMgYWxzbyB0YWtlcyBjYXJlIG9mIE1hcnRpbidzIGV4YW1wbGUg
KCIqID0gNDIiKS4NCj4gPiBIb3c/ICBJdCBpcyBub3QgY2xlYXIgdG8gbWUgaWYgdGhlICcqJyBp
cyBsZWdhbCBvciBub3QuDQo+IA0KPiBJdCBqdXN0IG9jY3VycmVkIHRvIG1lIHRoYXQgaXQgaXMg
dmVyeSBoYXJkIHRvIG5vdCByZWZlcmVuY2UgdGhlDQo+IGNvbnRleHQgbm9kZSBpbiBhICJ3aGVu
IiBYUGF0aCBleHByZXNzaW9uLCBzaW5jZSB0aGUgY29udGV4dCBub2RlIGlzDQo+IGFsd2F5cyB5
b3VyIGluaXRpYWwgWFBhdGggY29udGV4dCAoeW91IGFsd2F5cyBzdGFydCB3aXRoIGEgbm9kZS1z
ZXQgb2YNCj4gc2l6ZSAxLCBjb250YWluaW5nIHRoZSBjb250ZXh0IG5vZGUpLg0KPiANCj4gIi4u
L2JhciIgc2F5cywgc2VsZWN0IHRoZSBwYXJlbnQgb2YgdGhlIGNvbnRleHQgbm9kZSwgdGhlbiBz
ZWxlY3QNCj4gImJhciIgY2hpbGQNCj4gIioiIHNheXMsIHNlbGVjdCB0aGUgY2hpbGRyZW4gb2Yg
dGhlIGNvbnRleHQgbm9kZSB0aGF0IGFyZSBhbHNvDQo+IGVsZW1lbnQgbm9kZXMNCj4gDQo+IFNv
LCB5ZWFoLCAiTVVTVCBOT1QgcmVmZXJlbmNlIGNvbmRpdGlvbmFsIG5vZGVzIiBkb2Vzbid0IHdv
cmsuDQoNClNvIGRvIHlvdSB0aGluayB0aGF0IG15IHByb3Bvc2VkIHRleHQgYWJvdXQgInRlbnRh
dGl2ZWx5IHJlbW92ZSBhbGwNCmNvbmRpdGlvbmFsIG5vZGVzIiB3b3Jrcz8NCg0KDQovbWFydGlu
DQo=


From nobody Mon Sep 28 03:33:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5201A00CF for ; Mon, 28 Sep 2015 03:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8lcsMpiJ0zX for ; Mon, 28 Sep 2015 03:33:09 -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 B4F6C1A00E3 for ; Mon, 28 Sep 2015 03:33:07 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7ED9B88D for ; Mon, 28 Sep 2015 12:33:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VCBqgYUwmb1l for ; Mon, 28 Sep 2015 12:33:05 +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 for ; Mon, 28 Sep 2015 12:33:05 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F18420055 for ; Mon, 28 Sep 2015 12:33:05 +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 RTcyI2eAMzJo; Mon, 28 Sep 2015 12:33:05 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4F7520053; Mon, 28 Sep 2015 12:33:04 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E7A743768CE0; Mon, 28 Sep 2015 12:33:03 +0200 (CEST)
Date: Mon, 28 Sep 2015 12:33:03 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20150928103303.GA96330@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] today's (2015-09-28) virtual interim on YANG 1.1 cancelled
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 10:33:10 -0000

Hi,

after consulting with Martin Bjorklund, I decided to cancel today's
YANG 1.1 virtual interim meeting. Martin has posted

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07

and it seems discussions progress on the list at this point in time
but if needed we will make use of the YANG 1.1 virtual interim
meetings that we have allocated.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 28 03:49:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A62D1A6F10 for ; Mon, 28 Sep 2015 03:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX-mhWfpa9BW for ; Mon, 28 Sep 2015 03:49:15 -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 B1B011A1B34 for ; Mon, 28 Sep 2015 03:49:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75DE08EA for ; Mon, 28 Sep 2015 12:49:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tUZ6f5RyRS1V for ; Mon, 28 Sep 2015 12:49:13 +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 for ; Mon, 28 Sep 2015 12:49:13 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99F7A20053 for ; Mon, 28 Sep 2015 12:49:13 +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 0LWsIuemr7Y3; Mon, 28 Sep 2015 12:49:13 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A198D2004E; Mon, 28 Sep 2015 12:49:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 925263768D6F; Mon, 28 Sep 2015 12:49:12 +0200 (CEST)
Date: Mon, 28 Sep 2015 12:49:12 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20150928104912.GA96374@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] WG Last Call for draft-ietf-netmod-rfc6020bis-07 (until 2015-10-12)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 10:49:17 -0000

This is a notice to start a NETMOD WG last call for the document "The
YANG 1.1 Data Modeling Language":

  https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07

Please indicate your support by Monday October 12, 2015 at 13:00 CEST.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented I-D XYZ"
  "I am implementing I-D XYZ"
  "I am considering to implement I-D XYZ"

We will track non editorial defect reports in this document:

  https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/last-call-comments.html

This is the first WG Last Call for this document. 

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 28 04:56:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F791A8A63 for ; Mon, 28 Sep 2015 04:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyr6u8xBW4jV for ; Mon, 28 Sep 2015 04:56:17 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 33BC51A8A61 for ; Mon, 28 Sep 2015 04:56:17 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id D2188C4175C1; Mon, 28 Sep 2015 13:56:15 +0200 (CEST)
To: Martin Bjorklund 
References: <560548F4.8080505@mg-soft.si> <20150925.152224.1416615960207331298.mbj@tail-f.com> <56056192.7010301@mg-soft.si> <20150928.121527.98978972249244610.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <56092ADF.50909@mg-soft.si>
Date: Mon, 28 Sep 2015 13:56:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150928.121527.98978972249244610.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 11:56:21 -0000

Martin Bjorklund je 28.9.2015 ob 12:15 napisal:
> Jernej Tuljak  wrote:
>> Martin Bjorklund je 25.9.2015 ob 15:22 napisal:
>>> Jernej Tuljak  wrote:
>>>> Ladislav Lhotka je 25.9.2015 ob 13:44 napisal:
>>>>> Jernej Tuljak  writes:
>>>>>
>>>>>> Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
>>>>>>> Jernej Tuljak  writes:
>>>>>>>
>>>>>>>> Martin Bjorklund je 24.9.2015 ob 13:54 napisal:
>>>>>>>>> Jernej Tuljak  wrote:
>>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 14:29 napisal:
>>>>>>>>>>> Jernej Tuljak  writes:
>>>>>>>>>>>
>>>>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 12:52 napisal:
>>>>>>>>>>>>>> On 23 Sep 2015, at 12:37, Jernej Tuljak 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ladislav Lhotka je 23.9.2015 ob 11:58 napisal:
>>>>>>>>>>>>>>>> On 23 Sep 2015, at 11:45, Jernej Tuljak 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Section 7.21.5., the first bullet describing the augmentation
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> does not consider that an "augment" may specify a top-level
>>>>>>>>>>>>>>>> "choice"
>>>>>>>>>>>>>>>> or a "choice"/"case" nested within a top-level "choice" as the
>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>> node. There will be no initial context node for the expression
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> such
>>>>>>>>>>>>>>>> a case.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>         leaf enable-foos {
>>>>>>>>>>>>>>>>           type boolean;
>>>>>>>>>>>>>>>>         }
>>>>>>>>>>>>>>>>         choice ch1 {
>>>>>>>>>>>>>>>>           case foo {
>>>>>>>>>>>>>>>>             choice foos {
>>>>>>>>>>>>>>>>               when "enable-foos = 'true'";
>>>>>>>>>>>>>>>>               leaf foo1 {
>>>>>>>>>>>>>>>>                 type string;
>>>>>>>>>>>>>>>>               }
>>>>>>>>>>>>>>>>               leaf foo2 {
>>>>>>>>>>>>>>>>                 type string;
>>>>>>>>>>>>>>>>               }
>>>>>>>>>>>>>>>>             }
>>>>>>>>>>>>>>>>           }
>>>>>>>>>>>>>>>>           container meh;
>>>>>>>>>>>>>>>>         }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>         augment "/ch1/foo/foos" {
>>>>>>>>>>>>>>>>           when "enable-foos = 'true'";
>>>>>>>>>>>>>>>>           leaf foo3 {
>>>>>>>>>>>>>>>>             type string;
>>>>>>>>>>>>>>>>           }
>>>>>>>>>>>>>>>>         }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OLD:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>          o If the "when" statement is a child of an "augment"
>>>>>>>>>>>>>>>>          statement,
>>>>>>>>>>>>>>>>          then
>>>>>>>>>>>>>>>>             the context node is the augment's target node in the
>>>>>>>>>>>>>>>>             data tree,
>>>>>>>>>>>>>>>>             if
>>>>>>>>>>>>>>>>             the target node is a data node.  Otherwise, the
>>>>>>>>>>>>>>>>             context
>>>>>>>>>>>>>>>>             node is
>>>>>>>>>>>>>>>>             the closest ancestor node to the target node that is
>>>>>>>>>>>>>>>>             also a data
>>>>>>>>>>>>>>>>             node.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> NEW:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>          o If the "when" statement is a child of an "augment"
>>>>>>>>>>>>>>>>          statement,
>>>>>>>>>>>>>>>>          then
>>>>>>>>>>>>>>>>             the context node is the augment's target node in the
>>>>>>>>>>>>>>>>             data tree,
>>>>>>>>>>>>>>>>             if
>>>>>>>>>>>>>>>>             the target node is a data node.  Otherwise, the
>>>>>>>>>>>>>>>>             context
>>>>>>>>>>>>>>>>             node is
>>>>>>>>>>>>>>>>             the closest ancestor node to the target node that is
>>>>>>>>>>>>>>>>             also a data
>>>>>>>>>>>>>>>>             node. If no such node exists, the context node is
>>>>>>>>>>>>>>>>             the
>>>>>>>>>>>>>>>>             root node.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Good catch, I support this change.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also regarding sec. 7.21.5, I think we agreed that a when
>>>>>>>>>>>>>>> expression
>>>>>>>>>>>>>>> must not reference nodes that are made conditional through that
>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>> statement. I can’t find this rule in the text.
>>>>>>>>>>>>>> The "no referencing the initial context node and its descendants"
>>>>>>>>>>>>>> text
>>>>>>>>>>>>>> is currently in the guidelines draft only (6087bis).
>>>>>>>>>>>>> IMO this should be a hard rule in 6020bis. Such expressions are
>>>>>>>>>>>>> seriously broken and could lead to deadlocks.
>>>>>>>>>>>> I think that was the purpose of the change in 3rd bullet. A "dummy"
>>>>>>>>>>>> node
>>>>>>>>>>>> with no value and child nodes has been introduced.
>>>>>>>>>>> Not really, the dummy node solves the problem of a non-existent
>>>>>>>>>>> context
>>>>>>>>>>> node.
>>>>>>>>>> Are you referring to "existence" in the instance document or the
>>>>>>>>>> schema tree? Why is there no need for "no children, no value dummy"
>>>>>>>>>> in
>>>>>>>>>> 1st and 2nd bullet?
>>>>>>>>> In these cases, the context node is well-defined anyway.  But I think
>>>>>>>>> that also these bullets need to have text that make sure that the
>>>>>>>>> outcome is deterministic in all cases, such as:
>>>>>>>>>
>>>>>>>>>        augement /foo {
>>>>>>>>>          when "bar > 1";
>>>>>>>>>          leaf bar { type int32; }
>>>>>>>>>        }
>>>>>>>>>
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>>        grouping foo {
>>>>>>>>>          leaf bar { type int32; }
>>>>>>>>>        }
>>>>>>>>>        container x {
>>>>>>>>>          uses foo {
>>>>>>>>>            when "bar > 1";
>>>>>>>>>          }
>>>>>>>>>        }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> So I suggest this NEW text:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         o If the "when" statement is a child of an "augment" statement,
>>>>>>>>>         then
>>>>>>>>>            the context node is the augment's target node in the data
>>>>>>>>>            tree,
>>>>>>>>>            if
>>>>>>>>>            the target node is a data node.  Otherwise, the context node
>>>>>>>>>            is
>>>>>>>>>            the closest ancestor node to the target node that is also a
>>>>>>>>>            data
>>>>>>>>>            node.  If no such node exists, the context node is the root
>>>>>>>>>            node.
>>>>>>>>>            The accessible tree is tentatively altered during the
>>>>>>>>>            processing
>>>>>>>>>            of the XPath expression by removing all instances (if any)
>>>>>>>>>            of
>>>>>>>>>            the
>>>>>>>>>            nodes added by the "augment" statement.
>>>>>>>>>
>>>>>>>>>         o  If the "when" statement is a child of a "uses", "choice", or
>>>>>>>>>            "case" statement, then the context node is the closest
>>>>>>>>>            ancestor
>>>>>>>>>            node to the "uses", "choice", or "case" node that is also a
>>>>>>>>>            data
>>>>>>>>>            node.  If no such node exists, the context node is the root
>>>>>>>>>            node.
>>>>>>>>>            The accessible tree is tentatively altered during the
>>>>>>>>>            processing
>>>>>>>>>            of the XPath expression by removing all instances (if any)
>>>>>>>>>            of
>>>>>>>>>            the
>>>>>>>>>            nodes added by the "uses", "choice", or "case" statement.
>>>>>>>>>
>>>>>>>>>         o If the "when" statement is a child of any other data
>>>>>>>>>         definition
>>>>>>>>>            statement, the accessible tree is tentatively altered during
>>>>>>>>>            the
>>>>>>>>>            processing of the XPath expression by replacing all
>>>>>>>>>            instances
>>>>>>>>>            (if
>>>>>>>>>            any) of the data node for which the "when" statement is
>>>>>>>>>            defined
>>>>>>>>>            with a single dummy node with the same name, but with no
>>>>>>>>>            value
>>>>>>>>>            and
>>>>>>>>>            no children.  The context node is this dummy node.
>>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>        container foo {
>>>>>>>>          when "child::* or child::text() or not(self::*)"; // always
>>>>>>>>          false
>>>>>>>>          leaf bar {
>>>>>>>>            type string;
>>>>>>>>          }
>>>>>>>>        }
>>>>>>> I think it would be better to clearly state that a "when" expression
>>>>>>> MUST NOT refer to nodes that are made conditional by the same "when"
>>>>>>> statement - it's similar to the rule that forbids mutual references.
>>>>>>> This would also cover all uses of "when".
>>>>>>>
>>>>>>> The above example would be really confusing if the "bar" instance is
>>>>>>> present.
>>>>>> It is true that this introduces a caveat that is bound to confuse end
>>>>>> YANG users.
>>>>>>
>>>>>>>      I also don't like the fact that "when" and "must" would give
>>>>>>> different results in this case.
>>>>>> Just to be clear, you would like this, right?
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>>        The XPath expression is conceptually evaluated in the following
>>>>>>        context, in addition to the definition inSection 6.4.1
>>>>>> :
>>>>>>
>>>>>>        o If the "when" statement is a child of an "augment" statement,
>>>>>>        then
>>>>>>           the context node is the augment's target node in the data tree,
>>>>>>           if
>>>>>>           the target node is a data node.  Otherwise, the context node is
>>>>>>           the closest ancestor node to the target node that is also a data
>>>>>>           node. If no such node exists, the context node is the root node.
>>>>>>
>>>>>>        o  If the "when" statement is a child of a "uses", "choice", or
>>>>>>           "case" statement, then the context node is the closest ancestor
>>>>>>           node to the "uses", "choice", or "case" node that is also a data
>>>>>>           node.  If no such node exists, the context node is the root
>>>>>>           node.
>>>>>>
>>>>>>        o  If the "when" statement is a child of any other data definition
>>>>>>           statement, the context node is the node in the accessible tree
>>>>>>           for
>>>>>>           which the "when" statement is defined.
>>>>>>             An XPath expression MUST NOT reference nodes that are made
>>>>>>             conditional
>>>>>>        by the "when" statement that defines it.
>>>>> Yes, plus the other two rules that are already in 6020bis:
>>>>>
>>>>> If the XPath expression references any node that also has associated
>>>>> "when" statements, these "when" expressions MUST be evaluated first.
>>>>>
>>>>> There MUST NOT be any circular dependencies in these "when"
>>>>> expressions.
>>>>>> I don't see a case in which the context node is non-existent (in the
>>>>>> schema tree) in any of the three bullets, even without "no value, no
>>>>>> descendants" dummy node.
>>>>> The third bullet is aimed at cases like this:
>>>>>
>>>>> leaf foo {
>>>>>        when "../bar > 0";
>>>>>        mandatory true;
>>>>>        ...
>>>>> }
>>>>>
>>>>> If there is no instance of "foo", a validator has to find out whether
>>>>> the "mandatory" statement applies (and the absence of "foo" is thus a
>>>>> schema error), or whether it is overruled by the "when" expression
>>>>> being
>>>>> false. But in order to be able to evaluate that expression, XPath
>>>>> requires a context node in the instance document, so we need to
>>>>> tentatively add one.
>>>> Then the dummy node text is broken all together. It instructs to
>>>> modify the accessible tree (schema)
>>> The accessible tree is not the schema, it is the instance data.
>>>
>>>> instead of instructing to
>>>> instantiate a dummy if an instance of the context node does not
>>>> exist.
>>> No, the text says *replace* any instances with the dummy instance;
>>> this ensures that the result is the same regardless of if the node
>>> exists or not.
>> Okay, the accessible tree is instantiated data nodes.
>>
>> container top {
>>      leaf foo {
>>          when "../bar > 0";
>>          mandatory true;
>>          ...
>>      }
>> }
>>
>> "top": {}
>>
>> "top": { "foo": "" }
>>
>> How is a context node ensured for the two instances, if replacing
>> something that may not exist? You would need to create a dummy if
>> there is no "foo" instance, right? The text only says "replace".
> Ok; the intention was "replace if it exists, and create otherwise"
> (i.e., "replace" as in NETCONF edit operation).   We can make this
> explicit:
>
> NEW:
>
> - If the "when" statement is a child of any other data definition
>    statement, the accessible tree is tentatively altered during the
>    processing of the XPath expression by replacing all instances of the
>    data node for which the "when" statement is defined with a single
>    dummy node with the same name, but with no value and no children.
>    If no instances of the data node exists, the dummy node is created.
>    The context node is this dummy node.
>

I agree with this.

>
>
>>>> A context node always exists in the schema tree.
>>> The context node is in the data tree.
>>>
>>>> IMO, this
>>>> needs to be fixed in order to prevent the interpretation I came up
>>>> with (and also Balazs, independently). This interpretation was clearly
>>>> not the intention.
>>>>
>>>> NEW:
>>>>
>>>>      The XPath expression is conceptually evaluated in the following
>>>>      context, in addition to the definition inSection 6.4.1
>>>>      :
>>>>
>>>>      o  If the "when" statement is a child of an "augment" statement, then
>>>>         the context node is the augment's target node in the data tree, if
>>>>         the target node is a data node.  Otherwise, the context node is
>>>>         the closest ancestor node to the target node that is also a data
>>>>         node. If no such node exists, the context node is the root node.
>>>>
>>>>      o  If the "when" statement is a child of a "uses", "choice", or
>>>>         "case" statement, then the context node is the closest ancestor
>>>>         node to the "uses", "choice", or "case" node that is also a data
>>>>         node.  If no such node exists, the context node is the root node.
>>>>
>>>>      o  If the "when" statement is a child of any other data definition
>>>>         statement, the context node is the node in the accessible tree for
>>>>         which the "when" statement is defined.
>>>>             If an instance of the context node does not exist during
>>>>             processing
>>>>      of the XPath expression, the context node is tentatively instantiated
>>>>      as a single dummy node with the same name, but with no value and no
>>>>      children, and merged into the instance of the accessible tree.
>>>>
>>>>      The result of the XPath expression is converted to a boolean value
>>>>      using the standard XPath rules.
>>>>
>>>>      An XPath expression MUST NOT reference nodes that are made conditional
>>>>      by the "when" statement that defines it.
>>>>
>>>>      If the XPath expression references any node that also has associated
>>>>      "when" statements, these "when" expressions MUST be evaluated first.
>>>>
>>>>      There MUST NOT be any circular dependencies in these "when"
>>>>      expressions.
>>>>
>>>> Something like this also takes care of Martin's example ("* = 42").
>>> How?  It is not clear to me if the '*' is legal or not.
>> It just occurred to me that it is very hard to not reference the
>> context node in a "when" XPath expression, since the context node is
>> always your initial XPath context (you always start with a node-set of
>> size 1, containing the context node).
>>
>> "../bar" says, select the parent of the context node, then select
>> "bar" child
>> "*" says, select the children of the context node that are also
>> element nodes
>>
>> So, yeah, "MUST NOT reference conditional nodes" doesn't work.
> So do you think that my proposed text about "tentatively remove all
> conditional nodes" works?

Not sure anymore:

   grouping foo {
     leaf mandatory-foo1 {
       type string;
       mandatory true;
     }
   }

   container top {
     leaf enable {
       type boolean;
     }
     container foo {
       uses foo {
         when "../enable = 'true'";
       }
     }
   }

   augment "/top/foo" {
     when "../enable = 'true'";
     leaf mandatory-foo2 {
       type string;
       mandatory true; // local augment
     }
   }

For the following instance:

"top": { "enable": "true" }

Note that the context node (container "foo") does not exist. You'd have 
to create if not exists (+remove nodes from grouping, choice, case, 
augment if any).

Jernej

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


From nobody Mon Sep 28 05:51:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2492A1A8AED for ; Mon, 28 Sep 2015 05:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Iagxp_Xgdc0 for ; Mon, 28 Sep 2015 05:51:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3441A8AD4 for ; Mon, 28 Sep 2015 05:51:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 18A9A1AE0481; Mon, 28 Sep 2015 14:51:24 +0200 (CEST)
Date: Mon, 28 Sep 2015 14:51:23 +0200 (CEST)
Message-Id: <20150928.145123.1389744663706979496.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <56092ADF.50909@mg-soft.si>
References: <56056192.7010301@mg-soft.si> <20150928.121527.98978972249244610.mbj@tail-f.com> <56092ADF.50909@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 12:51:28 -0000

Jernej Tuljak  wrote:
> Martin Bjorklund je 28.9.2015 ob 12:15 napisal:
> > Jernej Tuljak  wrote:
> >> Martin Bjorklund je 25.9.2015 ob 15:22 napisal:
> >>> Jernej Tuljak  wrote:
> >>>> Ladislav Lhotka je 25.9.2015 ob 13:44 napisal:
> >>>>> Jernej Tuljak  writes:
> >>>>>
> >>>>>> Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
> >>>>>>> Jernej Tuljak  writes:
> >>>>>>>

> >>>> A context node always exists in the schema tree.
> >>> The context node is in the data tree.
> >>>
> >>>> IMO, this
> >>>> needs to be fixed in order to prevent the interpretation I came up
> >>>> with (and also Balazs, independently). This interpretation was clearly
> >>>> not the intention.
> >>>>
> >>>> NEW:
> >>>>
> >>>>      The XPath expression is conceptually evaluated in the following
> >>>>      context, in addition to the definition inSection 6.4.1
> >>>>      :
> >>>>
> >>>>      o If the "when" statement is a child of an "augment" statement, then
> >>>>         the context node is the augment's target node in the data tree,
> >>>>         if
> >>>>         the target node is a data node.  Otherwise, the context node is
> >>>>         the closest ancestor node to the target node that is also a data
> >>>>         node. If no such node exists, the context node is the root node.
> >>>>
> >>>>      o  If the "when" statement is a child of a "uses", "choice", or
> >>>>         "case" statement, then the context node is the closest ancestor
> >>>>         node to the "uses", "choice", or "case" node that is also a data
> >>>>         node.  If no such node exists, the context node is the root node.
> >>>>
> >>>>      o  If the "when" statement is a child of any other data definition
> >>>>         statement, the context node is the node in the accessible tree
> >>>>         for
> >>>>         which the "when" statement is defined.
> >>>>             If an instance of the context node does not exist during
> >>>>             processing
> >>>>      of the XPath expression, the context node is tentatively
> >>>>      instantiated
> >>>>      as a single dummy node with the same name, but with no value and no
> >>>>      children, and merged into the instance of the accessible tree.
> >>>>
> >>>>      The result of the XPath expression is converted to a boolean value
> >>>>      using the standard XPath rules.
> >>>>
> >>>>      An XPath expression MUST NOT reference nodes that are made
> >>>>      conditional
> >>>>      by the "when" statement that defines it.
> >>>>
> >>>>      If the XPath expression references any node that also has associated
> >>>>      "when" statements, these "when" expressions MUST be evaluated first.
> >>>>
> >>>>      There MUST NOT be any circular dependencies in these "when"
> >>>>      expressions.
> >>>>
> >>>> Something like this also takes care of Martin's example ("* = 42").
> >>> How?  It is not clear to me if the '*' is legal or not.
> >> It just occurred to me that it is very hard to not reference the
> >> context node in a "when" XPath expression, since the context node is
> >> always your initial XPath context (you always start with a node-set of
> >> size 1, containing the context node).
> >>
> >> "../bar" says, select the parent of the context node, then select
> >> "bar" child
> >> "*" says, select the children of the context node that are also
> >> element nodes
> >>
> >> So, yeah, "MUST NOT reference conditional nodes" doesn't work.
> > So do you think that my proposed text about "tentatively remove all
> > conditional nodes" works?
> 
> Not sure anymore:
> 
>   grouping foo {
>     leaf mandatory-foo1 {
>       type string;
>       mandatory true;
>     }
>   }
> 
>   container top {
>     leaf enable {
>       type boolean;
>     }
>     container foo {
>       uses foo {
>         when "../enable = 'true'";
>       }
>     }
>   }
> 
>   augment "/top/foo" {
>     when "../enable = 'true'";
>     leaf mandatory-foo2 {
>       type string;
>       mandatory true; // local augment
>     }
>   }
> 
> For the following instance:
> 
> "top": { "enable": "true" }
>
> Note that the context node (container "foo") does not exist.

It actually exists, since all NP-containers exists, according to:

   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree.


/martin


From nobody Mon Sep 28 06:08:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747241A8F3B for ; Mon, 28 Sep 2015 06:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqzdlYUuSbct for ; Mon, 28 Sep 2015 06:08:45 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 825271A8F50 for ; Mon, 28 Sep 2015 06:08:45 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 43CB8C4175C1; Mon, 28 Sep 2015 15:08:44 +0200 (CEST)
To: Martin Bjorklund 
References: <56056192.7010301@mg-soft.si> <20150928.121527.98978972249244610.mbj@tail-f.com> <56092ADF.50909@mg-soft.si> <20150928.145123.1389744663706979496.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <56093BDB.2040205@mg-soft.si>
Date: Mon, 28 Sep 2015 15:08:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150928.145123.1389744663706979496.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 13:08:47 -0000

Martin Bjorklund je 28.9.2015 ob 14:51 napisal:
> Jernej Tuljak  wrote:
>> Martin Bjorklund je 28.9.2015 ob 12:15 napisal:
>>> Jernej Tuljak  wrote:
>>>> Martin Bjorklund je 25.9.2015 ob 15:22 napisal:
>>>>> Jernej Tuljak  wrote:
>>>>>> Ladislav Lhotka je 25.9.2015 ob 13:44 napisal:
>>>>>>> Jernej Tuljak  writes:
>>>>>>>
>>>>>>>> Ladislav Lhotka je 25.9.2015 ob 9:58 napisal:
>>>>>>>>> Jernej Tuljak  writes:
>>>>>>>>>
>>>>>> A context node always exists in the schema tree.
>>>>> The context node is in the data tree.
>>>>>
>>>>>> IMO, this
>>>>>> needs to be fixed in order to prevent the interpretation I came up
>>>>>> with (and also Balazs, independently). This interpretation was clearly
>>>>>> not the intention.
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>>       The XPath expression is conceptually evaluated in the following
>>>>>>       context, in addition to the definition inSection 6.4.1
>>>>>>       :
>>>>>>
>>>>>>       o If the "when" statement is a child of an "augment" statement, then
>>>>>>          the context node is the augment's target node in the data tree,
>>>>>>          if
>>>>>>          the target node is a data node.  Otherwise, the context node is
>>>>>>          the closest ancestor node to the target node that is also a data
>>>>>>          node. If no such node exists, the context node is the root node.
>>>>>>
>>>>>>       o  If the "when" statement is a child of a "uses", "choice", or
>>>>>>          "case" statement, then the context node is the closest ancestor
>>>>>>          node to the "uses", "choice", or "case" node that is also a data
>>>>>>          node.  If no such node exists, the context node is the root node.
>>>>>>
>>>>>>       o  If the "when" statement is a child of any other data definition
>>>>>>          statement, the context node is the node in the accessible tree
>>>>>>          for
>>>>>>          which the "when" statement is defined.
>>>>>>              If an instance of the context node does not exist during
>>>>>>              processing
>>>>>>       of the XPath expression, the context node is tentatively
>>>>>>       instantiated
>>>>>>       as a single dummy node with the same name, but with no value and no
>>>>>>       children, and merged into the instance of the accessible tree.
>>>>>>
>>>>>>       The result of the XPath expression is converted to a boolean value
>>>>>>       using the standard XPath rules.
>>>>>>
>>>>>>       An XPath expression MUST NOT reference nodes that are made
>>>>>>       conditional
>>>>>>       by the "when" statement that defines it.
>>>>>>
>>>>>>       If the XPath expression references any node that also has associated
>>>>>>       "when" statements, these "when" expressions MUST be evaluated first.
>>>>>>
>>>>>>       There MUST NOT be any circular dependencies in these "when"
>>>>>>       expressions.
>>>>>>
>>>>>> Something like this also takes care of Martin's example ("* = 42").
>>>>> How?  It is not clear to me if the '*' is legal or not.
>>>> It just occurred to me that it is very hard to not reference the
>>>> context node in a "when" XPath expression, since the context node is
>>>> always your initial XPath context (you always start with a node-set of
>>>> size 1, containing the context node).
>>>>
>>>> "../bar" says, select the parent of the context node, then select
>>>> "bar" child
>>>> "*" says, select the children of the context node that are also
>>>> element nodes
>>>>
>>>> So, yeah, "MUST NOT reference conditional nodes" doesn't work.
>>> So do you think that my proposed text about "tentatively remove all
>>> conditional nodes" works?
>> Not sure anymore:
>>
>>    grouping foo {
>>      leaf mandatory-foo1 {
>>        type string;
>>        mandatory true;
>>      }
>>    }
>>
>>    container top {
>>      leaf enable {
>>        type boolean;
>>      }
>>      container foo {
>>        uses foo {
>>          when "../enable = 'true'";
>>        }
>>      }
>>    }
>>
>>    augment "/top/foo" {
>>      when "../enable = 'true'";
>>      leaf mandatory-foo2 {
>>        type string;
>>        mandatory true; // local augment
>>      }
>>    }
>>
>> For the following instance:
>>
>> "top": { "enable": "true" }
>>
>> Note that the context node (container "foo") does not exist.
> It actually exists, since all NP-containers exists, according to:
>
>     If a node that exists in the accessible tree has a non-presence
>     container as a child, then the non-presence container also exists in
>     the tree.

Missed that. The text you proposed should be fine then. Takes care of 
both problems, the missing context node and references to conditional 
nodes in one go.

Jernej

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


From nobody Mon Sep 28 09:34:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2FC1ACE4F for ; Mon, 28 Sep 2015 09:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlJBPRuey2cF for ; Mon, 28 Sep 2015 09:34:25 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 26D5F1ACE46 for ; Mon, 28 Sep 2015 09:34:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RQZCR8SJjygGbwVjA1oDcRf5C71/jZOoDxoof0zfjLrX7/9XwNSld+a5nmFCeCuG; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZgbNW-00080M-IH for netmod@ietf.org; Mon, 28 Sep 2015 12:34:14 -0400
Received: from 76.254.51.191 by webmail.earthlink.net with HTTP; Mon, 28 Sep 2015 12:34:13 -0400
Message-ID: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Date: Mon, 28 Sep 2015 09:34:13 -0700 (GMT-07:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edf33c9bf33a848deb54b9c41f973d9387350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.40
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 16:34:26 -0000

Hi -

>From: Martin Bjorklund 
>Sent: Sep 28, 2015 3:15 AM
>To: jernejt@mg-soft.si
>Cc: netmod@ietf.org
>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
...
>Ok; the intention was "replace if it exists, and create otherwise"
>(i.e., "replace" as in NETCONF edit operation).   We can make this
>explicit:
>
>NEW:
>
>- If the "when" statement is a child of any other data definition
>  statement, the accessible tree is tentatively altered during the
>  processing of the XPath expression by replacing all instances of the
>  data node for which the "when" statement is defined with a single
>  dummy node with the same name, but with no value and no children.
>  If no instances of the data node exists, the dummy node is created.
>  The context node is this dummy node.

A standard should avoid prescribing a specific implementation
strategy, and should instead limit itself to describing what
the observable behaviours of the relevant interfaces must be.

Randy



From nobody Mon Sep 28 09:52:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918211ACE7B for ; Mon, 28 Sep 2015 09:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p_6tTVzEu3B for ; Mon, 28 Sep 2015 09:52:15 -0700 (PDT)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 6694E1ACE7A for ; Mon, 28 Sep 2015 09:52:15 -0700 (PDT)
Received: by laer8 with SMTP id r8so38263638lae.2 for ; Mon, 28 Sep 2015 09:52:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q7QkEB8ecycz7Gp1XyJ3tDzNRrzyaPW75SVNoQWxJm8=; b=bk/Fo35+se/BpglfWykfMcwdg7jNrzINsFI8xBs2xtjfWqrenGuvCpl+Etp8FiTvGI LALvBDvNfAMmYtHFBxKF6WdaWf0ZdivVNy36LX7A+zjn6K5TVL7N1+AEfi52bRSCFDsL RhrV002H+3qKohoY05I3SbKgbzMK+GTvkGmPertrPbd0cIOi765ffEGs/0e2/v/oPLkn CmNqr0LUQ5iKiWhEajqLolx/f61b84yze1E6tVxxld0Gufvv7Z8lQDm8Cr73mDpz+/ig w7lsbMrKee5++7CddANNL+s/ZsOUOu9sDxCFj8lHsL14Lu6w2Wa4+I81yRzpWBA58f+O cwjA==
X-Gm-Message-State: ALoCoQmwTWK/7JwZOZ9rnB00Noz0361awRMezf6cFwe1Wo+zXbcW2eOj0YMBqJwIs0FmHkq1mRuf
MIME-Version: 1.0
X-Received: by 10.112.12.165 with SMTP id z5mr5861249lbb.33.1443459133346; Mon, 28 Sep 2015 09:52:13 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 28 Sep 2015 09:52:13 -0700 (PDT)
In-Reply-To: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Date: Mon, 28 Sep 2015 09:52:13 -0700
Message-ID: 
From: Andy Bierman 
To: Randy Presuhn 
Content-Type: multipart/alternative; boundary=001a11c3b830e42ea90520d1848a
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 16:52:17 -0000

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

On Mon, Sep 28, 2015 at 9:34 AM, Randy Presuhn  wrote:

> Hi -
>
> >From: Martin Bjorklund 
> >Sent: Sep 28, 2015 3:15 AM
> >To: jernejt@mg-soft.si
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
> ...
> >Ok; the intention was "replace if it exists, and create otherwise"
> >(i.e., "replace" as in NETCONF edit operation).   We can make this
> >explicit:
> >
> >NEW:
> >
> >- If the "when" statement is a child of any other data definition
> >  statement, the accessible tree is tentatively altered during the
> >  processing of the XPath expression by replacing all instances of the
> >  data node for which the "when" statement is defined with a single
> >  dummy node with the same name, but with no value and no children.
> >  If no instances of the data node exists, the dummy node is created.
> >  The context node is this dummy node.
>
> A standard should avoid prescribing a specific implementation
> strategy, and should instead limit itself to describing what
> the observable behaviours of the relevant interfaces must be.
>
>
Agreed.

I also do not understand why one would replace any instances with a dummy
node.
The dummy node is just to test whether the context node should be created
or not.

I also found other text related to when-stmt that prescribed an evaluation
order.
This is also implementation-specific.  What if the when-stmt is affected
by 2 nodes and both are edited in the same ?  NETCONF has no
edit processing order so which one is first?  (A: ???, so YANG cannot rely
on
edit processing order).





> Randy
>

Andy


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

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




On Mon, Sep 28, 2015 at 9:34 AM, Randy Presuhn <randy_presu=
hn@mindspring.com> wrote:
H=
i -



>From: Martin Bjorklund <mbj@tail-f=
.com>

>Sent: Sep 28, 2015 3:15 AM

>To: jernejt@mg-soft.si

>Cc: netmod@ietf.org

>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
...

>Ok; the intention was "replace if it exists, and create otherwise&=
quot;

>(i.e., "replace" as in NETCONF edit operation).=C2=A0 =C2=A0W=
e can make this

>explicit:

>

>NEW:

>

>- If the "when" statement is a child of any other data defini=
tion

>=C2=A0 statement, the accessible tree is tentatively altered during the=


>=C2=A0 processing of the XPath expression by replacing all instances of=
 the

>=C2=A0 data node for which the "when" statement is defined wi=
th a single

>=C2=A0 dummy node with the same name, but with no value and no children=
.

>=C2=A0 If no instances of the data node exists, the dummy node is creat=
ed.

>=C2=A0 The context node is this dummy node.



A standard should avoid prescribing a specific implementation

strategy, and should instead limit itself to describing what

the observable behaviours of the relevant interfaces must be.



Agreed.

I als=
o do not understand why one would replace any instances with a dummy node.<=
/div>
The dummy node is just to test whether the context node should be=
 created or not.

I also found other text related t=
o when-stmt that prescribed an evaluation order.
This is also imp=
lementation-specific.=C2=A0 What if the when-stmt is affected
by =
2 nodes and both are edited in the same <edit-config>?=C2=A0 NETCONF =
has no
edit processing order so which one is first? =C2=A0(A: ???=
, so YANG cannot rely on
edit processing order).



=C2=A0

Randy

Andy
=C2=A0





_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c3b830e42ea90520d1848a--


From nobody Mon Sep 28 10:10:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E757D1ACEE9 for ; Mon, 28 Sep 2015 10:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CZjwyRzyV0p for ; Mon, 28 Sep 2015 10:10:54 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB201ACEE7 for ; Mon, 28 Sep 2015 10:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21583; q=dns/txt; s=iport; t=1443460253; x=1444669853; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6hth5u2RXMuSqgSzsitUDU0x6Bt4uzuR+o6ajpFAKes=; b=UXGjHPzMM5WLh7aaLIvDb1OdJZumNXtU7nV2Yd+T4thuqqvKJ4I15htn 80PiRPVM8P5MoYls9dvMRctdbUZ/2XwXdke+cKHpX1NatLr9EotaMpD+p WJWHNjFfaA4hHQqi/1te0ZcMqRCek15GsKf29KlHXZEgXlMUfyFv3Wj96 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ChBADCcwlW/xbLJq1egleBIWm/PQEJhS9KAoIUAQEBAQEBgQuEJAEBAQMBAQEBIEsEBxALGAkaBAMCAg8CFh8RBg0GAgEBiCIIDbZ2lEoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzhH2EQksHgmmBQwWSQoMujQ+BT4Q2gwCJeIRVg21jgkOBPz0zh1slgSEBAQE
X-IronPort-AV: E=Sophos;i="5.17,603,1437436800";  d="scan'208,217";a="607295521"
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; 28 Sep 2015 17:10:51 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8SHApT5017458; Mon, 28 Sep 2015 17:10:51 GMT
To: Andy Bierman 
References:  <5603F9C2.2000500@cisco.com> 
From: Robert Wilton 
Message-ID: <5609749D.90207@cisco.com>
Date: Mon, 28 Sep 2015 18:10:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090004020200050008010409"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 17:10:58 -0000

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

Hi Andy,


On 24/09/2015 19:22, Andy Bierman wrote:
> Hi,
>
> I find this exercise to classify servers as synchronous or 
> asynchronous mostly useless.
> We have both types of instrumentation in our server. They can be different
> on a per-node basis.  They can both take a long time or both be 
> instant, depending
> on the instrumentation code the vendor writes.
>
> In any case, the server does not know if the instrumentation has 
> finished making
> the network behave according to the new edit.  That would be new 
> functionality that
> no vendor supports at this time.  Currently servers return "ok" if the 
> edit is accepted
> into the running datastore.  There are no other semantics wrt/ 
> returning "ok".

I'm not sure whether we agree here, but as stated previously, Sec 5.1 of 
RFC 6241, implies that if the configuration is in the running datastore 
then that configuration is expected to be active on the device.

Certainly I think that some Cisco's devices behave in the spirit of this 
description.  E.g. for a normal configuration commit (via the CLI, but I 
would expect NETCONF to be the same) a configuration commit event would 
not complete unless the configuration was applied and broadly in effect 
in the system.  However, even after the config commit, there may be some 
components that are still processing parts of the config change (e.g. 
ARP subsystem after an IP address change on an interface), and some 
hardware tables may also still be in the process of being programmed.

I think that is just comes down to the definition of what "that 
configuration is expected to be active on the device" means, and how 
that relates to the definition of "applied configuration".

I've been trying to define "applied configuration" to be the same as 
"configuration is expected to be active on the device".  I.e. it is in 
the config system but isn't necessarily applied everywhere.  This 
description appears to be consistent with sec 4.2. para 1 of 
openconfig-netmod-opstate-01 but inconsistent with how "applied 
configuration" is defined in Sec 2 of openconfig-netmod-opstate-01.

The alternative definition of "applied configuration" that is being put 
forward is something along the lines of "programmed absolutely 
everywhere where it needs to be".  But this definition is in conflict 
with the behaviour described in sec 4.2. para 1 of 
openconfig-netmod-opstate-01, where after a NETCONF commit it is 
expected that applied=intended.  Further, under this definition most 
NETCONF/RESTCONF servers would likely be defined as asynchronous (at 
least for some leaves), and not many (if any) servers currently have the 
capability to report "applied configuration" as per this definition.


>
> Even something as simple as "set the log-level" could be centralized 
> or distributed.
> So every single leaf is a separate case and every single 
> implementation of every leaf
> is a separate case.  It is completely implementation-dependent.  One 
> platform may
> take a long time and another from the same vendor may not, for the 
> exact same leaf.
>
> So instead of talking about the entire server being sync or async, we 
> need to
> talk about a specific implementation of a specific leaf, and not try 
> to generalize
> and simplify the problem.

But from a client perspective, I'm not quite sure whether they would 
want to optimise for this case.  E.g. if some of the configuration has 
been applied immediately and some will be handled asynchronously then I 
would imagine that a client might just treat that equivalently to it all 
being handled asynchronously, and hence poll for the applied config leaves.

Hence your suggestion feels like an optimization to me, a nice to have, 
but I don't currently see that it is required.

In summary, I think that the two main issues that need to be resolved 
w.r.t to the requirements, which are:
(1) What does applied-config actually mean?

(2) What does it mean when an existing NETCONF/RESTCONF commit completes 
(which I see as depending on the definition of applied-config)?

I expect that the rest of the requirements would probably logically 
follow on from these.  It would seem to be beneficial if we could get 
these nailed down before the next meeting on Thursday if at all possible.

Rob


>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton  > wrote:
>
>     Hi Kent,
>
>     On 23/09/2015 17:15, Kent Watsen wrote:
>>
>>     Jonathan Hansford writes: The requirements talk about both
>>     synchronous and asynchronous systems (1(D), 3, 3(A)) but really
>>     only address the behaviour for asynchronous systems. Would it not
>>     be worth clarifying the relationship between the intended and
>>     applied configurations for synchronous systems (i.e. they are the
>>     same), hence there is no need for synchronous requirements
>>     equivalent to 1(D) and 3(A)?
>>
>>     Ultimately, I think we need normative text in the "Terminology
>>     Section" for a "synchronous system" and "asynchronous system". 
>>     Would someone care to take a stab providing these two definitions?
>
>     First stab only, probably needs some tweaking ...
>
>     I find that the term "system" is a bit ambiguous in this context. 
>     It is talking about the NMS, the server, or both together?
>
>     Anyway, I've tried to define them relative to the configuration
>     operations being performed.
>
>     Synchronous configuration operation - A configuration request that
>     the server applies synchronously with respect to the client
>     request.  Before the server replies back to the client indicating
>     the success or failure of the operation it MUST semantically
>     validate the contents of the request and update the intended
>     configuration of the target datastore.  If the request is to the
>     running datastore then the configuration change MUST also be
>     applied in the system before the server replies back to the
>     client.  The reply to the client indicates whether there are any
>     semantic errors or system errors from applying the configuration
>     change.
>
>     Asynchronous configuration operation - A configuration request
>     that the server applies asynchronously with respect to the client
>     request.  Before the server replies back to the client indicating
>     the success or failure of the operation it MUST semantically
>     validate the contents of the request and update the intended
>     configuration of the target datastore.  If the request is to the
>     running datastore then the configuration change is applied to the
>     system after the server has replied back to the client. The reply
>     to the client only indicates whether there are any semantic errors
>     in the configuration change.
>
>     Synchronous system - NETCONF/RESTCONF client/server interactions
>     that processes all configuration operations as synchronous
>     configuration operations.
>
>     Asynchronous system - NETCONF/RESTCONF client/server interactions
>     that processes all configuration operations as asynchronous
>     configuration operations.
>
>     Thanks,
>     Rob
>
>
>>
>>
>>     PS: please Reply-All to this thread, rather than post comments on
>>     the GitHub issue tracker.
>>
>>     Thanks,
>>     Kent
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     netmod@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>


--------------090004020200050008010409
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    

    
On 24/09/2015 19:22, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I find this exercise to classify servers as synchronous or
          asynchronous mostly useless.

        
We have both types of instrumentation in our server. They
          can be different

        
on a per-node basis.  They can both take a long time or
          both be instant, depending

        
on the instrumentation code the vendor writes.

        


        

        
In any case, the server does not know if the
          instrumentation has finished making

        
the network behave according to the new edit.  That would
          be new functionality that

        
no vendor supports at this time.  Currently servers return
          "ok" if the edit is accepted

        
into the running datastore.  There are no other semantics
          wrt/ returning "ok".

      

    

    

    I'm not sure whether we agree here, but as stated previously, Sec
    5.1 of RFC 6241, implies that if the configuration is in the running
    datastore then that configuration is expected to be active on the
    device.

    

    Certainly I think that some Cisco's devices behave in the spirit of
    this description.  E.g. for a normal configuration commit (via the
    CLI, but I would expect NETCONF to be the same) a configuration
    commit event would not complete unless the configuration was applied
    and broadly in effect in the system.  However, even after the config
    commit, there may be some components that are still processing parts
    of the config change (e.g. ARP subsystem after an IP address change
    on an interface), and some hardware tables may also still be in the
    process of being programmed.

    

    I think that is just comes down to the definition of what "that
    configuration is expected to be active on the device" means, and how
    that relates to the definition of "applied configuration".

    

    I've been trying to define "applied configuration" to be the same as
    "configuration is expected to be active on the device".  I.e. it is
    in the config system but isn't necessarily applied everywhere.  This
    description appears to be consistent with sec 4.2. para 1 of
    openconfig-netmod-opstate-01 but inconsistent with how "applied
    configuration" is defined in Sec 2 of openconfig-netmod-opstate-01.

    

    The alternative definition of "applied configuration" that is being
    put forward is something along the lines of "programmed absolutely
    everywhere where it needs to be".  But this definition is in
    conflict with the behaviour described in sec 4.2. para 1 of
    openconfig-netmod-opstate-01, where after a NETCONF commit it is
    expected that applied=intended.  Further, under this definition most
    NETCONF/RESTCONF servers would likely be defined as asynchronous (at
    least for some leaves), and not many (if any) servers currently have
    the capability to report "applied configuration" as per this
    definition.

    

    

    

      

        


        

        
Even something as simple as "set the log-level" could be
          centralized or distributed.

        
So every single leaf is a separate case and every single
          implementation of every leaf

        
is a separate case.  It is completely
          implementation-dependent.  One platform may

        
take a long time and another from the same vendor may not,
          for the exact same leaf.

        


        

        
So instead of talking about the entire server being sync or
          async, we need to

        
talk about a specific implementation of a specific leaf,
          and not try to generalize

        
and simplify the problem.

      

    

    

    But from a client perspective, I'm not quite sure whether they would
    want to optimise for this case.  E.g. if some of the configuration
    has been applied immediately and some will be handled asynchronously
    then I would imagine that a client might just treat that
    equivalently to it all being handled asynchronously, and hence poll
    for the applied config leaves.

    

    Hence your suggestion feels like an optimization to me, a nice to
    have, but I don't currently see that it is required.

    

    In summary, I think that the two main issues that need to be
    resolved w.r.t to the requirements, which are:

    (1) What does applied-config actually mean?

    

    (2) What does it mean when an existing NETCONF/RESTCONF commit
    completes (which I see as depending on the definition of
    applied-config)?

    

    I expect that the rest of the requirements would probably logically
    follow on from these.  It would seem to be beneficial if we could
    get these nailed down before the next meeting on Thursday if at all
    possible.

    

    Rob

    

    

    

      

        


        

        


        

        
Andy

        


        

        


        

        


        

        


        

        


        

        


        

      

      


        
On Thu, Sep 24, 2015 at 6:25 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Kent,

              

              
On 23/09/2015 17:15, Kent Watsen wrote:

              

              

                

                  

                    

                  

                  
Jonathan Hansford
                      writes: The requirements talk about both
                      synchronous and asynchronous systems (1(D), 3,
                      3(A)) but really only address the behaviour for
                      asynchronous systems. Would it not be worth
                      clarifying the relationship between the intended
                      and applied configurations for synchronous systems
                      (i.e. they are the same), hence there is no need
                      for synchronous requirements equivalent to 1(D)
                      and 3(A)?

                  


                  

                  
Ultimately, I think we need normative text in the
                    "Terminology Section" for a "synchronous system" and
                    "asynchronous system".  Would someone care to take a
                    stab providing these two definitions?

                

              

              

              First stab only, probably needs some tweaking ...

              

              I find that the term "system" is a bit ambiguous in this
              context.  It is talking about the NMS, the server, or both
              together?

              

              Anyway, I've tried to define them relative to the
              configuration operations being performed.

              

              Synchronous configuration operation - A configuration
              request that the server applies synchronously with respect
              to the client request.  Before the server replies back to
              the client indicating the success or failure of the
              operation it MUST semantically validate the contents of
              the request and update the intended configuration of the
              target datastore.  If the request is to the running
              datastore then the configuration change MUST also be
              applied in the system before the server replies back to
              the client.  The reply to the client indicates whether
              there are any semantic errors or system errors from
              applying the configuration change.

              

              Asynchronous configuration operation - A configuration
              request that the server applies asynchronously with
              respect to the client request.  Before the server replies
              back to the client indicating the success or failure of
              the operation it MUST semantically validate the contents
              of the request and update the intended configuration of
              the target datastore.  If the request is to the running
              datastore then the configuration change is applied to the
              system after the server has replied back to the client. 
              The reply to the client only indicates whether there are
              any semantic errors in the configuration change.

              

              Synchronous system - NETCONF/RESTCONF client/server
              interactions that processes all configuration operations
              as synchronous configuration operations.

              

              Asynchronous system - NETCONF/RESTCONF client/server
              interactions that processes all configuration operations
              as asynchronous configuration operations.

              

              Thanks,

              Rob

              

              

              

                

                

                

                  


                    

                  


                    

                  
PS: please
                      Reply-All to this thread, rather than post
                      comments on the GitHub
                      issue tracker.

                  

                    

                  

                

                

                  Thanks,

                

                  Kent

                

                  

                

                

                

                

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


              

              

            

            

            _______________________________________________

            netmod mailing list

            netmod@ietf.org

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

            

          

        

        

      

    

    

  


--------------090004020200050008010409--


From nobody Mon Sep 28 10:17:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69911AD06D for ; Mon, 28 Sep 2015 10:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtbg8GJiYZrw for ; Mon, 28 Sep 2015 10:17:37 -0700 (PDT)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 34A2F1ACECB for ; Mon, 28 Sep 2015 10:17:37 -0700 (PDT)
Received: by labzv5 with SMTP id zv5so23185552lab.1 for ; Mon, 28 Sep 2015 10:17:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XhQigfB9GIT4VQE9+ydAJaaQgQCd5x+mDnjyWaU+674=; b=ad5EBrgEMjbtZiD/VQ6PoH94ThkAikrhGkdqYeQfY9moF0X5l7zLfGW9tDJltzHmnD 3+DxwIAEkJVPmhLMqqBmLq7RkICrmk46v8wqC9cvxNDyN2YdyuDnafxsaRZh+wUmc638 lI1P39faZvPhsVnOkdys+71IMl6lSo6Em3FepNIrUdDMtagJldISKeTvI2tgp5SzioXN uMUwINCiYh4FTM2/9k6it2KIVN5Zboby2zNA0c/YOXV0qWAJ/MkLoqiVNeoc8ajrzeW7 OzkREyaNORgdLDBksg3NK2EB24QQ5snzLV69qE1Ce5LxdA8cZxIFcvI0PtBV0veA0a1x i4Mw==
X-Gm-Message-State: ALoCoQmqC8Lhcf7Y9tcglmV1oPnADbLEzWdyg/6QMDf9VVSa8rIJT66j7mL4DIHMywFCfjP7ePH6
MIME-Version: 1.0
X-Received: by 10.25.145.132 with SMTP id t126mr3810639lfd.88.1443460655111; Mon, 28 Sep 2015 10:17:35 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 28 Sep 2015 10:17:35 -0700 (PDT)
In-Reply-To: <5609749D.90207@cisco.com>
References:  <5603F9C2.2000500@cisco.com>  <5609749D.90207@cisco.com>
Date: Mon, 28 Sep 2015 10:17:35 -0700
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a114038929889b10520d1dfce
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 17:17:41 -0000

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

On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton  wrote:

> Hi Andy,
>
>
> On 24/09/2015 19:22, Andy Bierman wrote:
>
> Hi,
>
> I find this exercise to classify servers as synchronous or asynchronous
> mostly useless.
> We have both types of instrumentation in our server. They can be different
> on a per-node basis.  They can both take a long time or both be instant,
> depending
> on the instrumentation code the vendor writes.
>
> In any case, the server does not know if the instrumentation has finished
> making
> the network behave according to the new edit.  That would be new
> functionality that
> no vendor supports at this time.  Currently servers return "ok" if the
> edit is accepted
> into the running datastore.  There are no other semantics wrt/ returning
> "ok".
>
>
> I'm not sure whether we agree here, but as stated previously, Sec 5.1 of
> RFC 6241, implies that if the configuration is in the running datastore
> then that configuration is expected to be active on the device.
>
>
I do not agree at all that the running datastore means anything other
than the intended confg.   A new operation is needed to retrieve
the active config vs. the intended config.



Andy

Certainly I think that some Cisco's devices behave in the spirit of this
> description.  E.g. for a normal configuration commit (via the CLI, but I
> would expect NETCONF to be the same) a configuration commit event would not
> complete unless the configuration was applied and broadly in effect in the
> system.  However, even after the config commit, there may be some
> components that are still processing parts of the config change (e.g. ARP
> subsystem after an IP address change on an interface), and some hardware
> tables may also still be in the process of being programmed.
>
> I think that is just comes down to the definition of what "that
> configuration is expected to be active on the device" means, and how that
> relates to the definition of "applied configuration".
>
> I've been trying to define "applied configuration" to be the same as
> "configuration is expected to be active on the device".  I.e. it is in the
> config system but isn't necessarily applied everywhere.  This description
> appears to be consistent with sec 4.2. para 1 of
> openconfig-netmod-opstate-01 but inconsistent with how "applied
> configuration" is defined in Sec 2 of openconfig-netmod-opstate-01.
>
> The alternative definition of "applied configuration" that is being put
> forward is something along the lines of "programmed absolutely everywhere
> where it needs to be".  But this definition is in conflict with the
> behaviour described in sec 4.2. para 1 of openconfig-netmod-opstate-01,
> where after a NETCONF commit it is expected that applied=intended.
> Further, under this definition most NETCONF/RESTCONF servers would likely
> be defined as asynchronous (at least for some leaves), and not many (if
> any) servers currently have the capability to report "applied
> configuration" as per this definition.
>
>
>
> Even something as simple as "set the log-level" could be centralized or
> distributed.
> So every single leaf is a separate case and every single implementation of
> every leaf
> is a separate case.  It is completely implementation-dependent.  One
> platform may
> take a long time and another from the same vendor may not, for the exact
> same leaf.
>
> So instead of talking about the entire server being sync or async, we need
> to
> talk about a specific implementation of a specific leaf, and not try to
> generalize
> and simplify the problem.
>
>
> But from a client perspective, I'm not quite sure whether they would want
> to optimise for this case.  E.g. if some of the configuration has been
> applied immediately and some will be handled asynchronously then I would
> imagine that a client might just treat that equivalently to it all being
> handled asynchronously, and hence poll for the applied config leaves.
>
> Hence your suggestion feels like an optimization to me, a nice to have,
> but I don't currently see that it is required.
>
> In summary, I think that the two main issues that need to be resolved
> w.r.t to the requirements, which are:
> (1) What does applied-config actually mean?
>
> (2) What does it mean when an existing NETCONF/RESTCONF commit completes
> (which I see as depending on the definition of applied-config)?
>
> I expect that the rest of the requirements would probably logically follow
> on from these.  It would seem to be beneficial if we could get these nailed
> down before the next meeting on Thursday if at all possible.
>
> Rob
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton  wrote:
>
>> Hi Kent,
>>
>> On 23/09/2015 17:15, Kent Watsen wrote:
>>
>>
>> Jonathan Hansford writes: The requirements talk about both synchronous
>> and asynchronous systems (1(D), 3, 3(A)) but really only address the
>> behaviour for asynchronous systems. Would it not be worth clarifying the
>> relationship between the intended and applied configurations for
>> synchronous systems (i.e. they are the same), hence there is no need for
>> synchronous requirements equivalent to 1(D) and 3(A)?
>>
>> Ultimately, I think we need normative text in the "Terminology Section"
>> for a "synchronous system" and "asynchronous system".  Would someone care
>> to take a stab providing these two definitions?
>>
>>
>> First stab only, probably needs some tweaking ...
>>
>> I find that the term "system" is a bit ambiguous in this context.  It is
>> talking about the NMS, the server, or both together?
>>
>> Anyway, I've tried to define them relative to the configuration
>> operations being performed.
>>
>> Synchronous configuration operation - A configuration request that the
>> server applies synchronously with respect to the client request.  Before
>> the server replies back to the client indicating the success or failure of
>> the operation it MUST semantically validate the contents of the request and
>> update the intended configuration of the target datastore.  If the request
>> is to the running datastore then the configuration change MUST also be
>> applied in the system before the server replies back to the client.  The
>> reply to the client indicates whether there are any semantic errors or
>> system errors from applying the configuration change.
>>
>> Asynchronous configuration operation - A configuration request that the
>> server applies asynchronously with respect to the client request.  Before
>> the server replies back to the client indicating the success or failure of
>> the operation it MUST semantically validate the contents of the request and
>> update the intended configuration of the target datastore.  If the request
>> is to the running datastore then the configuration change is applied to the
>> system after the server has replied back to the client.  The reply to the
>> client only indicates whether there are any semantic errors in the
>> configuration change.
>>
>> Synchronous system - NETCONF/RESTCONF client/server interactions that
>> processes all configuration operations as synchronous configuration
>> operations.
>>
>> Asynchronous system - NETCONF/RESTCONF client/server interactions that
>> processes all configuration operations as asynchronous configuration
>> operations.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> PS: please Reply-All to this thread, rather than post comments on the GitHub
>> issue tracker.
>>
>> Thanks,
>> Kent
>>
>>
>>
>> _______________________________________________
>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>

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




On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton <<=
a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com=
> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    

    
On 24/09/2015 19:22, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I find this exercise to classify servers as synchronous or
          asynchronous mostly useless.

        
We have both types of instrumentation in our server. They
          can be different

        
on a per-node basis.=C2=A0 They can both take a long time or
          both be instant, depending

        
on the instrumentation code the vendor writes.

        


        

        
In any case, the server does not know if the
          instrumentation has finished making

        
the network behave according to the new edit.=C2=A0 That would
          be new functionality that

        
no vendor supports at this time.=C2=A0 Currently servers retur=
n
          "ok" if the edit is accepted

        
into the running datastore.=C2=A0 There are no other semantics
          wrt/ returning "ok".

      

    

    

    I'm not sure whether we agree here, but as stated previously, Sec
    5.1 of RFC 6241, implies that if the configuration is in the running
    datastore then that configuration is expected to be active on the
    device.

    

I do not agree at all that t=
he running datastore means anything other
than the intended confg=
. =C2=A0 A new operation is needed to retrieve
the active config =
vs. the intended config.



=

Andy


    Certainly I think that some Cisco's devices behave in the spirit of
    this description.=C2=A0 E.g. for a normal configuration commit (via the
    CLI, but I would expect NETCONF to be the same) a configuration
    commit event would not complete unless the configuration was applied
    and broadly in effect in the system.=C2=A0 However, even after the conf=
ig
    commit, there may be some components that are still processing parts
    of the config change (e.g. ARP subsystem after an IP address change
    on an interface), and some hardware tables may also still be in the
    process of being programmed.

    

    I think that is just comes down to the definition of what "that
    configuration is expected to be active on the device" means, and h=
ow
    that relates to the definition of "applied configuration".
    

    I've been trying to define "applied configuration" to be =
the same as
    "configuration is expected to be active on the device".=C2=A0=
 I.e. it is
    in the config system but isn't necessarily applied everywhere.=C2=
=A0 This
    description appears to be consistent with sec 4.2. para 1 of
    openconfig-netmod-opstate-01 but inconsistent with how "applied
    configuration" is defined in Sec 2 of openconfig-netmod-opstate-01=
.

    

    The alternative definition of "applied configuration" that is=
 being
    put forward is something along the lines of "programmed absolutely
    everywhere where it needs to be".=C2=A0 But this definition is in
    conflict with the behaviour described in sec 4.2. para 1 of
    openconfig-netmod-opstate-01, where after a NETCONF commit it is
    expected that applied=3Dintended.=C2=A0 Further, under this definition =
most
    NETCONF/RESTCONF servers would likely be defined as asynchronous (at
    least for some leaves), and not many (if any) servers currently have
    the capability to report "applied configuration" as per this
    definition.

    

    

    

      

        


        

        
Even something as simple as "set the log-level" coul=
d be
          centralized or distributed.

        
So every single leaf is a separate case and every single
          implementation of every leaf

        
is a separate case.=C2=A0 It is completely
          implementation-dependent.=C2=A0 One platform may

        
take a long time and another from the same vendor may not,
          for the exact same leaf.

        


        

        
So instead of talking about the entire server being sync or
          async, we need to

        
talk about a specific implementation of a specific leaf,
          and not try to generalize

        
and simplify the problem.

      

    

    

    But from a client perspective, I'm not quite sure whether they woul=
d
    want to optimise for this case.=C2=A0 E.g. if some of the configuration
    has been applied immediately and some will be handled asynchronously
    then I would imagine that a client might just treat that
    equivalently to it all being handled asynchronously, and hence poll
    for the applied config leaves.

    

    Hence your suggestion feels like an optimization to me, a nice to
    have, but I don't currently see that it is required.

    

    In summary, I think that the two main issues that need to be
    resolved w.r.t to the requirements, which are:

    (1) What does applied-config actually mean?

    

    (2) What does it mean when an existing NETCONF/RESTCONF commit
    completes (which I see as depending on the definition of
    applied-config)?

    

    I expect that the rest of the requirements would probably logically
    follow on from these.=C2=A0 It would seem to be beneficial if we could
    get these nailed down before the next meeting on Thursday if at all
    possible.

    

    Rob

    

    

    

      

        


        

        


        

        
Andy

        


        

        


        

        


        

        


        

        


        

        


        

      

      


        
On Thu, Sep 24, 2015 at 6:25 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Kent,

              

              
On 23/09/2015 17:15, Kent Watsen wrote:

              

              

                

                  

                    

                  

                  
Jonathan Hansford
                      writes: The requirements talk about both
                      synchronous and asynchronous systems (1(D), 3,
                      3(A)) but really only address the behaviour for
                      asynchronous systems. Would it not be worth
                      clarifying the relationship between the intended
                      and applied configurations for synchronous systems
                      (i.e. they are the same), hence there is no need
                      for synchronous requirements equivalent to 1(D)
                      and 3(A)?

                  


                  

                  
Ultimately, I think we need normative text in the
                    "Terminology Section" for a "synchronous=
 system" and
                    "asynchronous system".=C2=A0 Would someone ca=
re to take a
                    stab providing these two definitions?

                

              

              

              First stab only, probably needs some tweaking ...

              

              I find that the term "system" is a bit ambiguous in=
 this
              context.=C2=A0 It is talking about the NMS, the server, or bo=
th
              together?

              

              Anyway, I've tried to define them relative to the
              configuration operations being performed.

              

              Synchronous configuration operation - A configuration
              request that the server applies synchronously with respect
              to the client request.=C2=A0 Before the server replies back t=
o
              the client indicating the success or failure of the
              operation it MUST semantically validate the contents of
              the request and update the intended configuration of the
              target datastore.=C2=A0 If the request is to the running
              datastore then the configuration change MUST also be
              applied in the system before the server replies back to
              the client.=C2=A0 The reply to the client indicates whether
              there are any semantic errors or system errors from
              applying the configuration change.

              

              Asynchronous configuration operation - A configuration
              request that the server applies asynchronously with
              respect to the client request.=C2=A0 Before the server replie=
s
              back to the client indicating the success or failure of
              the operation it MUST semantically validate the contents
              of the request and update the intended configuration of
              the target datastore.=C2=A0 If the request is to the running
              datastore then the configuration change is applied to the
              system after the server has replied back to the client.=C2=A0
              The reply to the client only indicates whether there are
              any semantic errors in the configuration change.

              

              Synchronous system - NETCONF/RESTCONF client/server
              interactions that processes all configuration operations
              as synchronous configuration operations.

              

              Asynchronous system - NETCONF/RESTCONF client/server
              interactions that processes all configuration operations
              as asynchronous configuration operations.

              

              Thanks,

              Rob

              

              

              

                

                

                

                  


                    

                  


                    

                  
PS: please
                      Reply-All to this thread, rather than post
                      comments on the=C2=A0GitHub
                      issue tracker.

                  

                    

                  

                

                

                  Thanks,

                

                  Kent

                

                  

                

                

                

                

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


              

              

            

            

            _______________________________________________

            netmod mailing list

            netmod@iet=
f.org

            https://www.ietf.org/mailman/listinfo/netmod=


            

          

        

        

      

    

    

  






--001a114038929889b10520d1dfce--


From nobody Mon Sep 28 14:21:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9923A1B33D9; Mon, 28 Sep 2015 14:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwdonuF2bH3K; Mon, 28 Sep 2015 14:21:39 -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 D13EF1B33C9; Mon, 28 Sep 2015 14:21:39 -0700 (PDT)
Received: by pacfv12 with SMTP id fv12so188511802pac.2; Mon, 28 Sep 2015 14:21:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N3cDAGAP7uyrS+AMd/So+6AM2F0bvwtyTkvJxS03oPg=; b=fDZveFhWNAAk2VyD6gQeMmj/a202tyeqRLUfHSeD/UasWU40J4+RgcgqTGB0DacAec Ut04wiTRyjr8zYLkq2UyAifg+7Z07V42G9zmAem6UYHL161u4ZXyLwZcou9V20rbGgPR FzS2GaB262ojGqa6Rwy1CsyHNVn4RI3dCF4pwwbIEHjPllwIeWwDUpG+uIczpxnEZ0Fq Fg9Fwjpvr7oByZko6IzGH+kTpJzQkTl90t539cHQG4qRf/BRyjokIcB7wv2r8kgssQHv iKs+fU/sCGTKpkp2gWYnbFMt/Q1f5/nh1KgC4A4FUFKcYOgf+4WIHqcm2biBLYLf1bd3 8EdA==
X-Received: by 10.66.241.40 with SMTP id wf8mr17035252pac.157.1443475299446; Mon, 28 Sep 2015 14:21:39 -0700 (PDT)
Received: from ?IPv6:2001:420:302:1270:4d23:9d4f:ee7c:225f? ([2001:420:302:1270:4d23:9d4f:ee7c:225f]) by smtp.gmail.com with ESMTPSA id zc4sm21203467pbb.24.2015.09.28.14.21.38 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 14:21:38 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mahesh Jethanandani 
In-Reply-To: <20150922190308.GB99737@elstar.local>
Date: Mon, 28 Sep 2015 14:22:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2633B208-C180-4F96-9B50-C354BFAF3C5E@gmail.com>
References:  <20150922142615.GC99134@elstar.local>  <20150922190308.GB99737@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "netconf@ietf.org" , NETMOD Working Group 
Subject: Re: [netmod] [Netconf] restconf and namespaces and unique module names.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Sep 2015 21:21:41 -0000

[Cross posting to netmod mailing list since this discussion affects =
YANG]

> On Sep 22, 2015, at 12:03 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Sep 22, 2015 at 05:25:04PM +0000, Kent Watsen wrote:
>>>=20
>>> RFC 6020:
>>>=20
>>>  The names of all standard modules and submodules MUST be unique.
>>>  Developers of enterprise modules are RECOMMENDED to choose names =
for
>>>  their modules that will have a low probability of colliding with
>>>  standard or other enterprise modules, e.g., by using the enterprise
>>>  or organization name as a prefix for the module name.
>>>=20
>>> Apparently, both module names in the example violate this. Note that
>>> module names are used to resolve imports and hence they better are
>>> unique. For the IETF, we can manage that via the IANA registry. For
>>> the other modules, there is a clear recommendation.
>>=20
>>=20
>> OK, that's fair, but it doesn't seem to be a followed often outside =
of the
>> IETF.
>>=20
>> For instance,
>>=20
>>  - ETSI NFV-MANO has module names like "nsd", "vnfd" and "vld"
>>  - Open Config has module names beginning with "bgp-" and "mpls-"
>>  - IEEE has module names like =E2=80=9Cethernet"

IEEE models did that because they did not have a namespace reserved. As =
IEEE goes through the motions of registering for a URN namespace, all =
IEEE standard models will be prefixed with ieee-.

>>  - ODL has some module names like "config" and "flow-errors"
>=20
> Because people often do not read specifications and if tools do not
> complain they assume everything is fine. The YANG spec has clear
> words, there is text in the guidelines. We can write more text and it
> will likely not help. Perhaps tutorials need to stress these points.
>=20
>> BTW, this sentence in 6087bis may be overreaching "All published =
module
>> names MUST be unique." - as it is only enforceable within the scope =
of a
>> specific registrar like IANA.  Perhaps replace MUST with SHOULD, or =
limit
>> the scope to IANA-published modules?
>=20
> IANA does not publish modules. The IETF can enforce unique module
> names.  I would hope that once the IEEE _publishes_ YANG modules they
> also find ways to enforce unique module names. Perhaps ODL, ETSI, OC
> etc will eventually get this right as well.

That is the plan for IEEE and MEF, where we are working on getting them =
a URN namespace and have them manage uniqueness between the models they =
produce.

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Tue Sep 29 00:18:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6C1A1B7D for ; Tue, 29 Sep 2015 00:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prNc9rkIxVO5 for ; Tue, 29 Sep 2015 00:18:42 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFDC1A1B7C for ; Tue, 29 Sep 2015 00:18:42 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 216831AE009B; Tue, 29 Sep 2015 09:18:41 +0200 (CEST)
Date: Tue, 29 Sep 2015 09:18:40 +0200 (CEST)
Message-Id: <20150929.091840.2002963607336702049.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 07:18:44 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Martin Bjorklund 
> >Sent: Sep 28, 2015 3:15 AM
> >To: jernejt@mg-soft.si
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
> ...
> >Ok; the intention was "replace if it exists, and create otherwise"
> >(i.e., "replace" as in NETCONF edit operation).   We can make this
> >explicit:
> >
> >NEW:
> >
> >- If the "when" statement is a child of any other data definition
> >  statement, the accessible tree is tentatively altered during the
> >  processing of the XPath expression by replacing all instances of the
> >  data node for which the "when" statement is defined with a single
> >  dummy node with the same name, but with no value and no children.
> >  If no instances of the data node exists, the dummy node is created.
> >  The context node is this dummy node.
> 
> A standard should avoid prescribing a specific implementation
> strategy, and should instead limit itself to describing what
> the observable behaviours of the relevant interfaces must be.

Absolutely!  This text is not supposed to prescribe anything for the
implementation. (*) Maybe it needs to be rephrased.  Do you have any
suggestions?


(*) FWIW, in our implementation we do not actually delete anything;
but it behaves as if it was deleted.


/martin


From nobody Tue Sep 29 00:57:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D11A1EF6 for ; Tue, 29 Sep 2015 00:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70BPxHj13EAP for ; Tue, 29 Sep 2015 00:57:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 77D141A1EEC for ; Tue, 29 Sep 2015 00:57:45 -0700 (PDT)
Received: from localhost (unknown [173.38.220.54]) by mail.tail-f.com (Postfix) with ESMTPSA id 116AB1AE009B; Tue, 29 Sep 2015 09:57:44 +0200 (CEST)
Date: Tue, 29 Sep 2015 09:57:43 +0200 (CEST)
Message-Id: <20150929.095743.1500141054422662540.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 07:57:47 -0000

Andy Bierman  wrote:
> On Mon, Sep 28, 2015 at 9:34 AM, Randy Presuhn  > wrote:
> 
> > Hi -
> >
> > >From: Martin Bjorklund 
> > >Sent: Sep 28, 2015 3:15 AM
> > >To: jernejt@mg-soft.si
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
> > ...
> > >Ok; the intention was "replace if it exists, and create otherwise"
> > >(i.e., "replace" as in NETCONF edit operation).   We can make this
> > >explicit:
> > >
> > >NEW:
> > >
> > >- If the "when" statement is a child of any other data definition
> > >  statement, the accessible tree is tentatively altered during the
> > >  processing of the XPath expression by replacing all instances of the
> > >  data node for which the "when" statement is defined with a single
> > >  dummy node with the same name, but with no value and no children.
> > >  If no instances of the data node exists, the dummy node is created.
> > >  The context node is this dummy node.
> >
> > A standard should avoid prescribing a specific implementation
> > strategy, and should instead limit itself to describing what
> > the observable behaviours of the relevant interfaces must be.
> >
> >
> Agreed.
> 
> I also do not understand why one would replace any instances with a dummy
> node.

Consider this:

  container foo {
    when "not(bar = 42)";
    leaf bar { type int32; }
  }

Suppose the db is empty.  The when expression now evaluates to true,
and you can configure bar.  If you now set bar to 42, the when
expression evaluates to false so foo/bar should be deleted; but then
the when expression evaluates to true so it should exist.

There are two ways we can handle this:

1) Try to make sure the result is deterministic; this is what the
   proposed text does.

2) Accept this behavior, since it only happens if people write such
   (bad) expressions.  In this case we should just create the dummy
   node if the context node doesn't exist, and remove the text about
   replace.
   
> The dummy node is just to test whether the context node should be created
> or not.
> 
> I also found other text related to when-stmt that prescribed an evaluation
> order.
> This is also implementation-specific.  What if the when-stmt is affected
> by 2 nodes and both are edited in the same ?  NETCONF has no
> edit processing order so which one is first?  (A: ???, so YANG cannot rely
> on
> edit processing order).

AFAIK there is no text that relies on any specific NETCONF edit-config
processing order.  If there is, let me know.


/martin


From nobody Tue Sep 29 01:34:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05AF1A1BF8 for ; Tue, 29 Sep 2015 01:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rq2ogwkuoKz for ; Tue, 29 Sep 2015 01:34:08 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 085F41A6EE9 for ; Tue, 29 Sep 2015 01:28:27 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 505D01CC009D; Tue, 29 Sep 2015 10:28:36 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
In-Reply-To: <20150928065504.GA95250@elstar.local>
References: <11463602.1442343683711.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local>  <20150923131119.GA1945@elstar.local> <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz> <20150928065504.GA95250@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 29 Sep 2015 10:28:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 08:34:10 -0000

Juergen Schoenwaelder  writes:

> On Wed, Sep 23, 2015 at 03:46:27PM +0200, Ladislav Lhotka wrote:
>>=20
>> > On 23 Sep 2015, at 15:11, Juergen Schoenwaelder  wrote:
>> >=20
>> > On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote:
>> >>>>=20
>> >>>> I must admit I am getting lost in these discussions. It seems to me=
 there is a lot of hand-waving and hidden assumptions that moreover differ =
from one person to another. As I already said in Prague, both anyxml and an=
ydata are IMO constructs of marginal utility and it is frustrating we spend=
 so much effort on them.
>> >>>>=20
>> >>>=20
>> >>> I agree that anyxml is of marginal utility, anydata however is needed
>> >>> for any rpc/action/notification or future language construct that can
>> >>> work with generic YANG content and hence I think its behaviour and
>> >>> encoding should be well defined.
>> >>=20
>> >> But then I believe we should have stricter rules for anydata than just
>> >> "an unknown set of nodes that can be modelled with YANG" - it should =
be
>> >> stated that the data model for an anydata instance MUST be known at
>> >> run-time. Otherwise I think anyxml can cover all use cases you mention
>> >> as well (as it has done in the past), and there is no need to introdu=
ce
>> >> a new data node type with a definition that allows for multiple
>> >> interpretations.
>> >>=20
>> >=20
>> > Lada, we are not repeating the discussion. It was long and painful
>> > enough and we finally accepted and verified Y34-05. If you have better
>> > wording to propose, feel free to make a proposal. But I am not going
>> > to open Y34 again just because you still do not like it.
>>=20
>> Experience has shown that the current formulation is understood differen=
tly by different people.
>>=20
>> Earlier in this thread, you proposed this text to be added to the yang-j=
son spec:
>>=20
>>      An anydata data node can contain an unknown set of nodes that can
>>      be modelled by YANG. A data model for anydata content may or may
>>      not exist at run time.  If the data model for anydata content is
>>      available, then the anydata content MUST be encoded according to
>>      the rules of this specification. If the data model for anydata
>>      content is not available, the encoding MUST follow the rules of
>>      this specification except for rules that require data model
>>      knowledge (and as a consequence, numbers may appear as strings or
>>      namespace qualifiers may not match module names).
>>=20
>> So let me repeat: shouldn=E2=80=99t this text really go to 6020bis? Or d=
o you think that XML encoding needn=E2=80=99t abide by the data model if it=
 is known?
>>
>
> Are you suggesting there should be similar text for the XML encoding or
> are you suggesting there should be abstract text for all encodings?

I think it should be an encoding-independent statement - if the data
model is known, then anydata contents should be essentially no different
from a regular data (sub)tree.

> RFC6020bis says currently:
>
>    An anydata node is encoded as an XML element.  The element's local
>    name is the anydata's identifier, and its namespace is the module's
>    XML namespace (see Section 7.1.3).  The value of the anydata node is
>    a set of nodes, which are encoded as XML subelements to the anydata
>    element.

Note, however, that this still includes contents that cannot be modelled
in YANG. The rules in the yang-json document (sec. 5.5) are similar but
they also try to exclude data that can never come from YANG.

>
> Perhaps it means 'set of data nodes' where it says 'set of nodes'. The
> main difference here is that encoding anydata into XML is somewhat
> easier since you do not need to know whether 42 has to be encoded as a
> string or a number etc.
>
>> > That said, "MUST be known at run-time" may already fall apart with the
>> > mount proposals discussed in NETCONF (or it is sufficiently unclear to
>> > whom it MUST be known).
>>=20
>> To the server and client so that they both work with the same data
>> model. Of course, it is true that currently there are no means for
>> passing this information (either way) but I guess your text above
>> suffers from the same problem: how can you tell whether the data
>> model for anydata content is available or not?
>>
>
> The example is a RESTCONF server mounting data from a remove datastore
> and using JSON encoding when talking to RESTCONF clients. Do we
> require that such a server has to have knowledge about the data model
> mounted in order to get the encoding right? Or do we expect that the
> RESTCONF client can deal with situations where encodings may not 100%
> match the data model (e.g. lack of type knowledge, lack of namespace
> to module name mappings).

This is not clear to me. I think access to remote content and schema
availability are orthogonal problems.

Lada

>
> /js
>
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 29 02:01:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BB21A6F7A for ; Tue, 29 Sep 2015 02:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv74cK4OSYGj for ; Tue, 29 Sep 2015 02:01:04 -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 78EFF1A6F6E for ; Tue, 29 Sep 2015 02:01:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 247D1FFA; Tue, 29 Sep 2015 11:01:03 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TkTi6zJFAFGo; Tue, 29 Sep 2015 11:01:01 +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, 29 Sep 2015 11:01:01 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43D692005F; Tue, 29 Sep 2015 11:01:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JNhA7Sfl3N2J; Tue, 29 Sep 2015 11:00:58 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB7FA20053; Tue, 29 Sep 2015 11:00:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AE33E37695AC; Tue, 29 Sep 2015 11:00:57 +0200 (CEST)
Date: Tue, 29 Sep 2015 11:00:57 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150929090057.GD98354@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , NETMOD Working Group 
References:  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local>  <20150923131119.GA1945@elstar.local> <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz> <20150928065504.GA95250@elstar.local> 
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.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 09:01:07 -0000

On Tue, Sep 29, 2015 at 10:28:28AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Wed, Sep 23, 2015 at 03:46:27PM +0200, Ladislav Lhotka wrote:
> >> 
> >> > On 23 Sep 2015, at 15:11, Juergen Schoenwaelder  wrote:
> >> > 
> >> > On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote:
> >> >>>> 
> >> >>>> I must admit I am getting lost in these discussions. It seems to me there is a lot of hand-waving and hidden assumptions that moreover differ from one person to another. As I already said in Prague, both anyxml and anydata are IMO constructs of marginal utility and it is frustrating we spend so much effort on them.
> >> >>>> 
> >> >>> 
> >> >>> I agree that anyxml is of marginal utility, anydata however is needed
> >> >>> for any rpc/action/notification or future language construct that can
> >> >>> work with generic YANG content and hence I think its behaviour and
> >> >>> encoding should be well defined.
> >> >> 
> >> >> But then I believe we should have stricter rules for anydata than just
> >> >> "an unknown set of nodes that can be modelled with YANG" - it should be
> >> >> stated that the data model for an anydata instance MUST be known at
> >> >> run-time. Otherwise I think anyxml can cover all use cases you mention
> >> >> as well (as it has done in the past), and there is no need to introduce
> >> >> a new data node type with a definition that allows for multiple
> >> >> interpretations.
> >> >> 
> >> > 
> >> > Lada, we are not repeating the discussion. It was long and painful
> >> > enough and we finally accepted and verified Y34-05. If you have better
> >> > wording to propose, feel free to make a proposal. But I am not going
> >> > to open Y34 again just because you still do not like it.
> >> 
> >> Experience has shown that the current formulation is understood differently by different people.
> >> 
> >> Earlier in this thread, you proposed this text to be added to the yang-json spec:
> >> 
> >>      An anydata data node can contain an unknown set of nodes that can
> >>      be modelled by YANG. A data model for anydata content may or may
> >>      not exist at run time.  If the data model for anydata content is
> >>      available, then the anydata content MUST be encoded according to
> >>      the rules of this specification. If the data model for anydata
> >>      content is not available, the encoding MUST follow the rules of
> >>      this specification except for rules that require data model
> >>      knowledge (and as a consequence, numbers may appear as strings or
> >>      namespace qualifiers may not match module names).
> >> 
> >> So let me repeat: shouldn’t this text really go to 6020bis? Or do you think that XML encoding needn’t abide by the data model if it is known?
> >>
> >
> > Are you suggesting there should be similar text for the XML encoding or
> > are you suggesting there should be abstract text for all encodings?
> 
> I think it should be an encoding-independent statement - if the data
> model is known, then anydata contents should be essentially no different
> from a regular data (sub)tree.

Can you make a concrete proposal how to change the text in section
7.10 of draft-ietf-netmod-rfc6020bis-07.txt? And then please post it
as a separate thread so we can track it as YANG 1.1 last call comment.

> > RFC6020bis says currently:
> >
> >    An anydata node is encoded as an XML element.  The element's local
> >    name is the anydata's identifier, and its namespace is the module's
> >    XML namespace (see Section 7.1.3).  The value of the anydata node is
> >    a set of nodes, which are encoded as XML subelements to the anydata
> >    element.
> 
> Note, however, that this still includes contents that cannot be modelled
> in YANG. The rules in the yang-json document (sec. 5.5) are similar but
> they also try to exclude data that can never come from YANG.
> 
> >
> > Perhaps it means 'set of data nodes' where it says 'set of nodes'. The
> > main difference here is that encoding anydata into XML is somewhat
> > easier since you do not need to know whether 42 has to be encoded as a
> > string or a number etc.
> >
> >> > That said, "MUST be known at run-time" may already fall apart with the
> >> > mount proposals discussed in NETCONF (or it is sufficiently unclear to
> >> > whom it MUST be known).
> >> 
> >> To the server and client so that they both work with the same data
> >> model. Of course, it is true that currently there are no means for
> >> passing this information (either way) but I guess your text above
> >> suffers from the same problem: how can you tell whether the data
> >> model for anydata content is available or not?
> >>
> >
> > The example is a RESTCONF server mounting data from a remove datastore
> > and using JSON encoding when talking to RESTCONF clients. Do we
> > require that such a server has to have knowledge about the data model
> > mounted in order to get the encoding right? Or do we expect that the
> > RESTCONF client can deal with situations where encodings may not 100%
> > match the data model (e.g. lack of type knowledge, lack of namespace
> > to module name mappings).
> 
> This is not clear to me. I think access to remote content and schema
> availability are orthogonal problems.

I wanted to provide an example demonstrating that schema availability
is not always guaranteed and since (i) JSON and XML use different ways
to encode namespaces and (ii) JSON assumes some type information to be
available while XML does not encode any type information, the example
outlined above will either be expensive to implement (the mount server
essentially has to grab all necessary data models while mounting
something from a remote datastore) or it will produce encodings that
require the client to very lenient in order to interoperate.

Yes, in an ideal world, these would be orthogonal problems but due the
differences how the encodings work, they are not as orthogonal as one
might think.

/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 Sep 29 02:10:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CF71A0390 for ; Tue, 29 Sep 2015 02:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiF_ARwF1mMQ for ; Tue, 29 Sep 2015 02:10:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 82BA61A6F0B for ; Tue, 29 Sep 2015 02:10:45 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 701461CC009D; Tue, 29 Sep 2015 11:10:55 +0200 (CEST)
From: Ladislav Lhotka 
To: Randy Presuhn , netmod@ietf.org
In-Reply-To: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <13615645.1443458054517.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 29 Sep 2015 11:10:48 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 09:10:48 -0000

Randy Presuhn  writes:

> Hi -
>
>>From: Martin Bjorklund 
>>Sent: Sep 28, 2015 3:15 AM
>>To: jernejt@mg-soft.si
>>Cc: netmod@ietf.org
>>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-07.txt
> ...
>>Ok; the intention was "replace if it exists, and create otherwise"
>>(i.e., "replace" as in NETCONF edit operation).   We can make this
>>explicit:
>>
>>NEW:
>>
>>- If the "when" statement is a child of any other data definition
>>  statement, the accessible tree is tentatively altered during the
>>  processing of the XPath expression by replacing all instances of the
>>  data node for which the "when" statement is defined with a single
>>  dummy node with the same name, but with no value and no children.
>>  If no instances of the data node exists, the dummy node is created.
>>  The context node is this dummy node.
>
> A standard should avoid prescribing a specific implementation
> strategy, and should instead limit itself to describing what
> the observable behaviours of the relevant interfaces must be.

"when" statement relies on XPath but in some situations context for
XPath evaluation is not properly defined. The proposed solution to
Issue=C2=A0Y18 tries to alleviate this problem by defining tentative
manipulations to XML infoset that provide the necessary context.

I am not particularly happy with this solution but still it is IMO
better than hand-waving. I think "when" statement is a problematic
inovation over standard XML schema languages because it defies
grammar-based validation.

Lada

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

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 29 07:07:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11301B407E for ; Tue, 29 Sep 2015 07:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUkXn5JX66qI for ; Tue, 29 Sep 2015 07:07:28 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1B1B405F for ; Tue, 29 Sep 2015 07:06:56 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E7BAA1CC008C for ; Tue, 29 Sep 2015 16:07:06 +0200 (CEST)
From: Ladislav Lhotka 
To: netmod@ietf.org
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 29 Sep 2015 16:07:00 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [netmod] 6020bis - anydata
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 14:07:31 -0000

Hi,

I propose to expand the text in Sec. 7.10 as follows:

OLD

   The "anydata" statement is used to represent an unknown set of nodes
   that can be modelled with YANG.  An example of where this can be
   useful is a list of received notifications, where the exact
   notifications are not known as design time.

NEW

   The "anydata" statement is used to represent an unknown set of nodes
   that can be modelled with YANG but for which the data model doesn't
   exist at module design time. At run time, the data model for
   "anydata" content MAY be known through protocol signalling or other
   means that are outside the scope of this document, it is however not
   required. If the data model is known, implementations MUST treat
   "anydata" content exactly as if it was a part of regular data tree.

   An example of where this can be useful is a list of received
   notifications, where the exact notifications are not known as module
   design time.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 29 07:31:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653111B4248 for ; Tue, 29 Sep 2015 07:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx8KDHInZMM3 for ; Tue, 29 Sep 2015 07:31:15 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 21FAF1B424D for ; Tue, 29 Sep 2015 07:31:15 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6FFFA1CC008C; Tue, 29 Sep 2015 16:31:25 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
In-Reply-To: <20150929090057.GD98354@elstar.local>
References:  <20150916151759.GB76960@elstar.local>   <20150921203439.GB96806@elstar.local>  <20150923131119.GA1945@elstar.local> <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz> <20150928065504.GA95250@elstar.local>  <20150929090057.GD98354@elstar.local>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 29 Sep 2015 16:31:18 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 14:31:17 -0000

Juergen Schoenwaelder  writes:

> On Tue, Sep 29, 2015 at 10:28:28AM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>=20
>> > On Wed, Sep 23, 2015 at 03:46:27PM +0200, Ladislav Lhotka wrote:
>> >>=20
>> >> > On 23 Sep 2015, at 15:11, Juergen Schoenwaelder  wrote:
>> >> >=20
>> >> > On Wed, Sep 23, 2015 at 10:14:52AM +0200, Ladislav Lhotka wrote:
>> >> >>>>=20
>> >> >>>> I must admit I am getting lost in these discussions. It seems to=
 me there is a lot of hand-waving and hidden assumptions that moreover diff=
er from one person to another. As I already said in Prague, both anyxml and=
 anydata are IMO constructs of marginal utility and it is frustrating we sp=
end so much effort on them.
>> >> >>>>=20
>> >> >>>=20
>> >> >>> I agree that anyxml is of marginal utility, anydata however is ne=
eded
>> >> >>> for any rpc/action/notification or future language construct that=
 can
>> >> >>> work with generic YANG content and hence I think its behaviour and
>> >> >>> encoding should be well defined.
>> >> >>=20
>> >> >> But then I believe we should have stricter rules for anydata than =
just
>> >> >> "an unknown set of nodes that can be modelled with YANG" - it shou=
ld be
>> >> >> stated that the data model for an anydata instance MUST be known at
>> >> >> run-time. Otherwise I think anyxml can cover all use cases you men=
tion
>> >> >> as well (as it has done in the past), and there is no need to intr=
oduce
>> >> >> a new data node type with a definition that allows for multiple
>> >> >> interpretations.
>> >> >>=20
>> >> >=20
>> >> > Lada, we are not repeating the discussion. It was long and painful
>> >> > enough and we finally accepted and verified Y34-05. If you have bet=
ter
>> >> > wording to propose, feel free to make a proposal. But I am not going
>> >> > to open Y34 again just because you still do not like it.
>> >>=20
>> >> Experience has shown that the current formulation is understood diffe=
rently by different people.
>> >>=20
>> >> Earlier in this thread, you proposed this text to be added to the yan=
g-json spec:
>> >>=20
>> >>      An anydata data node can contain an unknown set of nodes that can
>> >>      be modelled by YANG. A data model for anydata content may or may
>> >>      not exist at run time.  If the data model for anydata content is
>> >>      available, then the anydata content MUST be encoded according to
>> >>      the rules of this specification. If the data model for anydata
>> >>      content is not available, the encoding MUST follow the rules of
>> >>      this specification except for rules that require data model
>> >>      knowledge (and as a consequence, numbers may appear as strings or
>> >>      namespace qualifiers may not match module names).
>> >>=20
>> >> So let me repeat: shouldn=E2=80=99t this text really go to 6020bis? O=
r do you think that XML encoding needn=E2=80=99t abide by the data model if=
 it is known?
>> >>
>> >
>> > Are you suggesting there should be similar text for the XML encoding or
>> > are you suggesting there should be abstract text for all encodings?
>>=20
>> I think it should be an encoding-independent statement - if the data
>> model is known, then anydata contents should be essentially no different
>> from a regular data (sub)tree.
>
> Can you make a concrete proposal how to change the text in section
> 7.10 of draft-ietf-netmod-rfc6020bis-07.txt? And then please post it
> as a separate thread so we can track it as YANG 1.1 last call comment.

Done.

>
>> > RFC6020bis says currently:
>> >
>> >    An anydata node is encoded as an XML element.  The element's local
>> >    name is the anydata's identifier, and its namespace is the module's
>> >    XML namespace (see Section 7.1.3).  The value of the anydata node is
>> >    a set of nodes, which are encoded as XML subelements to the anydata
>> >    element.
>>=20
>> Note, however, that this still includes contents that cannot be modelled
>> in YANG. The rules in the yang-json document (sec. 5.5) are similar but
>> they also try to exclude data that can never come from YANG.
>>=20
>> >
>> > Perhaps it means 'set of data nodes' where it says 'set of nodes'. The
>> > main difference here is that encoding anydata into XML is somewhat
>> > easier since you do not need to know whether 42 has to be encoded as a
>> > string or a number etc.
>> >
>> >> > That said, "MUST be known at run-time" may already fall apart with =
the
>> >> > mount proposals discussed in NETCONF (or it is sufficiently unclear=
 to
>> >> > whom it MUST be known).
>> >>=20
>> >> To the server and client so that they both work with the same data
>> >> model. Of course, it is true that currently there are no means for
>> >> passing this information (either way) but I guess your text above
>> >> suffers from the same problem: how can you tell whether the data
>> >> model for anydata content is available or not?
>> >>
>> >
>> > The example is a RESTCONF server mounting data from a remove datastore
>> > and using JSON encoding when talking to RESTCONF clients. Do we
>> > require that such a server has to have knowledge about the data model
>> > mounted in order to get the encoding right? Or do we expect that the
>> > RESTCONF client can deal with situations where encodings may not 100%
>> > match the data model (e.g. lack of type knowledge, lack of namespace
>> > to module name mappings).
>>=20
>> This is not clear to me. I think access to remote content and schema
>> availability are orthogonal problems.
>
> I wanted to provide an example demonstrating that schema availability
> is not always guaranteed and since (i) JSON and XML use different ways
> to encode namespaces and (ii) JSON assumes some type information to be
> available while XML does not encode any type information, the example
> outlined above will either be expensive to implement (the mount server
> essentially has to grab all necessary data models while mounting
> something from a remote datastore) or it will produce encodings that
> require the client to very lenient in order to interoperate.

It is because JSON and XML are not just different encodings, as UCS-2
and UTF-8 are different encodings of Unicode that can be mapped
1-1. Information sets of XML and JSON differ considerably, so coercing
one into the other makes no sense.

It will be no different if, for example, CBOR is used as another
"encoding" for YANG data.

Maybe it would be better to use "serialization" rather than "encoding"
in 6020bis and draft-ietf-netmod-yang-json.

Lada

>
> Yes, in an ideal world, these would be orthogonal problems but due the
> differences how the encodings work, they are not as orthogonal as one
> might think.
>
> /js
>
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Sep 29 07:47:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7550A1B4350 for ; Tue, 29 Sep 2015 07:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBTC2_kaP-ZD for ; Tue, 29 Sep 2015 07:47:16 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED5E1B434E for ; Tue, 29 Sep 2015 07:47:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6435; q=dns/txt; s=iport; t=1443538037; x=1444747637; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=DLJ39ynJEZSha5DxCXAK6RI37E1LMJ0alic7iXAViDA=; b=PTeGQxEAmEuFZkOP5EtuA7OHerr7xYUbHvlCdTk894bvyW0bhpcSCbOR yFZLk/BOcLqcxuTOjBRNCgaBpJx5bdj1FA/gLccox6Honicl2F3Ge5lDh jJxYl0xKNoWecbkL4G71G9Ed+1civgvHRdeUQQKXomfrARa9Rm0c2v75E 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DdAQAFowpW/xbLJq1ehGGDKro7AQ2HdAKCBRQBAQEBAQEBgQqEJQEBBCMkMQEQCxgJFgQEAwICCQMCAQIBNBEGDQYCAQGIKrcehRyPPAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9hEJLB4JpgUMFlXSNE4kFkj8fAQFCgkOBPz0ziR8BAQE
X-IronPort-AV: E=Sophos;i="5.17,608,1437436800";  d="scan'208,217";a="630034997"
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; 29 Sep 2015 14:47:15 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8TElDtD004529; Tue, 29 Sep 2015 14:47:13 GMT
To: Andy Bierman 
References:  <5603F9C2.2000500@cisco.com>  <5609749D.90207@cisco.com> 
From: Robert Wilton 
Message-ID: <560AA471.3050307@cisco.com>
Date: Tue, 29 Sep 2015 15:47:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090001090805060909090602"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 14:47:17 -0000

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



On 28/09/2015 18:17, Andy Bierman wrote:
>
>
> On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton  > wrote:
>
>     Hi Andy,
>
>
>     On 24/09/2015 19:22, Andy Bierman wrote:
>>     Hi,
>>
>>     I find this exercise to classify servers as synchronous or
>>     asynchronous mostly useless.
>>     We have both types of instrumentation in our server. They can be
>>     different
>>     on a per-node basis.  They can both take a long time or both be
>>     instant, depending
>>     on the instrumentation code the vendor writes.
>>
>>     In any case, the server does not know if the instrumentation has
>>     finished making
>>     the network behave according to the new edit. That would be new
>>     functionality that
>>     no vendor supports at this time.  Currently servers return "ok"
>>     if the edit is accepted
>>     into the running datastore.  There are no other semantics wrt/
>>     returning "ok".
>
>     I'm not sure whether we agree here, but as stated previously, Sec
>     5.1 of RFC 6241, implies that if the configuration is in the
>     running datastore then that configuration is expected to be active
>     on the device.
>
>
> I do not agree at all that the running datastore means anything other
> than the intended confg.   A new operation is needed to retrieve
> the active config vs. the intended config.

If the running datastore only ever means intended config, then I think 
that would imply:

  - existing NETCONF servers should reply immediately after the config 
has been semantically verified + written to the config subsystem before 
the configuration is applied.

  - existing NETCONF servers are logically classified (as per 
openconfig-netmod-opstate) as being asynchronous w.r.t to the config 
requests.

  - the existing NETCONF/RESTCONF protocols has no direct mechanism for 
indicating a failure to apply any configuration leaf, the only way such 
information could be deduced is through related operational state leaves 
or notifications.

Rob


--------------090001090805060909090602
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 28/09/2015 18:17, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Sep 28, 2015 at 10:10 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              
 Hi Andy,

                

                

                
On 24/09/2015 19:22, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
I find this exercise to classify servers as
                      synchronous or asynchronous mostly useless.

                    
We have both types of instrumentation in our
                      server. They can be different

                    
on a per-node basis.  They can both take a long
                      time or both be instant, depending

                    
on the instrumentation code the vendor writes.

                    


                    

                    
In any case, the server does not know if the
                      instrumentation has finished making

                    
the network behave according to the new edit. 
                      That would be new functionality that

                    
no vendor supports at this time.  Currently
                      servers return "ok" if the edit is accepted

                    
into the running datastore.  There are no other
                      semantics wrt/ returning "ok".

                  

                

                

                I'm not sure whether we agree here, but as stated
                previously, Sec 5.1 of RFC 6241, implies that if the
                configuration is in the running datastore then that
                configuration is expected to be active on the device.

                

              

            

            


            

            
I do not agree at all that the running datastore means
              anything other

            
than the intended confg.   A new operation is needed to
              retrieve

            
the active config vs. the intended config.

          

        

      

    

    

    If the running datastore only ever means intended config, then I
    think that would imply:

    

     - existing NETCONF servers should reply immediately after the
    config has been semantically verified + written to the config
    subsystem before the configuration is applied.

    

     - existing NETCONF servers are logically classified (as per
    openconfig-netmod-opstate) as being asynchronous w.r.t to the config
    requests.

    

     - the existing NETCONF/RESTCONF protocols has no direct mechanism
    for indicating a failure to apply any configuration leaf, the only
    way such information could be deduced is through related operational
    state leaves or notifications.

    

    Rob

    

  


--------------090001090805060909090602--


From nobody Tue Sep 29 09:11:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A7C1B46AF for ; Tue, 29 Sep 2015 09:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkXuuFB6uLXR for ; Tue, 29 Sep 2015 09:11:11 -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 CAC061B46ED for ; Tue, 29 Sep 2015 09:11:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 93D808F1; Tue, 29 Sep 2015 18:11:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YdpAPRDk4Loo; Tue, 29 Sep 2015 18:11:08 +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, 29 Sep 2015 18:11:08 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 878B520053; Tue, 29 Sep 2015 18:11:08 +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 Fc0Vtd8RJI5b; Tue, 29 Sep 2015 18:11:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E762E2004E; Tue, 29 Sep 2015 18:11:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 271D53769BEA; Tue, 29 Sep 2015 18:11:04 +0200 (CEST)
Date: Tue, 29 Sep 2015 18:11:03 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150929161101.GA99497@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Randy Presuhn , NETMOD Working Group 
References:   <20150921203439.GB96806@elstar.local>  <20150923131119.GA1945@elstar.local> <84F8DD3A-25CC-4330-8EC9-80AA3401EA70@nic.cz> <20150928065504.GA95250@elstar.local>  <20150929090057.GD98354@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , NETMOD Working Group 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 16:11:12 -0000

On Tue, Sep 29, 2015 at 04:31:18PM +0200, Ladislav Lhotka wrote:
> 
> It is because JSON and XML are not just different encodings, as UCS-2
> and UTF-8 are different encodings of Unicode that can be mapped
> 1-1. Information sets of XML and JSON differ considerably, so coercing
> one into the other makes no sense.
> 
> It will be no different if, for example, CBOR is used as another
> "encoding" for YANG data.
> 
> Maybe it would be better to use "serialization" rather than "encoding"
> in 6020bis and draft-ietf-netmod-yang-json.
>

Changing the terms does not change the characteristics of the design:
The encodings (or serializations) are not transformable without having
the data models. This has consequences and the WG hopefully
understands them. The impact is likely low on a device hosting a
server and low on a true management system. But anything generic in
between those two (and I am sure there will be stuff in between plain
servers on devices and management systems - mount is just a first
example) will have to be able to grab data models as necessary in
order to pass information along.

/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 Sep 29 09:56:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9277C1B48C4 for ; Tue, 29 Sep 2015 09:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx5lWJ9Wn4nr for ; Tue, 29 Sep 2015 09:56:00 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 198001B48C3 for ; Tue, 29 Sep 2015 09:56:00 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bcZsNsO0UUH6ircCJ/3idDRkSUHQ5UPljogHWQxOdUBThFu9KVRWmllTM9OxoUTp; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZgyC7-0007bv-GX for netmod@ietf.org; Tue, 29 Sep 2015 12:55:59 -0400
Received: from 76.254.48.35 by webmail.earthlink.net with HTTP; Tue, 29 Sep 2015 12:55:59 -0400
Message-ID: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
Date: Tue, 29 Sep 2015 09:55:59 -0700 (GMT-07:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3edb0ec6e1a8e62ea8d2c39b74780376072350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.29
Archived-At: 
Subject: Re: [netmod] 6020bis - anydata
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 16:56:01 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Sep 29, 2015 7:07 AM
>To: netmod@ietf.org
>Subject: [netmod] 6020bis - anydata
>
>Hi,
>
>I propose to expand the text in Sec. 7.10 as follows:
>
>OLD
>
>   The "anydata" statement is used to represent an unknown set of nodes
>   that can be modelled with YANG.  An example of where this can be
>   useful is a list of received notifications, where the exact
>   notifications are not known as design time.
>
>NEW
>
>   The "anydata" statement is used to represent an unknown set of nodes
>   that can be modelled with YANG but for which the data model doesn't
>   exist at module design time.

"doesn't exist" would not be appropriate for the example you provide
below.  It would be incorrect if some of the notifications in your
example had already been defined, even though "anydata" would still
be necessary to handle others not yet defined.

>                                At run time, the data model for
>   "anydata" content MAY be known through protocol signalling or other

This use of "MAY" seems outside the RFC 2119 sense.  Suggested
replacement:

   It is possible for the data model for "anydata" content to become
   known through protocol signalling or other

>   means that are outside the scope of this document, it is however not
>   required. If the data model is known, implementations MUST treat
>   "anydata" content exactly as if it was a part of regular data tree.

"of regular" -> "of a regular" -or- "of the regular", depending
on which it is that you mean

This use of "MUST" seems at odds with section 6 of RFC 2119.
For example, dynamic lookup of data models could be affected by
connectivity.  The "MUST" would mean that the observable protocol
behaviour on the Netconf wire could change, depending on whether
a schema server happened to be reachable at the moment (or not).

Suggested replacement:

    When the data model is known (by whatever means) it is possible
    for implementations to treat "anydata" as a part of the regular
    data tree.

    When the data model is not known, the following limitations
    potentially apply:
       -?

>   An example of where this can be useful is a list of received
>   notifications, where the exact notifications are not known as module

  "as" -> "at"

>   design time.
...


Randy


From nobody Tue Sep 29 10:57:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B01ACE7A for ; Tue, 29 Sep 2015 10:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7LcOPUzRvEF for ; Tue, 29 Sep 2015 10:57:01 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 E04751ACE73 for ; Tue, 29 Sep 2015 10:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1443549333; bh=B/CG7WgiD796YFOmptIJ62iQB5bBjqlWzPrvi/Z/oiE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=moFPFUsJfRkM3/MTlKqjgy0ukV4jwGoJA2MwrArS+ZcIxA4jqsArujw+rKotpgKrr TejXKdJiZVr1QIrk+QJKppnkZLHqwcOBaacKwWYvYSKH8QO81dGAGaZSa4Kohjq1CB Fv7F9LA/w3GtNrqY0hu20m4kTO3cgropHwzB6FRQ=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8BF435F4-DEFB-4848-BC0D-DAE88B8AEE02"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: <560AA471.3050307@cisco.com>
Date: Tue, 29 Sep 2015 13:56:56 -0400
Message-Id: <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.com>
References:  <5603F9C2.2000500@cisco.com>  <5609749D.90207@cisco.com>  <560AA471.3050307@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=8 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 137, in=1704, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 17:57:06 -0000

--Apple-Mail=_8BF435F4-DEFB-4848-BC0D-DAE88B8AEE02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


	Robert,

	It seems this discussion has run out of steam and we=E2=80=99ve =
come to a head on this issue. =20
It seems we have some actions we can take based on the list of three =
bullets below as part of
that conclusion (potentially). =20

	Do folks think we are ready to close this issue down officially?

	=E2=80=94Tom


> On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton =
 wrote:
>=20
>=20
>=20
> On 28/09/2015 18:17, Andy Bierman wrote:
>>=20
>>=20
>> On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton > wrote:
>> Hi Andy,
>>=20
>>=20
>> On 24/09/2015 19:22, Andy Bierman wrote:
>>> Hi,
>>>=20
>>> I find this exercise to classify servers as synchronous or =
asynchronous mostly useless.
>>> We have both types of instrumentation in our server. They can be =
different
>>> on a per-node basis.  They can both take a long time or both be =
instant, depending
>>> on the instrumentation code the vendor writes.
>>>=20
>>> In any case, the server does not know if the instrumentation has =
finished making
>>> the network behave according to the new edit.  That would be new =
functionality that
>>> no vendor supports at this time.  Currently servers return "ok" if =
the edit is accepted
>>> into the running datastore.  There are no other semantics wrt/ =
returning "ok".
>>=20
>> I'm not sure whether we agree here, but as stated previously, Sec 5.1 =
of RFC 6241, implies that if the configuration is in the running =
datastore then that configuration is expected to be active on the =
device.
>>=20
>>=20
>> I do not agree at all that the running datastore means anything other
>> than the intended confg.   A new operation is needed to retrieve
>> the active config vs. the intended config.
>=20
> If the running datastore only ever means intended config, then I think =
that would imply:
>=20
>  - existing NETCONF servers should reply immediately after the config =
has been semantically verified + written to the config subsystem before =
the configuration is applied.
>=20
>  - existing NETCONF servers are logically classified (as per =
openconfig-netmod-opstate) as being asynchronous w.r.t to the config =
requests.
>=20
>  - the existing NETCONF/RESTCONF protocols has no direct mechanism for =
indicating a failure to apply any configuration leaf, the only way such =
information could be deduced is through related operational state leaves =
or notifications.
>=20
> Rob
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_8BF435F4-DEFB-4848-BC0D-DAE88B8AEE02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



	=
Robert,

	=
It seems this discussion has run out of steam and we=E2=80=99ve =
come to a head on this issue.  
It seems we =
have some actions we can take based on the list of three bullets below =
as part of
that conclusion (potentially). =
 

	Do folks =
think we are ready to close this issue down officially?

	=
=E2=80=94Tom


On =
Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton <rwilton@cisco.com> =
wrote:


 =20
    
 =20
  

    

    

    
On 28/09/2015 18:17, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Sep 28, 2015 at 10:10 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              
 Hi =
Andy,

                

                

                
On 24/09/2015 19:22, Andy Bierman =
wrote:

                

                

                  
Hi,
                    


                    

                    
I find this exercise to classify =
servers as
                      synchronous or asynchronous mostly useless.

                    
We have both types of =
instrumentation in our
                      server. They can be different

                    
on a per-node basis.  They can =
both take a long
                      time or both be instant, depending

                    
on the instrumentation code the =
vendor writes.

                    


                    

                    
In any case, the server does not =
know if the
                      instrumentation has finished making

                    
the network behave according to the =
new edit. 
                      That would be new functionality that

                    
no vendor supports at this =
time.  Currently
                      servers return "ok" if the edit is accepted

                    
into the running datastore.  =
There are no other
                      semantics wrt/ returning "ok".

                  

                

                

                I'm not sure whether we agree here, but as stated
                previously, Sec 5.1 of RFC 6241, implies that if the
                configuration is in the running datastore then that
                configuration is expected to be active on the device.

                

              

            

            


            

            
I do not agree at all that the running =
datastore means
              anything other

            
than the intended confg.   A new =
operation is needed to
              retrieve

            
the active config vs. the intended =
config.

          

        

      

    

    

    If the running datastore only ever means intended config, then I
    think that would imply:

    

     - existing NETCONF servers should reply immediately after the
    config has been semantically verified + written to the config
    subsystem before the configuration is applied.

    

     - existing NETCONF servers are logically classified (as per
    openconfig-netmod-opstate) as being asynchronous w.r.t to the config
    requests.

    

     - the existing NETCONF/RESTCONF protocols has no direct =
mechanism
    for indicating a failure to apply any configuration leaf, the only
    way such information could be deduced is through related operational
    state leaves or notifications.

    

    Rob

    

  


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

=

--Apple-Mail=_8BF435F4-DEFB-4848-BC0D-DAE88B8AEE02--


From nobody Tue Sep 29 11:39:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF101B4AA5 for ; Tue, 29 Sep 2015 11:39: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b9Xyd_9WJMT for ; Tue, 29 Sep 2015 11:39:51 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84081B4AA1 for ; Tue, 29 Sep 2015 11:39:49 -0700 (PDT)
Received: from BY1PR0501CA0012.namprd05.prod.outlook.com (10.162.139.22) by BN3PR0501MB1377.namprd05.prod.outlook.com (10.160.117.11) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 29 Sep 2015 18:39:46 +0000
Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::103) by BY1PR0501CA0012.outlook.office365.com (2a01:111:e400:4821::22) with Microsoft SMTP Server (TLS) id 15.1.280.20 via Frontend Transport; Tue, 29 Sep 2015 18:39:46 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.1.274.4 via Frontend Transport; Tue, 29 Sep 2015 18:39:46 +0000
Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Sep 2015 11:39:38 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t8TIdbD75131	for ; Tue, 29 Sep 2015 11:39:37 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t8TIbdsX023889	for ; Tue, 29 Sep 2015 14:37:39 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201509291837.t8TIbdsX023889@idle.juniper.net>
To: "netmod@ietf.org" 
Date: Tue, 29 Sep 2015 14:37:39 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD006; 1:iSp4KY6TqjmKNisUOyg3LccPZ6HSdcECgkbYmJdJDt8NdMpxICc7Ok05+9L2E8dact6oakr2k6M3J7SoRY4/g0twTz+MjIhpHRXPxO0Baq01nT/dLbk00CuWvXVREG7/3Tlln9yDMDC3MnogpW6Dr506Y0CZrTFsOGOpktjCRh8Um3V3wA6r/xMTIvzQxzCvvKq6FrLwQoM4t5BN1J7WWtLtXUjOJbHTdc1BYRfEm8bd9fgGZxpt4uNllDRAhV75a9Dz1Q76bimE7wRCM6zIIeQlxjHODQggwN11DIlubFmlzt/iZsnOHZqCvrT5GBvLnHrv+hyUuMp/t28d5RgwYw==
X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(164054003)(50986999)(53416004)(81156007)(47776003)(46102003)(68736005)(62966003)(97736004)(5003940100001)(64706001)(189998001)(54356999)(19580405001)(19580395003)(450100001)(5001960100002)(110136002)(107886002)(77156002)(5003600100002)(76506005)(50466002)(11100500001)(48376002)(5007970100001)(5001830100001)(105596002)(2351001)(4001540100001)(2501003)(5001860100001)(92566002)(77096005)(6806005)(106466001)(86362001)(87936001)(5008740100001)(229853001)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1377; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1377; 2:KmHyoGCwhwAtqsg6miFrfH44VY7Z5lEEqrTJSC2l6K3y2dmzBPtpA9UMwotm9kdCMZLJ623N1N1K1miSYgRxBj0txkOlfPN0yKKvKYFo3Q9ugr1cTL86c0AsFyWBnixXbcQtpMouV0firPiBAMdYmgRgS0myUZ+k2ezxLrc2ykQ=; 3:p1uLn1zcAecPBySkX0Mdinbbvdp5Sxxe8CxtZmgEUNK4nXUkNpli8q5ynzmMXL5o9jwvsAoXQ/rRj05qOaORV15AM0dG8QhtABSXMlQLu64drZGCb3XjLLotyiHhCJ5n8qKptBGjCBR8FG9XPoBVPtDMDmDoFGotcx+tyfO64bIsOXh99hWW6f64ip1cqmmRvdqSwGu2XYkF7AEKS+PLw2Y33zlUzfJbpvFOVTZu0+s=; 25:5/+nEdfzIYB9k/38DuXTCCDh/X5xenEwfQIvGctJv0tWoEJOKJzKilxnNNqOflthi3WTgQr372z577o+TpY8aqy1m0nt90SdFYqxYsKuCh1ItyTNPmLbZgH6ZEdV63K2SxxmSs8h55Q/sM55arh1thrjAJk1ev6ccOCnHoAP5ELycLW7lczpjSV3B16B83S+Oah9805jbEjxiH3n6Hpwztg/DMx1nMBUqO2Q3eLUSwy42bknpt6Z/6Jv5g2Lmz3L4DsIMH785Wr7H7Xw80bcoA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1377;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1377; 20:kT1dayjAS0npAa+H8CkmVw54DNekiM+MipBw3TnyZ8CESLErwUgH5kPY3gEfXS7zJJ6TGqCMy8FhkGBGsq8Sbq9aTO6k1FLbIt5um72JkoW9ZOS1bNfG6pJXrVK9bXkbVNKXxlQrsXM2Aq6z3OnJqrJz2CNCfTsU77r5Wf+hClSEgPTMiPTR/57pwkMqtKK3qmKLd2ArQtmk6yXM0bxgluscWRfB+n7o+JDDqe5NpjjZiMEgUcG9j/2FH32ZLTPEx5Qr5uCqiQumS3W1tNicaw9VYzJbuEv7dDt0c86mjXK+2MhCqsrsHKzZCxKPKtRnrNve9/dxqmvu1pGebtIncuJZkF7qZ4a7VSBMYHIzYx243kISIfEi4fbQVBlLVhxSRgZaO8u3H4cPE3QgctzOx3ZnbmZnWz0fJquVEi6MYEwLyDYHk0wT/9L0xxcvlv327Qg99AoHnMxgJQzmB+ZovZ5tABEKIUhz0BuZ6OlY909JPFsBtZRUqxh/mgYxJpn8; 4:U2fAelRsRmPPP4tFWYjuNoUYgdbTcSbBcQPifK4ydraiyCOpB0Yox98YEQtRNYW/edpk8elqTCNtYT/L/8EBCCRxYSAoajzNdDRvrH7LZoChXfViW9PE07xnNM1QJ5+9RVNCztrx7UcrKGZ47YrSUodS8R9cQJCk6mDAe3UakzNCiZcuSpOy2i1cdhlv1SNS3msK94XnKBVXJTcZftuyeRM384z0m6A5euFyTBkiYpw8QYzbwrkl5Jgm3HiWvBRu/x3BxisAqIXguOpUa2vS0bnj6KqxRzGtN81sC3I+ILrzkAGHr/lZLddjTYRCsun9vF4wGcuUuk0ho0bvLf8sWRtblXbxEkc5cuYsixRo1lw=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:BN3PR0501MB1377; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1377; 
X-Forefront-PRVS: 0714841678
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1377; 23:SfB524x/aOFEDaUaWgdWGMmTwVEBbePJEDAW3CV?= =?us-ascii?Q?qEJQt21/x1BvcBHhK65mayiWszcnfBpXQV9a0P00rI0MAMDz8MiJ/YxYW7tu?= =?us-ascii?Q?wg71df9mwS+Wv4Cnk46N/UIbaEYyyodWPoVK/kKQ+SpH6O18YQCJGwEQo4tN?= =?us-ascii?Q?BeO5x5EGPl8MXm96zL1zgDQsKbSNxHqWo8IwRXnx/xPmZwxzfqEMKh2uDvTd?= =?us-ascii?Q?pwGXCxARUacMNEQyFIslQTk0Xou2jgA/nfXZiNrrAg8aoqLkKKruh52bQBL9?= =?us-ascii?Q?ew8V7v0MGC35Cq72125NVAJwPIZcnTGP55qTlgBEUdvHczujdbNIAuHfFay6?= =?us-ascii?Q?9iNkMYTf077lIHNeATLDsvEpAlU6S9ZFZ4fXLWNHppMR1IM80Aa8600UdyOX?= =?us-ascii?Q?qQngfKCZTWGaf6pZ6cubnQ/MIGJSu4CADc7Vbl1X5ogLbBfXvOqn9sfqG+kw?= =?us-ascii?Q?gavaNEKeL01m73amys2qw2GE+OX178ns9goJt5b1SkyXdBD+WN5FzjuTwhIj?= =?us-ascii?Q?FxvgDJvuAHXfLTA2RvkGmjxHrV+1z3NVZL80AQX3m1PPdXdNAYxn7HIchwVP?= =?us-ascii?Q?VBJii27C4O9AetbK+EkcbfVrEt3FCBOH0Hk1C6z39nNNmW2NcC3IYB1nMC62?= =?us-ascii?Q?XimQqUNVADSGWxA8eNjCK1lH06aU5LvwAul0fByJdBt2cG/M5w54hMYnJ12v?= =?us-ascii?Q?Tan27m0lVze0nm3GEabpnq+shIaTnBXIri6iOx6QxAoHJuB0mMwvUFN4pVyH?= =?us-ascii?Q?doHP//7lZBep6F8G+532jfhpTh8JIofXlJ7ky7JDMLjbnnGiLBEO45RmCA0g?= =?us-ascii?Q?DkvK5s0GcnEWg8US33WcuLfbXbmNPkabt1en0v7F4WXYG9v0pddcU8LfRXxk?= =?us-ascii?Q?BwSzTflgix46jzZSCFQuYK8+Q4ylJaTVTfZrWZL/MC6+cYE6tRgkpkLLTy02?= =?us-ascii?Q?mkSPuqLG0wZMht5B7vAIUA75jtOiqMGL78JW4IVWRRg7nyYgE6ujEnbIv4AO?= =?us-ascii?Q?Ah4JZGfybegPPxvd2k65e9ySXgEg8eFlEI8aNwBbB8tqmux2mEKaGxmpULvm?= =?us-ascii?Q?5DdFBPun3bOIQBwPBKRi6fSS2FcKbBiqHZQp0jOKf3mPgaWeXpPmGC7lp7Zc?= =?us-ascii?Q?6saas1Z/1W49GnRK7dbulYdmNBdlvEIVSf/t4jMdl00JXHbKtA5CR3Cg/Yis?= =?us-ascii?Q?XO21YiG5wmXlMTDsEkgx59vRrBHm/Q0Ji83PydnnBrown0TvlYaKTf6roXQ?= =?us-ascii?Q?=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1377; 5:mOq4T8+NC44K1xfGU8+8G+vsRgfiGxyJS0msXGstggrZB73u3j1dUvcEs1nKhlg8G0ESaY9LMnYwB/fyF6vWa5JL1rG427pngoBCNUHQlo1R4DCE2GsSD791gq50BxeppwBmsYjscjiyTpFcoORgAA==; 24:hDJhmMT6OdqAXFKxEFZgV9mrG+xuU23ic1vhYiVDKEHwpHz89xkLQ27Vvw0nMdUcFes9pwGiw5o4M4KrVdoKN9glVA3EpHiLpdyzCyi9cp0=; 20:OwCP45XiU+B94sq9zYbT5hKLJtoo5yABd+G+Ylfs59oSPB8b/dSLzP1YMLk2b5uCJzh+PYqNltZACD12cPngRg==
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2015 18:39:46.0566 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01b-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1377
Archived-At: 
Subject: [netmod]  opstate-reqs: terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 18:39:57 -0000

Semi-in-reply-to: <560AA471.3050307@cisco.com>

I keep thinking the terms in the draft somewhat confusing.  Okay,
confusing isn't exactly right.  I find the terms have a lot of
background that needs to be explained that's not obvious from the
simple explanations in the draft.  The reader will see these terms
and think they know what they mean without that deeper understanding.

For example:

   o  applied configuration - this data represents the state that the
      network element is actually in, i.e., that which is currently
      being run by particular software modules (e.g., the BGP daemon),
      or other systems within the device (e.g., a secondary control-
      plane, or line card).

This says nothing about how the current state relates to the
configuration.  The term "applied configuration" would imply that
this state is driven by configuration, but there's really nothing
here addressing that.  Does config for interfaces that don't exist
appear in AC?  Do implicit peers appear along side explicitly
configured ones?

Likewise:

   o  derived state - this data represents information which is
      generated as part of the system's own interactions.  For example,
      derived state may consist of the results of protocol interactions
      (the negotiated duplex state of an Ethernet link), statistics
      (such as message queue depth), or counters (such as packet input
      or output bytes).

There's nothing that clearly delineates DS from AC.  The switch
from "state" to "information" doesn't really add anything concrete.
Why is AC state but DS information?

How does one decide which category any particular leaf belongs in?
Does "protocol interactions" include ospf peers, their status, and
learned routes?  Is this the same for both explicitly configured
peers and unconfigured peers (set protocols ospf interface ge-0/0/0)?

I wouldn't have thought duplex as derived state, given that I can
configure a value for it.

Would it be better to think of these values in three sets?

A) values given explicitly by the user (== IC == running config)
B) current values which use organization identical to (A)
C) current values which are not organized identical to (A)

I think the real key is that values which _can_ be organized by the
data models used in (A) _should_ use identifical organization in (B).
When I read openconfig, that seems to be their real requirement.

So if (A) has duplex or OSPF peers or interfaces, then (B) will
list duplex state, peer state, and interface state using an identical
organization (in terms of parentage or containers, lists, and keys).

Once the concepts are clear, selecting terminology should be easier.
I'd actually prefer terms like "primary state" and "secondary state"
which force the reader to look up their meaning to terms like
"derived state" which the reader will likely assume they know the
meaning of.  Clean terms really help with understanding and discussions
especially when the audience grows beyond the key players active
here.

Should a request for better terms be a new, distinct issue?

Andy B. writes:
>> I do not agree at all that the running datastore means anything other
>> than the intended confg.   A new operation is needed to retrieve
>> the active config vs. the intended config.

Do we have a definition for "active config"?  Is this running config
or the parts of AC that are fed by IC?

Robert Wilton writes:
>If the running datastore only ever means intended config, then I think 
>that would imply:
>
>  - existing NETCONF servers should reply immediately after the config 
>has been semantically verified + written to the config subsystem before 
>the configuration is applied.

The running datastore is definitely only intended config.

My question is what "the configuration change MUST also be applied
in the system" means in a world of a hundred FRUs with a zillion
chips.  Does an "applied" MTU mean it hits the kernel, the embedded
FRU, or the final chip with enforces the MTU?  Does an "applied"
BGP peer mean an open connection or full route exchange and FIB
update?  There's a lot of gray space here.

The original NETCONF view is that when the config is atomically
accepted as the new, valid config, it's done.  Are we really talking
about changing that?

You see the same issue with AC's used of "particular software
modules", where any piece of functionality might well be a distributed
set of software instances, often with differing code (kernel,
embedded, chip).

FWIW, in JUNOS we show configuration from the configuration database
and _most_ operational commands from the routing engine, either
from its kernel or the daemons running on it.  We expect the kernel
to propagate an MTU as needed without asking the embedded FRU or
chips for their view of the MTU.

>  - the existing NETCONF/RESTCONF protocols has no direct mechanism for 
>indicating a failure to apply any configuration leaf, the only way such 
>information could be deduced is through related operational state leaves 
>or notifications.

True, and this is one of the thing I think openconfig hopes to
address, by allowing apps that fetch IC, fetch AC, and diff them
(with suitable diff logic), which stresses the importance of
reusing organization.

Thanks,
 Phil


From nobody Tue Sep 29 12:30:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC77C1B4D0F for ; Tue, 29 Sep 2015 12:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0TBhdjxAynY for ; Tue, 29 Sep 2015 12:30:12 -0700 (PDT)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE9D1B2B88 for ; Tue, 29 Sep 2015 12:30:11 -0700 (PDT)
Received: by laclj5 with SMTP id lj5so21047815lac.3 for ; Tue, 29 Sep 2015 12:30:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6lplDbsCFOr2eK0J3zwM7EpjaqPP4DQ7ZCIhhFkZygE=; b=Kcg8vtBN4m7Nq+CUQJ2aZoU49j9/XeNtU2mbr8FPcekgyCm478hDK+n8a+kCrizanB wt6F9S9OZY3RQq8SfiTRpabZFGxnQ7cUWaFs0Ez3WyZPspKXx2APv8KrUG7g4oMGuGLf lOQir3fGh0mtC+8CerFJEiJZfhLvz7lxdvyJiU4Xk/oYrX8fB0aY+qtBWHcgJ1eYuxMH lQ+/m77GMZLzaCzXeb2YTDrdAdyz1c9jfjlYVb9c4hRg6LtjClmGXN6BjsQ+5QOLajL3 Xc339kScw/rftxc3ZOFFFoP7F3ss1duxlnPqEarclxIjafd4BY8Tvc4uDVXLMfm1WGw9 tA+A==
X-Gm-Message-State: ALoCoQnlt5yYG5Dn3wCPIa7nZdt2UWSJmICdSfdHCILsEailvbSuB/S3tbC76VvllhN6G/IInkbp
MIME-Version: 1.0
X-Received: by 10.152.237.1 with SMTP id uy1mr7884062lac.33.1443555009794; Tue, 29 Sep 2015 12:30:09 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Tue, 29 Sep 2015 12:30:09 -0700 (PDT)
In-Reply-To: <201509291837.t8TIbdsX023889@idle.juniper.net>
References: <201509291837.t8TIbdsX023889@idle.juniper.net>
Date: Tue, 29 Sep 2015 12:30:09 -0700
Message-ID: 
From: Andy Bierman 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=001a1134079892b1900520e7d741
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs: terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 19:30:20 -0000

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

Hi,

Perhaps the operational requirements are not that clear, so
the terminology is also not that clear?

Is there really a requirement to know detailed info about the
differences between intended and applied config?

It seems like the general requirement is that the client
needs to know when it can start using the network resource
that has been added or modified in the intended config.

There are 2 modes that fall out from this requirement:
  1) synchronous: do not return from this RPC until resources are ready
  2) asynchronous: return right away from this RPC, and inform the client
       when the resources are ready (could indicate ready in the RPC
response)


Andy



On Tue, Sep 29, 2015 at 11:37 AM, Phil Shafer  wrote:

> Semi-in-reply-to: <560AA471.3050307@cisco.com>
>
> I keep thinking the terms in the draft somewhat confusing.  Okay,
> confusing isn't exactly right.  I find the terms have a lot of
> background that needs to be explained that's not obvious from the
> simple explanations in the draft.  The reader will see these terms
> and think they know what they mean without that deeper understanding.
>
> For example:
>
>    o  applied configuration - this data represents the state that the
>       network element is actually in, i.e., that which is currently
>       being run by particular software modules (e.g., the BGP daemon),
>       or other systems within the device (e.g., a secondary control-
>       plane, or line card).
>
> This says nothing about how the current state relates to the
> configuration.  The term "applied configuration" would imply that
> this state is driven by configuration, but there's really nothing
> here addressing that.  Does config for interfaces that don't exist
> appear in AC?  Do implicit peers appear along side explicitly
> configured ones?
>
> Likewise:
>
>    o  derived state - this data represents information which is
>       generated as part of the system's own interactions.  For example,
>       derived state may consist of the results of protocol interactions
>       (the negotiated duplex state of an Ethernet link), statistics
>       (such as message queue depth), or counters (such as packet input
>       or output bytes).
>
> There's nothing that clearly delineates DS from AC.  The switch
> from "state" to "information" doesn't really add anything concrete.
> Why is AC state but DS information?
>
> How does one decide which category any particular leaf belongs in?
> Does "protocol interactions" include ospf peers, their status, and
> learned routes?  Is this the same for both explicitly configured
> peers and unconfigured peers (set protocols ospf interface ge-0/0/0)?
>
> I wouldn't have thought duplex as derived state, given that I can
> configure a value for it.
>
> Would it be better to think of these values in three sets?
>
> A) values given explicitly by the user (== IC == running config)
> B) current values which use organization identical to (A)
> C) current values which are not organized identical to (A)
>
> I think the real key is that values which _can_ be organized by the
> data models used in (A) _should_ use identifical organization in (B).
> When I read openconfig, that seems to be their real requirement.
>
> So if (A) has duplex or OSPF peers or interfaces, then (B) will
> list duplex state, peer state, and interface state using an identical
> organization (in terms of parentage or containers, lists, and keys).
>
> Once the concepts are clear, selecting terminology should be easier.
> I'd actually prefer terms like "primary state" and "secondary state"
> which force the reader to look up their meaning to terms like
> "derived state" which the reader will likely assume they know the
> meaning of.  Clean terms really help with understanding and discussions
> especially when the audience grows beyond the key players active
> here.
>
> Should a request for better terms be a new, distinct issue?
>
> Andy B. writes:
> >> I do not agree at all that the running datastore means anything other
> >> than the intended confg.   A new operation is needed to retrieve
> >> the active config vs. the intended config.
>
> Do we have a definition for "active config"?  Is this running config
> or the parts of AC that are fed by IC?
>
> Robert Wilton writes:
> >If the running datastore only ever means intended config, then I think
> >that would imply:
> >
> >  - existing NETCONF servers should reply immediately after the config
> >has been semantically verified + written to the config subsystem before
> >the configuration is applied.
>
> The running datastore is definitely only intended config.
>
> My question is what "the configuration change MUST also be applied
> in the system" means in a world of a hundred FRUs with a zillion
> chips.  Does an "applied" MTU mean it hits the kernel, the embedded
> FRU, or the final chip with enforces the MTU?  Does an "applied"
> BGP peer mean an open connection or full route exchange and FIB
> update?  There's a lot of gray space here.
>
> The original NETCONF view is that when the config is atomically
> accepted as the new, valid config, it's done.  Are we really talking
> about changing that?
>
> You see the same issue with AC's used of "particular software
> modules", where any piece of functionality might well be a distributed
> set of software instances, often with differing code (kernel,
> embedded, chip).
>
> FWIW, in JUNOS we show configuration from the configuration database
> and _most_ operational commands from the routing engine, either
> from its kernel or the daemons running on it.  We expect the kernel
> to propagate an MTU as needed without asking the embedded FRU or
> chips for their view of the MTU.
>
> >  - the existing NETCONF/RESTCONF protocols has no direct mechanism for
> >indicating a failure to apply any configuration leaf, the only way such
> >information could be deduced is through related operational state leaves
> >or notifications.
>
> True, and this is one of the thing I think openconfig hopes to
> address, by allowing apps that fetch IC, fetch AC, and diff them
> (with suitable diff logic), which stresses the importance of
> reusing organization.
>
> Thanks,
>  Phil
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

Perhaps the operational requirement=
s are not that clear, so
the terminology is also not that clear?<=
/div>

Is there really a requirement to know detailed inf=
o about the
differences between intended and applied config?

It seems like the general requirement is that the clie=
nt
needs to know when it can start using the network resource
that has been added or modified in the intended config.
There are 2 modes that fall out from this requirement:
=C2=A0 1) synchronous: do not return from this RPC until resources are r=
eady
=C2=A0 2) asynchronous: return right away from this RPC, and=
 inform the client
=C2=A0 =C2=A0 =C2=A0 =C2=A0when the resources =
are ready (could indicate ready in the RPC response)


Andy



On Tue, Sep 29, 2015 at 11:=
37 AM, Phil Shafer <phil@juniper.net> wrote:
Semi-in-reply-to: <560AA471.3050307@cisco.com>



I keep thinking the terms in the draft somewhat confusing.=C2=A0 Okay,

confusing isn't exactly right.=C2=A0 I find the terms have a lot of

background that needs to be explained that's not obvious from the

simple explanations in the draft.=C2=A0 The reader will see these terms

and think they know what they mean without that deeper understanding.



For example:



=C2=A0 =C2=A0o=C2=A0 applied configuration - this data represents the state=
 that the

=C2=A0 =C2=A0 =C2=A0 network element is actually in, i.e., that which is cu=
rrently

=C2=A0 =C2=A0 =C2=A0 being run by particular software modules (e.g., the BG=
P daemon),

=C2=A0 =C2=A0 =C2=A0 or other systems within the device (e.g., a secondary =
control-

=C2=A0 =C2=A0 =C2=A0 plane, or line card).



This says nothing about how the current state relates to the

configuration.=C2=A0 The term "applied configuration" would imply=
 that

this state is driven by configuration, but there's really nothing

here addressing that.=C2=A0 Does config for interfaces that don't exist=


appear in AC?=C2=A0 Do implicit peers appear along side explicitly

configured ones?



Likewise:



=C2=A0 =C2=A0o=C2=A0 derived state - this data represents information which=
 is

=C2=A0 =C2=A0 =C2=A0 generated as part of the system's own interactions=
.=C2=A0 For example,

=C2=A0 =C2=A0 =C2=A0 derived state may consist of the results of protocol i=
nteractions

=C2=A0 =C2=A0 =C2=A0 (the negotiated duplex state of an Ethernet link), sta=
tistics

=C2=A0 =C2=A0 =C2=A0 (such as message queue depth), or counters (such as pa=
cket input

=C2=A0 =C2=A0 =C2=A0 or output bytes).



There's nothing that clearly delineates DS from AC.=C2=A0 The switch
from "state" to "information" doesn't really add an=
ything concrete.

Why is AC state but DS information?



How does one decide which category any particular leaf belongs in?

Does "protocol interactions" include ospf peers, their status, an=
d

learned routes?=C2=A0 Is this the same for both explicitly configured

peers and unconfigured peers (set protocols ospf interface ge-0/0/0)?



I wouldn't have thought duplex as derived state, given that I can

configure a value for it.



Would it be better to think of these values in three sets?



A) values given explicitly by the user (=3D=3D IC =3D=3D running config)
B) current values which use organization identical to (A)

C) current values which are not organized identical to (A)



I think the real key is that values which _can_ be organized by the

data models used in (A) _should_ use identifical organization in (B).

When I read openconfig, that seems to be their real requirement.



So if (A) has duplex or OSPF peers or interfaces, then (B) will

list duplex state, peer state, and interface state using an identical

organization (in terms of parentage or containers, lists, and keys).



Once the concepts are clear, selecting terminology should be easier.

I'd actually prefer terms like "primary state" and "seco=
ndary state"

which force the reader to look up their meaning to terms like

"derived state" which the reader will likely assume they know the=


meaning of.=C2=A0 Clean terms really help with understanding and discussion=
s

especially when the audience grows beyond the key players active

here.



Should a request for better terms be a new, distinct issue?



Andy B. writes:

>> I do not agree at all that the running datastore means anything ot=
her

>> than the intended confg.=C2=A0 =C2=A0A new operation is needed to =
retrieve

>> the active config vs. the intended config.



Do we have a definition for "active config"?=C2=A0 Is this runnin=
g config

or the parts of AC that are fed by IC?



Robert Wilton writes:

>If the running datastore only ever means intended config, then I think<=
br>
>that would imply:

>

>=C2=A0 - existing NETCONF servers should reply immediately after the co=
nfig

>has been semantically verified + written to the config subsystem before=


>the configuration is applied.



The running datastore is definitely only intended config.



My question is what "the configuration change MUST also be applied

in the system" means in a world of a hundred FRUs with a zillion

chips.=C2=A0 Does an "applied" MTU mean it hits the kernel, the e=
mbedded

FRU, or the final chip with enforces the MTU?=C2=A0 Does an "applied&q=
uot;

BGP peer mean an open connection or full route exchange and FIB

update?=C2=A0 There's a lot of gray space here.



The original NETCONF view is that when the config is atomically

accepted as the new, valid config, it's done.=C2=A0 Are we really talki=
ng

about changing that?



You see the same issue with AC's used of "particular software

modules", where any piece of functionality might well be a distributed=


set of software instances, often with differing code (kernel,

embedded, chip).



FWIW, in JUNOS we show configuration from the configuration database

and _most_ operational commands from the routing engine, either

from its kernel or the daemons running on it.=C2=A0 We expect the kernel
to propagate an MTU as needed without asking the embedded FRU or

chips for their view of the MTU.



>=C2=A0 - the existing NETCONF/RESTCONF protocols has no direct mechanis=
m for

>indicating a failure to apply any configuration leaf, the only way such=


>information could be deduced is through related operational state leave=
s

>or notifications.



True, and this is one of the thing I think openconfig hopes to

address, by allowing apps that fetch IC, fetch AC, and diff them

(with suitable diff logic), which stresses the importance of

reusing organization.



Thanks,

=C2=A0Phil



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1134079892b1900520e7d741--


From nobody Tue Sep 29 12:53:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCB51B4E3A for ; Tue, 29 Sep 2015 12:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc4Id59kHrnE for ; Tue, 29 Sep 2015 12:53:14 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2201F1B4E39 for ; Tue, 29 Sep 2015 12:53:13 -0700 (PDT)
Received: from BL2PR05CA0035.namprd05.prod.outlook.com (10.255.226.35) by BN1PR05MB060.namprd05.prod.outlook.com (10.255.202.153) with Microsoft SMTP Server (TLS) id 15.1.274.16; Tue, 29 Sep 2015 19:53:11 +0000
Received: from BL2FFO11FD018.protection.gbl (2a01:111:f400:7c09::113) by BL2PR05CA0035.outlook.office365.com (2a01:111:e400:c04::35) with Microsoft SMTP Server (TLS) id 15.1.280.20 via Frontend Transport; Tue, 29 Sep 2015 19:53:11 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD018.mail.protection.outlook.com (10.173.161.36) with Microsoft SMTP Server (TLS) id 15.1.274.4 via Frontend Transport; Tue, 29 Sep 2015 19:53:11 +0000
Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Sep 2015 12:53:09 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t8TJr8D20948;	Tue, 29 Sep 2015 12:53:08 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t8TJpBtC024925; Tue, 29 Sep 2015 15:51:11 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201509291951.t8TJpBtC024925@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Tue, 29 Sep 2015 15:51:10 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD018; 1:DQdvKih+YmNa5jNeFZC6sJTB6ixBJnBlkdCfijYqHlilZ8wusM8nTQnGYbWE7j97dFuMyUFbwvAyQ7hPn9/zCnOGB3vVZECt7XXi0TNxcDZvZWg3omqnbbQvMYLs9PnyJrnsLopFYb9zuS+NIDd0Wwuf/2yemDXiPguYS6qNH+04fe3Y0bRcMj+PnLRVhry/l0N/l5sPLGnS+4mGryng8HG+hIalYTcx3mVkJA19+yqpbu4tTNmxZk80gjWl28xvCYfLslhJ7GcIt/8wmSuPGwjWkhlh8fgh1gZpM0UD2QHNqzDWJuzmpvhHIwby45NZkpJ9YAxRukDAlzSuJ5rqAdM89/g+asKqOfRQZ8cZjmzuNT/9Mh6WMpz7PzBamtEW
X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(164054003)(199003)(97736004)(50466002)(87936001)(2950100001)(47776003)(48376002)(64706001)(5001960100002)(189998001)(5003600100002)(6806005)(68736005)(5003940100001)(77096005)(110136002)(5001830100001)(81156007)(5001860100001)(4001540100001)(92566002)(54356999)(50986999)(5007970100001)(86362001)(53416004)(69596002)(11100500001)(77156002)(105596002)(76506005)(62966003)(5008740100001)(106466001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB060; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB060; 2:hXsW7CBr2RaoCZDUI4HtKqcvs3w/ulAcwJiwFQqFvEPnaGaUiE+s+11VeEzxlHaPGYTis/GxeF4aYkw32ipMVSz1JYmYTusU8CiAKOgT8djGIMH0FP1+NV/pql67bL6NkizuuDwjmrlknt2td/gc5dPUqEyM5BlXfZLySU90454=; 3:c1Orcv98R/K8W5VTNKGkvfyi51rgk84vIK/uAtlIoqdZRAmqiUS9jeF2Th8AGh375bLUx+0PkJAhF0DZDXYX4ZTk70dF20O4N1aPE4gKsnJvUBvSHNnlldCkp/KiVltG4dONCAYXS8OA/ZZzgujniTQVEJ/EfysTMbvHfYAYINZfUv7OYbviV4+7Mn/KDkUIUCr6lYlNbGu4jYNRjF2/3drETT30JgK80069zqfGfyE=; 25:Gtqn4Z4FOqJnyNwlLrzF2AFGaeZ1G9errwDB1F0EqowDdO0fQ4cJQA+UtJNN3kvLjuK675Pr/mSZv34214h78TwBWCv+rspy5bexmKnElN+IqMIzC/CqL750lbx9UoZX770A13vq7llfuMPJZ0x/LQg+4NvQzlsoc1VQC150gCpT4hG2QywEaXDH+AHAfGRmCm/0oRJfu9J/Pdbbjnm1bWv4qI8yjQKkblz2TYkEJ1nYXz8ghL9NpAKmUG5Vax5U4JQOYjfgI6R6LjJm42pisw==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB060;
X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB060; 20:5Qme/+s/wj1ajfBalzkOO37zpwN2/fzqxNhXMuJ1+g+oY0vGXDDAd4Vgt8Ux0gYnGEQ6EbYC6/a70vILA+OsEEgBn1v2D5GRDuUX88byC1+pU/kA6NO+RITY/s3B3RqkKGiRQuJEQa6RgRos/qmLBCkY/BAVwuMTZS8qjIPjJXb0m8Ut5eTWFwfd4VfsgqP0vN0SHwRTspwrzNRhWX9I4Zuk3O8GboczLvVMQvpZjRUwjK25UQ7NpVa51S0J87YaT1PqsMwm1AAwRb9YWt94ls1NsdCLIpQC1AZaUrvbYLLDogf/lu6MAmH3JBb9Wrtvbkm9lRG0Ndo/lSrrdwH5SKYsUaOG7ESXEcF/hb1caNTj6eQB3zKlInz3lZuvyNqfxbN9aV1Ml+3qY9wd4Yozzkl/zYCcbogT2p+52mZyEQ7408Yc2jEOx6H3tN4d7bxS/ufbixH8nJWRu9IU4f6CNwzzW2u7QkNyDEzZFDWdAOBMMy//QLTj/pGL3ZxchxsK; 4:8ed0/m2Slg7EO8zqKknvFB+kl087rOBNZkRAbDTE4YxHCLgySP10mWI7zFLMJ+6rkYN9i5DFN3NYhSUMRAtjJzNMej4fZk7bCJlBjicEp8iyMytIo2vTqFcdPoPbJAZgwoYrrcgNGF+xLUzRy1ddDm0gJberQ5PEAci6x1RGB5H+X+UW/o8EEkdQKzADNSQ+T7QgRrPMlIxwF0X3HExZyMvjmpme6m4CSDHAisHdYr8uY4RvlccMoTfzbsnA+zzuSGJKQ7tQA+YOz4WT17uq/0UeZkVGq7W/rtfeXOx9LiqJP5hc+46igJeF/Mz6kgPsUIuyqEHoFwyc4fOn55RaffO3qwgJQedABP4tYEEY4Kc=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BN1PR05MB060; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB060; 
X-Forefront-PRVS: 0714841678
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB060; 23:rxyco6UhqwngUeKkAuxW1PKhwNL4WnKopr5EuWTQPQ?= =?us-ascii?Q?uA4l+7rUn3ghRFsx6NhaLrNHlVi152gizcURATRLmY1YNHAilOUbhyu03W1q?= =?us-ascii?Q?9EQP0FSZoUPUUeS/ux5/0ACsW1AJglLHABrRUevFaa60G9NNfShbwUR/fNUc?= =?us-ascii?Q?+AGJGlEOi17qpcRW6Bx128ebI1L31StwN+KhvGq3rVFunf3ZD7M0UJAZoTfV?= =?us-ascii?Q?1DrRoL9vyZmADR19eJ1qNbK+YjjtM5sgcY10zHkUCGeJdXE5dXVxIn3Lb/nT?= =?us-ascii?Q?NmJ7ytVhhson4x04Ne8CjUs4MAAFPuKfD09vfb5fy5A2IufOnBFzA11KVhqj?= =?us-ascii?Q?WVervEkh4qwQ/GcD2R+uoiCuz22Ic57SEL/OCAPv0m9lHEu9Rw+6Gw4U2PHc?= =?us-ascii?Q?hTMbuIyNfCvJi9FVB7dn0HXS8k9nbN3YxIx5hsnfuHviPbF9acSVtExr9AMs?= =?us-ascii?Q?Oim3peW7HKHbfvCaUVm1na1L3/z9vBI5Lf5cykC+503YVIAR4I1ftm2Uc+EJ?= =?us-ascii?Q?vSTvHo0g2Ifk9qUn1Nzs+y2JXsC29iNk2NRY9aadaMhLxgXf7GjkHJOnWii8?= =?us-ascii?Q?e4b/5vVdJaYYCWEgjrhvmH4270lZOabu3mcPnv8499aQhh87myny4uWvkDxM?= =?us-ascii?Q?bdymXDrdfrhSRc5BnVCK0JCxKjdh3CBRSj5huOaEbmEQD+hY+gyDCG5AZLcm?= =?us-ascii?Q?2KVIp9HBNDCwcftseiWyNTKhO+SDmnvdQodksA1v7zaQpj4sinoZesgRzi0t?= =?us-ascii?Q?GIkUTnHdm6OVFCjHD2hT65IlAZMFXzjHAK+YNqyyEeSGr+Kp5tz4KUQqvioK?= =?us-ascii?Q?LGUdU+o8kGCN4gAIIuRAXSfKo/9Q9u7NeasE8pm52pqn9TVJEDqhH3F/SFwC?= =?us-ascii?Q?1/SE8CJkI5UeOuIlt86o8Pwhg2lMCA146HcMTCAtazC4+eQdJAeNYG+dCOXT?= =?us-ascii?Q?u3fHb0iBAGaGOaftzV4Ir72XGizC5c4uAGeJ0TJZ81VES7HbH2czlQEGsFLs?= =?us-ascii?Q?MCLMc6ZeVQYYYfBkl1zHgIL3vr3u5nM64EZDypY9nuDNo9JB5ot+m489sUaC?= =?us-ascii?Q?bVByzX5j3eR7Ib/pIze03uiuJ8T73a9COcc2/rxT+o9nKYOw=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB060; 5:5FLhaGRqmIQsFpmL5ETA5NeyKSq1yrPCjLewZggiSMEcIS/LbLj31wuW/XUZG/xp7BMIZ/MmfQujUqhRYYGVDyJW1i+V3ejyZaoAb68eT3GYONNdbzYHOTE5Vi0h7Gqae0/YW3yp5S9hwOIyB4JR8Q==; 24:jssIL9l9RN2Zww1x9Z8RDHrlAXGODOXsmelM3FAIuE1km01+WG+tX1MUJMubViLtFfkeu7+5aPtAnFIq10gTmJO0Y+WD5U0/CLGJUaonVcA=; 20:akQbrboMvPSPXf76vJL3SQgytnVDbpqOysz8gs7fgIheNZfr79q/HoRrx9wDgiX5CfpaXHwZHmeAjjnd7jw09w==
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2015 19:53:11.2711 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01b-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB060
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs: terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 19:53:17 -0000

Andy Bierman writes:
>Perhaps the operational requirements are not that clear, so
>the terminology is also not that clear?

Are we trying to agree on the former without the later?

>Is there really a requirement to know detailed info about the
>differences between intended and applied config?

I'm assuming this will end up impacting either netconf operations
or yang data model construction.  At that point (if not before),
we'll need clear terms for app writers and data modelers.

>It seems like the general requirement is that the client
>needs to know when it can start using the network resource
>that has been added or modified in the intended config.

Consider that case where you add interface config for an interface
FRU that's not been inserted.  This config might not be used for
months, until the tech inserts the FRU.

>There are 2 modes that fall out from this requirement:
>  1) synchronous: do not return from this RPC until resources are ready
>  2) asynchronous: return right away from this RPC, and inform the client
>       when the resources are ready (could indicate ready in the RPC response)

Given the inherently squishy definition of "ready", I'd prefer to avoid #1.

Thanks,
 Phil


From nobody Tue Sep 29 12:53:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7214F1B4E3E for ; Tue, 29 Sep 2015 12:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q85rnsFuAKXs for ; Tue, 29 Sep 2015 12:53:19 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 1C7141B4E39 for ; Tue, 29 Sep 2015 12:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1443556310; bh=gSGD92eWhV7s51ioBCd7hTO6SPp344zyI7tQHoeVXMQ=; h=From:Subject:Date:To; b=rtJ6CiejN2dj+FSiROwv3Eiv/a16gWO4HSauVYvUghjbP3g0BDJqwBf8iSSHwpEp3 4o0n2ICHzT+uB7rbizrDfBoLSlmdOt1OndOrIebURWAlayI5bO/Gut4+xkkqZ3OX5J 2AaFWC8Er1ewiBXooSCNm5atRSd7w9Yc7FarhzNc=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Tue, 29 Sep 2015 15:53:15 -0400
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=10 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 137, in=1706, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Subject: [netmod] Thursday Interim Meeting Agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 19:53:20 -0000

	After going over the plan with Kent, we would like to continue =
the agenda from the
last interim meeting on Thursday. That is to say, Kent will continue =
with the comparison
of solutions.  =46rom last time and in parallel with this, the WG =
discussion around the requirements=20
seems to be converging on a detailed level of refinement of the =
requirements.  We will
recap the status here and goals.

	The details of the meeting are here:


The NETCONF Data Modeling Language (netmod) Working Group will hold a =
virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am =
PDT; 2pm GMT).

The title is =E2=80=9COpenconfig Solutions Discussion (continued)=E2=80=9D=
.

The WebEx is:

Meeting number:640 686 530
Meeting password:1234
Audio connection:
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 640 686 530
Meeting link: =
https://ietf.webex.com/ietf/j.php?MTID=3Dmf12aa8d28a159614cb415f2f32dcbebf=




	--Tom (as WG co-chair)



From nobody Tue Sep 29 13:23:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA7F1B4FD5 for ; Tue, 29 Sep 2015 13:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDir88hqgmgX for ; Tue, 29 Sep 2015 13:23:02 -0700 (PDT)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 BBD141B4FD2 for ; Tue, 29 Sep 2015 13:23:01 -0700 (PDT)
Received: by laer8 with SMTP id r8so22511898lae.2 for ; Tue, 29 Sep 2015 13:22:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pqROft8fNs0ApkRCgvzyEBnfK6JK+RQGOFYXd/zogCA=; b=W21IUskAjSGfX1IRyH6ximn/SCXIpDMBY1lO++oli0drWyY12aQDTyhph32mG1DQeK uOM9p1JCOv7il2VbnT7AOGX9Q3CAbDfw3BARBCYYZNikzWnZTYUVsZOO50loh7a4JBHH iniU3ad9BhbmaelOCmFAj2nmI9kLdUisGZ7niesKx0Zr/rtnF3s9BgO4+q2EIJhtU0eX CPGd9y0egfL5yh6ipbpXfobXghcDzTcCb0zgcFpWae7maJ+dWgDeJRqGhW/tbdBxdWQE S/EdX8IQbbfZ4HFBB7TAwhFkAOCxypErH6X1ghr/N5niiHvJdXA9MhIuRf0gGMs26WS3 3bUA==
X-Gm-Message-State: ALoCoQmAR/KT/uHLwkvoEBj2cisuUEr+xlpJxgHQKqAs8f4Um7lRwyr+lVC+jlrRWAiyDtvKuzmz
MIME-Version: 1.0
X-Received: by 10.25.150.83 with SMTP id y80mr5020652lfd.119.1443558179278; Tue, 29 Sep 2015 13:22:59 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Tue, 29 Sep 2015 13:22:59 -0700 (PDT)
In-Reply-To: <201509291951.t8TJpBtC024925@idle.juniper.net>
References:  <201509291951.t8TJpBtC024925@idle.juniper.net>
Date: Tue, 29 Sep 2015 13:22:59 -0700
Message-ID: 
From: Andy Bierman 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=001a11401a247d2cf90520e894e9
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs: terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Sep 2015 20:23:04 -0000

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

On Tue, Sep 29, 2015 at 12:51 PM, Phil Shafer  wrote:

> Andy Bierman writes:
> >Perhaps the operational requirements are not that clear, so
> >the terminology is also not that clear?
>
> Are we trying to agree on the former without the later?
>
> >Is there really a requirement to know detailed info about the
> >differences between intended and applied config?
>
> I'm assuming this will end up impacting either netconf operations
> or yang data model construction.  At that point (if not before),
> we'll need clear terms for app writers and data modelers.
>
>

I don't have any objection to "intended" and "applied" as terms.


> >It seems like the general requirement is that the client
> >needs to know when it can start using the network resource
> >that has been added or modified in the intended config.
>
> Consider that case where you add interface config for an interface
> FRU that's not been inserted.  This config might not be used for
> months, until the tech inserts the FRU.
>
>

Clearly a case where the client should pick (2)



> >There are 2 modes that fall out from this requirement:
> >  1) synchronous: do not return from this RPC until resources are ready
> >  2) asynchronous: return right away from this RPC, and inform the client
> >       when the resources are ready (could indicate ready in the RPC
> response)
>
> Given the inherently squishy definition of "ready", I'd prefer to avoid #1.
>


None of the protocols actually tell the client which one they did, for a
given edit.
I agree the best we could say is "I think it's ready right now".
However, I think even this much could require massive code changes in many
systems.



> Thanks,
>  Phil
>


Andy

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




On Tue, Sep 29, 2015 at 12:51 PM, Phil Shafer <phil@juniper.net>=
 wrote:
Andy Bierman writes:

>Perhaps the operational requirements are not that clear, so

>the terminology is also not that clear?



Are we trying to agree on the former without the later?



>Is there really a requirement to know detailed info about the

>differences between intended and applied config?



I'm assuming this will end up impacting either netconf operations

or yang data model construction.=C2=A0 At that point (if not before),

we'll need clear terms for app writers and data modelers.




I don't have any ob=
jection to "intended" and "applied" as terms.
=C2=A0

>It seems like the general requirement is that the client

>needs to know when it can start using the network resource

>that has been added or modified in the intended config.



Consider that case where you add interface config for an interface

FRU that's not been inserted.=C2=A0 This config might not be used for
months, until the tech inserts the FRU.




Clearly a case where th=
e client should pick (2)

=C2=A0

>There are 2 modes that fall out from this requirement:

>=C2=A0 1) synchronous: do not return from this RPC until resources are =
ready

>=C2=A0 2) asynchronous: return right away from this RPC, and inform the=
 client

>=C2=A0 =C2=A0 =C2=A0 =C2=A0when the resources are ready (could indicate=
 ready in the RPC response)



Given the inherently squishy definition of "ready", I'd prefe=
r to avoid #1.


None of t=
he protocols actually tell the client which one they did, for a given edit.=

I agree the best we could say is "I think it's ready ri=
ght now".
However, I think even this much could require mass=
ive code changes in many systems.





Thanks,

=C2=A0Phil




Andy



--001a11401a247d2cf90520e894e9--


From nobody Tue Sep 29 23:47:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4701A037E for ; Tue, 29 Sep 2015 23:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-cGRQT9DEQ7 for ; Tue, 29 Sep 2015 23:47:37 -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 15ACB1A035F for ; Tue, 29 Sep 2015 23:47:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8677C101C; Wed, 30 Sep 2015 08:47:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xDPN0KMlZhFw; Wed, 30 Sep 2015 08:47: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; Wed, 30 Sep 2015 08:47:34 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1B3A20053; Wed, 30 Sep 2015 08:47:34 +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 ZSa8UM6SF1Ov; Wed, 30 Sep 2015 08:47:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA1892004E; Wed, 30 Sep 2015 08:47:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 91F28376A0C9; Wed, 30 Sep 2015 08:47:32 +0200 (CEST)
Date: Wed, 30 Sep 2015 08:47:31 +0200
From: Juergen Schoenwaelder 
To: Nadeau Thomas 
Message-ID: <20150930064731.GA979@elstar.local>
Mail-Followup-To: Nadeau Thomas , Robert Wilton , "netmod@ietf.org" 
References:  <5603F9C2.2000500@cisco.com>  <5609749D.90207@cisco.com>  <560AA471.3050307@cisco.com> <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.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: <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 06:47:39 -0000

On Tue, Sep 29, 2015 at 01:56:56PM -0400, Nadeau Thomas wrote:
> 
> 	Robert,
> 
> 	It seems this discussion has run out of steam and we’ve come to a head on this issue.
> It seems we have some actions we can take based on the list of three bullets below as part of
> that conclusion (potentially).  
> 
> 	Do folks think we are ready to close this issue down officially?
>

Tom,

what do you think is the outcome of the discussion? This is not at all
clear to me so how can I say we are done with it...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 30 02:52:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B201B2DA0 for ; Wed, 30 Sep 2015 02:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCy1I4u3DjD9 for ; Wed, 30 Sep 2015 02:52:32 -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 4BB301B2D9F for ; Wed, 30 Sep 2015 02:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12341; q=dns/txt; s=iport; t=1443606752; x=1444816352; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=dXrDn9Bm6crS0hcZT/IW/nMPTHFcgiuqWDQuS9LXqb0=; b=dNLpljGBa6+hnDTwIyuF8d6Zlug23vCTEIT6JUBVo/uFjtqI2Fy/Beu9 8bBkpDKQbhcLRXvSLpwBoBhmNq8/7nYqqOQl+d/bcBWLxJkrDbZBskOBY em2xE0W0hh3OwCkz5zbBrTRX9ue7SSer6tnURLx5fyCmwp2UFGcv7hSLN 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CvBACQsAtW/xbLJq1eg3hpgyu8QQEJhS9KAoF+AQEBAQEBgQuEJQEBBAEBASAkJwoBEAsOCgkWBAQDAgIJAwIBAgEVHxEGDQYCAQEXiBMNtmGFHI9QAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGc4R9hEJLB4JpgUMFlXiNE4kFkktjgkSBPz0ziR4BAQE
X-IronPort-AV: E=Sophos;i="5.17,611,1437436800";  d="scan'208,217";a="605449886"
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; 30 Sep 2015 09:52:30 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8U9qTeY032285; Wed, 30 Sep 2015 09:52:29 GMT
To: Nadeau Thomas 
References:  <5603F9C2.2000500@cisco.com>  <5609749D.90207@cisco.com>  <560AA471.3050307@cisco.com> <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.com>
From: Robert Wilton 
Message-ID: <560BB0DD.8050508@cisco.com>
Date: Wed, 30 Sep 2015 10:52:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.com>
Content-Type: multipart/alternative; boundary="------------070105040507040205060408"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 09:52:35 -0000

This is a multi-part message in MIME format.
--------------070105040507040205060408
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Tom,

I'm not sure that this discussion has completely reached a conclusion 
with regard to how existing netconf servers are defined as behaving.

But my view is that the requirements are well enough understood that we 
can have a useful discussion on the merits of the proposed solutions, 
and that discussing the possible solutions in the meeting on Thursday 
will be more enlightening than spending further time debating the exact 
semantics of the requirements.

Thanks,
Rob


On 29/09/2015 18:56, Nadeau Thomas wrote:
>
> Robert,
>
> It seems this discussion has run out of steam and we’ve come to a head 
> on this issue.
> It seems we have some actions we can take based on the list of three 
> bullets below as part of
> that conclusion (potentially).
>
> Do folks think we are ready to close this issue down officially?
>
> —Tom
>
>
>> On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton 
>> > wrote:
>>
>>
>>
>> On 28/09/2015 18:17, Andy Bierman wrote:
>>>
>>>
>>> On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton >> > wrote:
>>>
>>>     Hi Andy,
>>>
>>>
>>>     On 24/09/2015 19:22, Andy Bierman wrote:
>>>>     Hi,
>>>>
>>>>     I find this exercise to classify servers as synchronous or
>>>>     asynchronous mostly useless.
>>>>     We have both types of instrumentation in our server. They can
>>>>     be different
>>>>     on a per-node basis.  They can both take a long time or both be
>>>>     instant, depending
>>>>     on the instrumentation code the vendor writes.
>>>>
>>>>     In any case, the server does not know if the instrumentation
>>>>     has finished making
>>>>     the network behave according to the new edit.  That would be
>>>>     new functionality that
>>>>     no vendor supports at this time.  Currently servers return "ok"
>>>>     if the edit is accepted
>>>>     into the running datastore. There are no other semantics wrt/
>>>>     returning "ok".
>>>
>>>     I'm not sure whether we agree here, but as stated previously,
>>>     Sec 5.1 of RFC 6241, implies that if the configuration is in the
>>>     running datastore then that configuration is expected to be
>>>     active on the device.
>>>
>>>
>>> I do not agree at all that the running datastore means anything other
>>> than the intended confg.   A new operation is needed to retrieve
>>> the active config vs. the intended config.
>>
>> If the running datastore only ever means intended config, then I 
>> think that would imply:
>>
>>  - existing NETCONF servers should reply immediately after the config 
>> has been semantically verified + written to the config subsystem 
>> before the configuration is applied.
>>
>>  - existing NETCONF servers are logically classified (as per 
>> openconfig-netmod-opstate) as being asynchronous w.r.t to the config 
>> requests.
>>
>>  - the existing NETCONF/RESTCONF protocols has no direct mechanism 
>> for indicating a failure to apply any configuration leaf, the only 
>> way such information could be deduced is through related operational 
>> state leaves or notifications.
>>
>> Rob
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
>


--------------070105040507040205060408
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Tom,

    

    I'm not sure that this discussion has completely reached a
    conclusion with regard to how existing netconf servers are defined
    as behaving.

    

    But my view is that the requirements are well enough understood that
    we can have a useful discussion on the merits of the proposed
    solutions, and that discussing the possible solutions in the meeting
    on Thursday will be more enlightening than spending further time
    debating the exact semantics of the requirements.

    

    Thanks,

    Rob

    

    

    
On 29/09/2015 18:56, Nadeau Thomas
      wrote:

    

    

      
      


      

      
	Robert,

      


      

      
	It
        seems this discussion has run out of steam and we’ve come to a
        head on this issue.  

      
It seems we have some actions we can take based on
        the list of three bullets below as part of

      
that conclusion (potentially).  

      


      

      
	Do
        folks think we are ready to close this issue down officially?

      


      

      
	—Tom

      


      

      

      

        

          
On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert
            Wilton <rwilton@cisco.com>
            wrote:

          

          

            
 

              

              
On 28/09/2015 18:17, Andy
                Bierman wrote:

              

              

                


                  


                    
On Mon, Sep 28, 2015 at
                      10:10 AM, Robert Wilton <rwilton@cisco.com>
                      wrote:

                      

                        

                          Hi Andy,

                          

                          

                          
On 24/09/2015 19:22, Andy
                            Bierman wrote:

                          

                          

                            
Hi,
                              


                              

                              
I find this exercise to
                                classify servers as synchronous or
                                asynchronous mostly useless.

                              
We have both types of
                                instrumentation in our server. They can
                                be different

                              
on a per-node basis.  They
                                can both take a long time or both be
                                instant, depending

                              
on the instrumentation code
                                the vendor writes.

                              


                              

                              
In any case, the server does
                                not know if the instrumentation has
                                finished making

                              
the network behave according
                                to the new edit.  That would be new
                                functionality that

                              
no vendor supports at this
                                time.  Currently servers return "ok" if
                                the edit is accepted

                              
into the running datastore. 
                                There are no other semantics wrt/
                                returning "ok".

                            

                          

                          

                          I'm not sure whether we agree here, but as
                          stated previously, Sec 5.1 of RFC 6241,
                          implies that if the configuration is in the
                          running datastore then that configuration is
                          expected to be active on the device.

                          

                        

                      

                      


                      

                      
I do not agree at all that the
                        running datastore means anything other

                      
than the intended confg.   A new
                        operation is needed to retrieve

                      
the active config vs. the intended
                        config.

                    

                  

                

              

              

              If the running datastore only ever means intended config,
              then I think that would imply:

              

               - existing NETCONF servers should reply immediately after
              the config has been semantically verified + written to the
              config subsystem before the configuration is applied.

              

               - existing NETCONF servers are logically classified (as
              per openconfig-netmod-opstate) as being asynchronous w.r.t
              to the config requests.

              

               - the existing NETCONF/RESTCONF protocols has no direct
              mechanism for indicating a failure to apply any
              configuration leaf, the only way such information could be
              deduced is through related operational state leaves or
              notifications.

              

              Rob

              

            

            _______________________________________________

            netmod mailing list

            netmod@ietf.org

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

          

        

      

      

    

    

  


--------------070105040507040205060408--


From nobody Wed Sep 30 02:56:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3181B2DB2 for ; Wed, 30 Sep 2015 02:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu8rmTiFvS-O for ; Wed, 30 Sep 2015 02:56:16 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 828A71B2DB1 for ; Wed, 30 Sep 2015 02:56:16 -0700 (PDT)
Received: (qmail 24540 invoked by uid 0); 30 Sep 2015 09:56:13 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 30 Sep 2015 09:56:13 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id PMw41r00V2SSUrH01Mw7Le; Wed, 30 Sep 2015 03:56:11 -0600
X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=-_JJqrS2NaAA:10 a=ff-B7xzCdYMA:10 a=T0ZuanxOAAAA:8 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=1uWK3vrQX0JosYssg8oA:9 a=d7Sw58Zuviv5WBUp:21 a=mS134G1rIYR5E66p:21 a=QEXdDO2ut3YA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=9uUzcS5Nrb8A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=xaeCDWh3aJO05gXbxhhFjRb0GgHHxJH2txV64AGNGGw=;  b=vF36VrH88RzYTk+VerKCK9YhX9uQRyU1mw3hJHQScOfPbU1WkKrW1vmf80DZ/PZpwYprpg16Gmx2OG5K3NU22qUYWZnnfjYaSyRlQ/TBjLVxvm65Ab+EEXjmIx2hECHr;
Received: from [71.191.205.226] (port=48200 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZhE7K-0002ks-5R; Wed, 30 Sep 2015 03:56:06 -0600
From: Lou Berger 
To: Nadeau Thomas , netmod WG 
Date: Wed, 30 Sep 2015 05:56:04 -0400
Message-ID: <1501dae1b68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: 
References: 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 71.191.205.226 authed with lberger@labn.net}
Archived-At: 
Subject: Re: [netmod] Thursday Interim Meeting Agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 09:56:18 -0000

Tom, chairs,

At the last meeting, I believe I heard that a statement of consensus - 
i.e., a consensus call -  on the requirements would be made by the chairs,  
on list. (With the understanding that there are details of the requirements 
that will need to be documented, presumably in a WG version of the chairs 
requirements draft.)

Are we at the point yet were this call can/will be made?

Thanks,
Lou





On September 29, 2015 3:53:56 PM Nadeau Thomas  wrote:

>
> 	After going over the plan with Kent, we would like to continue the agenda 
> from the
> last interim meeting on Thursday. That is to say, Kent will continue with 
> the comparison
> of solutions.  From last time and in parallel with this, the WG discussion 
> around the requirements
> seems to be converging on a detailed level of refinement of the 
> requirements.  We will
> recap the status here and goals.
>
> 	The details of the meeting are here:
>
>
> The NETCONF Data Modeling Language (netmod) Working Group will hold a 
> virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am PDT; 
> 2pm GMT).
>
> The title is “Openconfig Solutions Discussion (continued)”.
>
> The WebEx is:
>
> Meeting number:640 686 530
> Meeting password:1234
> Audio connection:
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 640 686 530
> Meeting link: 
> https://ietf.webex.com/ietf/j.php?MTID=mf12aa8d28a159614cb415f2f32dcbebf
>
>
>
> 	--Tom (as WG co-chair)
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



From nobody Wed Sep 30 03:10:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779531B2DDB for ; Wed, 30 Sep 2015 03:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um6gjpte6Bio for ; Wed, 30 Sep 2015 03:10:26 -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 976A91B2DDE for ; Wed, 30 Sep 2015 03:10:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12198; q=dns/txt; s=iport; t=1443607825; x=1444817425; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=/eg6zoZ9qe8/CtD0131K+vdGc61Ge+MXe9nPj//jrHc=; b=AGWYGvHjS4MPqvEI8OlmSffyKh/pw5i8fbnNEKMis8JpqCHZmqBjXxrb e5YpxmqWaiQyUi0EvoRdSmaZ8OddF4CfYFCTuh0ERvM2GnWIWgjGMMZbD +L+aD3jvzwZkbB7leqTfKONFY1fmi4/UWlZzXZ7oPOGMZ6zvEB06T9EPf A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CgBAAjtAtW/xbLJq1eg3hpv2wBCYUvSgKBfgEBAQEBAYELhCQBAQEDAQEBAWsKAQULCxgJFggHCQMCAQIBFR8RBgEMBgIBAYgiCA3LSgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnODd4EGhEJLB4QsBZJGgzKFfocVgU+HNpJLY4IRHYFVPTOJHgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,611,1437436800";  d="scan'208,217";a="605450193"
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; 30 Sep 2015 10:10:23 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8UAANMW009635; Wed, 30 Sep 2015 10:10:23 GMT
To: Andy Bierman , Phil Shafer 
References:  <201509291951.t8TJpBtC024925@idle.juniper.net> 
From: Robert Wilton 
Message-ID: <560BB50E.5070808@cisco.com>
Date: Wed, 30 Sep 2015 11:10:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060900050908060906010701"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs: terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 10:10:28 -0000

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



On 29/09/2015 21:22, Andy Bierman wrote:
>
>
> On Tue, Sep 29, 2015 at 12:51 PM, Phil Shafer  > wrote:
>
>     Andy Bierman writes:
>     >Perhaps the operational requirements are not that clear, so
>     >the terminology is also not that clear?
>
>     Are we trying to agree on the former without the later?
>
>     >Is there really a requirement to know detailed info about the
>     >differences between intended and applied config?
>
>     I'm assuming this will end up impacting either netconf operations
>     or yang data model construction.  At that point (if not before),
>     we'll need clear terms for app writers and data modelers.
>
>
>
> I don't have any objection to "intended" and "applied" as terms.
+1.

I think that the terms will be fine once we agree on the definitions of 
them, and I think that we probably already agree on "intended".


>     >It seems like the general requirement is that the client
>     >needs to know when it can start using the network resource
>     >that has been added or modified in the intended config.
>
I agree.

Perhaps some wording based around the above might be a better way of 
defining "applied configuration"?

E.g. considering that case where an VPWS service is being provisioned.  
I would expect that a programmatic client might choose to wait until the 
configuration to instantiate the VPWS service has been applied before 
starting to verify the end-to-end connectivity as a pre-requisite to 
using the service.


>
>     Consider that case where you add interface config for an interface
>     FRU that's not been inserted.  This config might not be used for
>     months, until the tech inserts the FRU.
>
>
>
> Clearly a case where the client should pick (2)
>
>     >There are 2 modes that fall out from this requirement:
>     >  1) synchronous: do not return from this RPC until resources are
>     ready
>

For a synchronous request I would suggest that the server should wait 
until it has programmed all resources that are currently available (i.e. 
installed in the system) and to warn on any resources which can't be 
programmed because they are not present. Not returning from a request 
because an item of hardware is physically not present in the system 
doesn't sound like a usable design to me.

>     >  2) asynchronous: return right away from this RPC, and inform
>     the client
>     >       when the resources are ready (could indicate ready in the
>     RPC response)
>
>     Given the inherently squishy definition of "ready", I'd prefer to
>     avoid #1.
>
>
>
> None of the protocols actually tell the client which one they did, for 
> a given edit.

Ideally, I think that it would be good if a server could indicate 
whether it supports (1) or (2) or both, and to allow a client to choose 
which semantics are expected to be used when making the request.

Rob

> I agree the best we could say is "I think it's ready right now".
> However, I think even this much could require massive code changes in 
> many systems.
>
>
>
>     Thanks,
>      Phil
>
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    

    

    
On 29/09/2015 21:22, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Sep 29, 2015 at 12:51 PM,
            Phil Shafer <phil@juniper.net>
            wrote:

            
Andy
              Bierman writes:

              >Perhaps the operational requirements are not that
              clear, so

              >the terminology is also not that clear?

              

              Are we trying to agree on the former without the later?

              

              >Is there really a requirement to know detailed info
              about the

              >differences between intended and applied config?

              

              I'm assuming this will end up impacting either netconf
              operations

              or yang data model construction. At that point (if not
              before),

              we'll need clear terms for app writers and data modelers.

              

            

            


            

            


            

            
I don't have any objection to "intended" and "applied"
              as terms.

          

        

      

    

    +1.

    

    I think that the terms will be fine once we agree on the definitions
    of them, and I think that we probably already agree on "intended".

    

    

    

      

        

          

            

            

              >It seems like the general requirement is that the
              client

              >needs to know when it can start using the network
              resource

              >that has been added or modified in the intended
              config.

            

          

        

      

    

    I agree.

    

    Perhaps some wording based around the above might be a better way of
    defining "applied configuration"?

    

    E.g. considering that case where an VPWS service is being
    provisioned. I would expect that a programmatic client might choose
    to wait until the configuration to instantiate the VPWS service has
    been applied before starting to verify the end-to-end connectivity
    as a pre-requisite to using the service.

    

    

    

      

        

          

            

              

              Consider that case where you add interface config for an
              interface

              FRU that's not been inserted. This config might not be
              used for

              months, until the tech inserts the FRU.

              

            

            


            

            


            

            
Clearly a case where the client should pick (2)

          

        

      

    

    

      

        

          

            


            

            

            

              >There are 2 modes that fall out from this requirement:

              > 1) synchronous: do not return from this RPC until
              resources are ready

            

          

        

      

    

    

    For a synchronous request I would suggest that the server should
    wait until it has programmed all resources that are currently
    available (i.e. installed in the system) and to warn on any
    resources which can't be programmed because they are not present.
    Not returning from a request because an item of hardware is
    physically not present in the system doesn't sound like a usable
    design to me.

    

    

      

        

          

            

              > 2) asynchronous: return right away from this RPC,
              and inform the client

              >   when the resources are ready (could indicate
              ready in the RPC response)

              

              Given the inherently squishy definition of "ready", I'd
              prefer to avoid #1.

            

            


            

            


            

            
None of the protocols actually tell the client which
              one they did, for a given edit.

          

        

      

    

    

    Ideally, I think that it would be good if a server could indicate
    whether it supports (1) or (2) or both, and to allow a client to
    choose which semantics are expected to be used when making the
    request.

    

    Rob

    

    

      

        

          

            
I agree the best we could say is "I think it's ready
              right now".

            
However, I think even this much could require massive
              code changes in many systems.

          

        

      

    

    

      

        

          

            


            

            


            

            

              

              Thanks,

              Phil

            

          

          

        

        


        

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------060900050908060906010701--


From nobody Wed Sep 30 04:01:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D36C1B5D19 for ; Wed, 30 Sep 2015 04:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWWXXY7oVLvU for ; Wed, 30 Sep 2015 04:01:40 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59B1B5D17 for ; Wed, 30 Sep 2015 04:01:40 -0700 (PDT)
Received: from localhost (unknown [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id C4AE91CC008C; Wed, 30 Sep 2015 13:01:49 +0200 (CEST)
From: Ladislav Lhotka 
To: Randy Presuhn , netmod@ietf.org
In-Reply-To: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
References: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 30 Sep 2015 13:01:36 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] 6020bis - anydata
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 11:01:43 -0000

Hi Randy,

thanks for the comments and proposed edits. Please see inline.

Randy Presuhn  writes:

> Hi -
>
>>From: Ladislav Lhotka 
>>Sent: Sep 29, 2015 7:07 AM
>>To: netmod@ietf.org
>>Subject: [netmod] 6020bis - anydata
>>
>>Hi,
>>
>>I propose to expand the text in Sec. 7.10 as follows:
>>
>>OLD
>>
>>   The "anydata" statement is used to represent an unknown set of nodes
>>   that can be modelled with YANG.  An example of where this can be
>>   useful is a list of received notifications, where the exact
>>   notifications are not known as design time.
>>
>>NEW
>>
>>   The "anydata" statement is used to represent an unknown set of nodes
>>   that can be modelled with YANG but for which the data model doesn't
>>   exist at module design time.
>
> "doesn't exist" would not be appropriate for the example you provide
> below.  It would be incorrect if some of the notifications in your
> example had already been defined, even though "anydata" would still
> be necessary to handle others not yet defined.

Would "doesn't exist or cannot be determined at module design time" be better?

>
>>                                At run time, the data model for
>>   "anydata" content MAY be known through protocol signalling or other
>
> This use of "MAY" seems outside the RFC 2119 sense.  Suggested
> replacement:
>
>    It is possible for the data model for "anydata" content to become
>    known through protocol signalling or other

OK.

>
>>   means that are outside the scope of this document, it is however not
>>   required. If the data model is known, implementations MUST treat
>>   "anydata" content exactly as if it was a part of regular data tree.
>
> "of regular" -> "of a regular" -or- "of the regular", depending
> on which it is that you mean

"of a regular", probably - you know, we Slavonic people are really
hopeless when it comes to articles. :-) 

>
> This use of "MUST" seems at odds with section 6 of RFC 2119.
> For example, dynamic lookup of data models could be affected by
> connectivity.  The "MUST" would mean that the observable protocol
> behaviour on the Netconf wire could change, depending on whether
> a schema server happened to be reachable at the moment (or not).

You are right. So it is left to the "other means" to make sure the data
model is observed if necessary.

>
> Suggested replacement:
>
>     When the data model is known (by whatever means) it is possible
>     for implementations to treat "anydata" as a part of the regular
>     data tree.
>
>     When the data model is not known, the following limitations
>     potentially apply:
>        -?

Are there any general limitations? Perhaps the section on XML encoding
could describe in more detail the subset of XML that "can be modelled
with YANG".

>
>>   An example of where this can be useful is a list of received
>>   notifications, where the exact notifications are not known as module
>
>   "as" -> "at"

Actually, this typo was copied-and-pasted from 6020bis.

Thanks, Lada

>
>>   design time.
> ...
>
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Sep 30 05:40:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779A71A6FCB for ; Wed, 30 Sep 2015 05:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlrbdnf95odc for ; Wed, 30 Sep 2015 05:40:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCDC1A6FCA for ; Wed, 30 Sep 2015 05:40:35 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 12:40:34 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 12:40:33 +0000
From: Kent Watsen 
To: Nadeau Thomas , Robert Wilton 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgABS6YCABjVsgIAAAeCAgAFoUYCAADUCAIAAxJKA
Date: Wed, 30 Sep 2015 12:40:32 +0000
Message-ID: 
References:  <5603F9C2.2000500@cisco.com>  <5609749D.90207@cisco.com>  <560AA471.3050307@cisco.com> <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.com>
In-Reply-To: <944F9C18-27FA-420D-ACC1-FF3E30CF0973@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:JKafzTcpwoHAZcjDHJgFtEPQXZp9I7cTT0QEKldf5X3ZZ3vLkk/oCoSuuEjXv1o0s2mEEp1tp27LIyD3SHIta6niuKTJpZoXpT1FkffA/BtRQUU2X6EyXDDO41J+Xy599xTWTcmv9RbyuqRWW6RfJg==; 24:ZO13ep3b9FQrXiTxAUDLyAUhooLg1gSyBBjYWiY5kQ899wPLt+T3ZBL4odllozTtWyiZiyd99P48uInoh9MGFh76KN/0UafmEUA70ZbxTok=; 20:w2j8JYEjI5zORed2E6bXJqdOkOVwF/GFMZW6jYb2RH5Oi6wAhZ0lU9H0bHlEsFN9H0I5g0XSGmgwLmt7IAHoUA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(479174004)(189002)(164054003)(51444003)(24454002)(83506001)(19580395003)(5007970100001)(93886004)(86362001)(46102003)(5001860100001)(4001350100001)(2900100001)(81156007)(5001770100001)(101416001)(2950100001)(97736004)(4001540100001)(36756003)(5008740100001)(5004730100002)(5002640100001)(105586002)(15975445007)(102836002)(5001830100001)(19580405001)(106116001)(5001960100002)(99286002)(87936001)(16236675004)(77156002)(68736005)(40100003)(10400500002)(64706001)(50986999)(66066001)(76176999)(54356999)(189998001)(62966003)(92566002)(122556002)(19617315012)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D230A45CE2852kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 12:40:32.5048 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 12:40:40 -0000

--_000_D230A45CE2852kwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


What text do we agree to put into draft-chairs-netmod-opstate-reqs?   I mai=
ntain that we need definitions for the terms "synchronous" and "asynchronou=
s".  Robert took a stab at defining these terms on the 24th (thanks Robert!=
), but so far no one has commented on them.   So I don't think we're ready =
to close this issue yet.

Thanks,
Kent


From: Thomas Nadeau >
Date: Tuesday, September 29, 2015 at 10:56 AM
To: Robert Wilton >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asy=
nchronous (esp. wrt intended and applied)


Robert,

It seems this discussion has run out of steam and we've come to a head on t=
his issue.
It seems we have some actions we can take based on the list of three bullet=
s below as part of
that conclusion (potentially).

Do folks think we are ready to close this issue down officially?

-Tom


On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton > wrote:



On 28/09/2015 18:17, Andy Bierman wrote:


On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton > wrote:
Hi Andy,


On 24/09/2015 19:22, Andy Bierman wrote:
Hi,

I find this exercise to classify servers as synchronous or asynchronous mos=
tly useless.
We have both types of instrumentation in our server. They can be different
on a per-node basis.  They can both take a long time or both be instant, de=
pending
on the instrumentation code the vendor writes.

In any case, the server does not know if the instrumentation has finished m=
aking
the network behave according to the new edit.  That would be new functional=
ity that
no vendor supports at this time.  Currently servers return "ok" if the edit=
 is accepted
into the running datastore.  There are no other semantics wrt/ returning "o=
k".

I'm not sure whether we agree here, but as stated previously, Sec 5.1 of RF=
C 6241, implies that if the configuration is in the running datastore then =
that configuration is expected to be active on the device.


I do not agree at all that the running datastore means anything other
than the intended confg.   A new operation is needed to retrieve
the active config vs. the intended config.

If the running datastore only ever means intended config, then I think that=
 would imply:

 - existing NETCONF servers should reply immediately after the config has b=
een semantically verified + written to the config subsystem before the conf=
iguration is applied.

 - existing NETCONF servers are logically classified (as per openconfig-net=
mod-opstate) as being asynchronous w.r.t to the config requests.

 - the existing NETCONF/RESTCONF protocols has no direct mechanism for indi=
cating a failure to apply any configuration leaf, the only way such informa=
tion could be deduced is through related operational state leaves or notifi=
cations.

Rob

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


--_000_D230A45CE2852kwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <7CDFE683F102A54CB7F0BE34490374D5@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable













What text do we agree to put into dr=
aft-chairs-netmod-opstate-reqs?   I maintain that we need definitions =
for the terms "synchronous" and "asynchronous".  R=
obert took a stab at defining these terms on the 24th (thanks Robert!),
 but so far no one has commented on them.   So I don't think we're rea=
dy to close this issue yet.









Thanks,



Kent
















From: Thomas Nadeau <tnadeau@lucidvision.com>

Date: Tuesday, September 29, 2015 a=
t 10:56 AM

To: Robert Wilton <rwilton@cisco.com>

Cc: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: Re: [netmod] opstate-reqs =
#6: clarify impact of synchronous vs asynchronous (esp. wrt intended and ap=
plied)


















Robert,







It seems this discussion has run out of steam and we’ve come to =
a head on this issue.  


It seems we have some actions we can take based on the list=
 of three bullets below as part of


that conclusion (potentially).  







Do folks think we are ready to close this issue down officially?







—Tom













On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton <rwilton@cisco.com> wro=
te:











On 28/09/2015 18:17, Andy Bierman wrote:












On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton =

<rwilton@cisco.com> wrote:




Hi Andy,






On 24/09/2015 19:22, Andy Bierman wrote:






Hi,






I find this exercise to classify servers as synchronous or =
asynchronous mostly useless.


We have both types of instrumentation in our server. They c=
an be different


on a per-node basis.  They can both take a long time o=
r both be instant, depending


on the instrumentation code the vendor writes.







In any case, the server does not know if the instrumentatio=
n has finished making


the network behave according to the new edit.  That wo=
uld be new functionality that


no vendor supports at this time.  Currently servers re=
turn "ok" if the edit is accepted


into the running datastore.  There are no other semant=
ics wrt/ returning "ok".







I'm not sure whether we agree here, but as stated previously, Sec 5.1 of RF=
C 6241, implies that if the configuration is in the running datastore then =
that configuration is expected to be active on the device.













I do not agree at all that the running datastore means anyt=
hing other


than the intended confg.   A new operation is needed t=
o retrieve


the active config vs. the intended config.











If the running datastore only ever means intended config, then I think that=
 would imply:



 - existing NETCONF servers should reply immediately after the config =
has been semantically verified + written to the config subsystem before=
 the configuration is applied.



 - existing NETCONF servers are logically classified (as per openconfi=
g-netmod-opstate) as being asynchronous w.r.t to the config requests.



 - the existing NETCONF/RESTCONF protocols has no direct mechanism for=
 indicating a failure to apply any configuration leaf, the only way such in=
formation could be deduced is through related operational state leaves or n=
otifications.



Rob





_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.o=
rg/mailman/listinfo/netmod

















--_000_D230A45CE2852kwatsenjunipernet_--


From nobody Wed Sep 30 06:12:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65FC1A6FFC for ; Wed, 30 Sep 2015 06:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQEkZhIIQ9bo for ; Wed, 30 Sep 2015 06:12:58 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 B74171A7D84 for ; Wed, 30 Sep 2015 06:12:37 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 59C85A0D34AF7 for ; Wed, 30 Sep 2015 13:12:33 +0000 (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 t8UDCYa0016066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Sep 2015 13:12:34 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.201]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 30 Sep 2015 09:12:34 -0400
From: "Sterne, Jason (Jason)" 
To: "netmod@ietf.org" 
Thread-Topic: YANG advice and editing session with YANG doctors planned at IETF94 ?
Thread-Index: AdD7gatH3MF+wbZtQrO0U1alWyH9mw==
Date: Wed, 30 Sep 2015 13:12:34 +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.17]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CACB391US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] YANG advice and editing session with YANG doctors planned at IETF94 ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 13:12:59 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CACB391US70TWXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Just checking if there are plans for a Sunday YANG advice & editing session=
 with the YANG doctors again at IETF94 Japan.  Looking into travel plans...

Thx,
Jason


--_000_A125E53CE190A749957C19483DC79F9F5CACB391US70TWXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


Just checking if there are plans for a Sunday YANG advice & editin=
g session with the YANG doctors again at IETF94 Japan.  Looking into t=
ravel plans…


 


Thx,


Jason


 





--_000_A125E53CE190A749957C19483DC79F9F5CACB391US70TWXCHMBA11z_--


From nobody Wed Sep 30 06:52:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C505F1A872E for ; Wed, 30 Sep 2015 06:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTB3VjESqAwB for ; Wed, 30 Sep 2015 06:52:28 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3D61A872B for ; Wed, 30 Sep 2015 06:52:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DEB24105D; Wed, 30 Sep 2015 15:52:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vg_w4vBzxedP; Wed, 30 Sep 2015 15:52:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Sep 2015 15:52:26 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E569F20053; Wed, 30 Sep 2015 15:52:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IuuJrN30YLxM; Wed, 30 Sep 2015 15:52:24 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31A942004E; Wed, 30 Sep 2015 15:52:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 37EA4377931B; Wed, 30 Sep 2015 15:52:22 +0200 (CEST)
Date: Wed, 30 Sep 2015 15:52:22 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150930135222.GA25888@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Randy Presuhn , netmod@ietf.org
References: <19611673.1443545759340.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] 6020bis - anydata
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 13:52:30 -0000

On Wed, Sep 30, 2015 at 01:01:36PM +0200, Ladislav Lhotka wrote:
> Hi Randy,
> 
> thanks for the comments and proposed edits. Please see inline.
> 
> Randy Presuhn  writes:
> 
> > Hi -
> >
> >>From: Ladislav Lhotka 
> >>Sent: Sep 29, 2015 7:07 AM
> >>To: netmod@ietf.org
> >>Subject: [netmod] 6020bis - anydata
> >>
> >>Hi,
> >>
> >>I propose to expand the text in Sec. 7.10 as follows:
> >>
> >>OLD
> >>
> >>   The "anydata" statement is used to represent an unknown set of nodes
> >>   that can be modelled with YANG.  An example of where this can be
> >>   useful is a list of received notifications, where the exact
> >>   notifications are not known as design time.
> >>
> >>NEW
> >>
> >>   The "anydata" statement is used to represent an unknown set of nodes
> >>   that can be modelled with YANG but for which the data model doesn't
> >>   exist at module design time.
> >
> > "doesn't exist" would not be appropriate for the example you provide
> > below.  It would be incorrect if some of the notifications in your
> > example had already been defined, even though "anydata" would still
> > be necessary to handle others not yet defined.
> 
> Would "doesn't exist or cannot be determined at module design time" be better?
>

What about this:

  The "anydata" statement is used to represent a set of nodes that can
  be modelled with YANG but for which the data model is not known at
  module design time.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 30 07:32:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC81A8776 for ; Wed, 30 Sep 2015 07:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqsklgEKdjV8 for ; Wed, 30 Sep 2015 07:32:20 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8901A8798 for ; Wed, 30 Sep 2015 07:32:20 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 14:32:00 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 14:32:00 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
Thread-Index: AQHQ9hsXCtutmH/6pU2cjn+AIkuwS55LrLcAgAkLQYA=
Date: Wed, 30 Sep 2015 14:31:59 +0000
Message-ID: 
References:  <5603F9C2.2000500@cisco.com>
In-Reply-To: <5603F9C2.2000500@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:arlJfL6Dngp97dYJx7fFkz2nIsMHSzhWKqiP2SvHRrBd0hcxHLXWcNKfs1G+VJoB9TdNrrvrI07xSDF4Z97Vn2rQGNj5/h93leEm4cpIZQ7BQVrOdNJFJfSSWk0PyqXuY67+Bjooq4gzTvLt+fxT6Q==; 24:wG6xieW8dG0RoaSVVmtGOdYyzCV1VH7z5sS/vzsA3kcghoDwlpcv1IcPs2TzT/q22toFOhTmKCpYEUb3TCOP4MhxUnfarc92ezkLQAErpwM=; 20:ArS4liiKTeMTDw5osEQScXZmnQKLB80Z3ht2t0NrgVxDGIWjLJDqnMqI/x+SsBHNVGJtm5Zm3Ibkm4MenP3k3A==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(52314003)(199003)(76104003)(43784003)(68736005)(11100500001)(54356999)(105586002)(101416001)(76176999)(50986999)(2950100001)(2501003)(81156007)(106116001)(62966003)(102836002)(99286002)(66066001)(5008740100001)(16236675004)(86362001)(4001350100001)(2900100001)(5002640100001)(106356001)(36756003)(4001540100001)(64706001)(77156002)(83506001)(5007970100001)(92566002)(87936001)(40100003)(46102003)(5001960100002)(122556002)(5004730100002)(189998001)(5001770100001)(5001830100001)(5001860100001)(97736004)(10400500002)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D23127CBE290Bkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 14:31:59.9035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 14:32:28 -0000

--_000_D23127CBE290Bkwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[As a contributor]


I find that the term "system" is a bit ambiguous in this context.  It is ta=
lking about the NMS, the server, or both together?

[KENT] I believe that we're talking about the NETCONF/RESTCONF/ server=
, specifically in how it processes update requests.


Anyway, I've tried to define them relative to the configuration operations =
being performed.

[KENT] Perhaps these could be collapsed if we use the terms "a/synchronous =
server" ?


Synchronous configuration operation - A configuration request that the serv=
er applies synchronously with respect to the client request.  Before the se=
rver replies back to the client indicating the success or failure of the op=
eration it MUST semantically validate the contents of the request and updat=
e the intended configuration of the target datastore.  If the request is to=
 the running datastore then the configuration change MUST also be applied i=
n the system before the server replies back to the client.  The reply to th=
e client indicates whether there are any semantic errors or system errors f=
rom applying the configuration change.


[KENT]  This generally matches my understanding, but here are some thoughts=
 to improve it:

1. I think the language "semantically validate" would exclude an ephemeral =
datastore.  We could put a qualifier on it, but I think it can be removed e=
ntirely as each datastore already has its own semantics around how it proce=
sses update requests.

2. I like how you call out the running datastore, but it is somewhat NETCON=
F-specific.  How about something like "If the request impacts the intended =
configuration (see term), then..."

3. "applied in the system" seems too open ended, how about this:  "...MUST =
also be propagated to and processed by the operational components of the se=
rver before..." ???



Asynchronous configuration operation - A configuration request that the ser=
ver applies asynchronously with respect to the client request.  Before the =
server replies back to the client indicating the success or failure of the =
operation it MUST semantically validate the contents of the request and upd=
ate the intended configuration of the target datastore.  If the request is =
to the running datastore then the configuration change is applied to the sy=
stem after the server has replied back to the client.  The reply to the cli=
ent only indicates whether there are any semantic errors in the configurati=
on change.

[KENT] For the most part, my comments on this are the mirror image of the c=
omments made above.   One additional comment though, when reading in the fi=
rst sentence "with respect to the client" I was thinking that these terms a=
re actually independent of the protocol.  For instance, they could equally =
well be defined for a system that only had CLI access.  So, in that sense, =
the word "client" in the first sentence, and client/server elsewhere genera=
lly, may be ground for some confusion.


Synchronous system - NETCONF/RESTCONF client/server interactions that proce=
sses all configuration operations as synchronous configuration operations.

Asynchronous system - NETCONF/RESTCONF client/server interactions that proc=
esses all configuration operations as asynchronous configuration operations=
.

[KENT] again, maybe we can collapse the number of terms from 4 to 2 by call=
ing these "a/synchronous server" - what do you think?


Thanks again,
Kent




--_000_D23127CBE290Bkwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <00248DBC7AC52F43A49F85F04641AA92@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable








[As a contributor]

















I find that the term "system=
" is a bit ambiguous in this context.  It is talking about the NM=
S, the server, or both together?












[KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> =
server, specifically in how it processes update requests.

















Anyway, I've tried to define them=
 relative to the configuration operations being performed.













[KENT] Perhaps these could be collap=
sed if we use the terms "a/synchronous server" ?













Synchronous configuration operation - A configuration request that the serv=
er applies synchronously with respect to the client request.  Before t=
he server replies back to the client indicating the success or failure of t=
he operation it MUST semantically validate
 the contents of the request and update the intended configuration of the t=
arget datastore.  If the request is to the running datastore then the =
configuration change MUST also be applied in the system before the server r=
eplies back to the client.  The reply
 to the client indicates whether there are any semantic errors or system er=
rors from applying the configuration change.

















[KENT]  This generally matches my understanding, but here are som=
e thoughts to improve it:







1. I think the language "semantically validate" would exclud=
e an ephemeral datastore.  We could put a qualifier on it, but I think=
 it can be removed entirely as each datastore already has its own semantics=
 around how it processes update requests.







2. I like how you call out the running datastore, but it is somewhat N=
ETCONF-specific.  How about something like "If the request impact=
s the intended configuration (see term), then..."







3. "applied in the system" seems too open ended, how about t=
his:  "...MUST also be propagated to and processed by the operati=
onal components of the server before..." ???

















Asynchronous configuration operation - A configuration request that the ser=
ver applies asynchronously with respect to the client request.  Before=
 the server replies back to the client indicating the success or failure of=
 the operation it MUST semantically validate
 the contents of the request and update the intended configuration of the t=
arget datastore.  If the request is to the running datastore then the =
configuration change is applied to the system after the server has replied =
back to the client.  The reply to the
 client only indicates whether there are any semantic errors in the configu=
ration change.












[KENT] For the most part, my comments on this are the mirror image of =
the comments made above.   One additional comment though, when reading=
 in the first sentence "with respect to the client" I was thinkin=
g that these terms are actually independent of
 the protocol.  For instance, they could equally well be defined for a=
 system that only had CLI access.  So, in that sense, the word "c=
lient" in the first sentence, and client/server elsewhere generally, m=
ay be ground for some confusion.












Synchronous system - NETCONF/RESTCONF client/server interactions that proce=
sses all configuration operations as synchronous configuration operations.<=
br>


Asynchronous system - NETCONF/RESTCONF client/server interactions that proc=
esses all configuration operations as asynchronous configuration operations=
.












[KENT] again, maybe we can collapse the number of terms from 4 to 2 by=
 calling these "a/synchronous server" - what do you think?












Thanks again,


Kent






















--_000_D23127CBE290Bkwatsenjunipernet_--


From nobody Wed Sep 30 07:37:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639261A8799 for ; Wed, 30 Sep 2015 07:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es6vU2SWOdcl for ; Wed, 30 Sep 2015 07:37:46 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281C21A87BA for ; Wed, 30 Sep 2015 07:37:45 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 14:37:24 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 14:37:24 +0000
From: Kent Watsen 
To: "Sterne, Jason (Jason)" , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG advice and editing session with YANG doctors planned at IETF94 ?
Thread-Index: AQHQ+42FNvts4CSFkk2H2jZ7bRzv6A==
Date: Wed, 30 Sep 2015 14:37:24 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:J4/cSFyGV+qs6ZK5DTXH9eGSrlPmxJvD/h8H3HtPs1lQsk775jkBrZCIXC3H//PWq9LE6KdcBe/dVJIrEdFUCpYYjf1ha0o8/ac57dxIgivCgRwu+yWwKNDnb4x3FwsJqZSYWhZZKUNzjYKBfc13kA==; 24:zgnaAS+smUZd9qQrQGppm9Dd2mJnaBhrMIE9cGF7jkTyjDwOLroqAyM6MZUDPGvDL5DLQF4bRYu8OkwzSnDnyjHfGmhSpTvE01bU2OtfE54=; 20:qigavQapolnbocjR9WT3MIOPs072G2C1wAjIYW7KLh+Q3ROJ+Sp33bS0yPHvPGWRwxShieo7jDUe/S3q1NKVgw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(199003)(53754006)(83506001)(5001860100001)(19580395003)(5007970100001)(86362001)(46102003)(4001350100001)(81156007)(2501003)(19625215002)(2900100001)(5001770100001)(101416001)(2950100001)(97736004)(4001540100001)(36756003)(5004730100002)(5008740100001)(5002640100001)(11100500001)(105586002)(15975445007)(102836002)(5001830100001)(19580405001)(106116001)(99286002)(5001960100002)(87936001)(16236675004)(40100003)(68736005)(77156002)(10400500002)(64706001)(50986999)(107886002)(66066001)(76176999)(54356999)(122556002)(189998001)(62966003)(92566002)(106356001)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D23140A4E2A1Akwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 14:37:24.3752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [netmod] YANG advice and editing session with YANG doctors planned at IETF94 ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 14:37:53 -0000

--_000_D23140A4E2A1Akwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Jason,

Yes, there will be a YANG advice and editing session on Sunday.  Specifical=
ly, the four hour block listed on https://www.ietf.org/meeting/94/tutorials=
.html as "YANG Tutorial and Hackathon" is being renamed to "YANG Tutorial a=
nd YANG Advice/Editing Session"  (roughly 2 hours each).

Thank you for bringing this to our attention.

Kent

From: , "Jason (Jason)" >
Date: Wednesday, September 30, 2015 at 6:12 AM
To: "netmod@ietf.org" >
Subject: [netmod] YANG advice and editing session with YANG doctors planned=
 at IETF94 ?

Hi all,

Just checking if there are plans for a Sunday YANG advice & editing session=
 with the YANG doctors again at IETF94 Japan.  Looking into travel plans...

Thx,
Jason


--_000_D23140A4E2A1Akwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <7DF9630A22702640BC8A9306B0042EA5@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














Hi Jason,









Yes, there will be a YANG advice and editing session on Sunday.  Speci=
fically, the four hour block listed on
https://www.ietf=
.org/meeting/94/tutorials.html as "YANG Tutorial and Hackatho=
n" is being renamed to "YANG Tutorial and YANG Advice/Editing Ses=
sion"  (roughly 2 hours each).









Thank you for bringing this to our attention.









Kent










From: <Sterne>, "Jason (=
Jason)" <jason.s=
terne@alcatel-lucent.com>

Date: Wednesday, September 30, 2015=
 at 6:12 AM

To: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: [netmod] YANG advice and e=
diting session with YANG doctors planned at IETF94 ?















Hi all,


 


Just checking if there are plans for a Sunday YANG advice & editin=
g session with the YANG doctors again at IETF94 Japan.  Looking into t=
ravel plans…


 


Thx,


Jason


 









--_000_D23140A4E2A1Akwatsenjunipernet_--


From nobody Wed Sep 30 07:54:25 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01E21B5DC1 for ; Wed, 30 Sep 2015 07:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1EKHtAumuVJ for ; Wed, 30 Sep 2015 07:54:21 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 9247C1B4155 for ; Wed, 30 Sep 2015 07:54:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1443624772; bh=QRUGwUJPW8HxKEaANW1w4EJZSMmAs/RC+ekEuvcNwOg=; h=Subject:From:In-Reply-To:Date:References:To; b=iwr45Temf4n0yY6xTuKN9+LvCqQOIookkOBhp7GEjm1aAD0+4WOXRHJMX1/O24N5U gFtZNgoJo+Ko/F8DtR29dny05H16fqAZGSYxSGJPlvDyecxugm1lpT4SegpxuM0Jd+ OFBf1Cg2clVo+m77JfZclVlfsQPx4C6Bo+YizRiE=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Wed, 30 Sep 2015 10:54:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C236103-0F38-427E-888F-78537B1A2269@lucidvision.com>
References: 
To: netmod WG 
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 138, in=1714, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Subject: Re: [netmod] Thursday Interim Meeting Agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 14:54:23 -0000

	After discussing a bit more with Kent, we wanted to slightly =
amend=20
the agenda for tomorrow to first start out with trying to wrap up the
discussion around the requirements.  We will review the issues=20
as they are listed on the NETMOD Github issue tracker and try to
come to conclusions about the open issues:

https://github.com/netmod-wg/opstate-reqs/issues

	=E2=80=94Tom



> On Sep 29, 2015:3:53 PM, at 3:53 PM, Nadeau Thomas =
 wrote:
>=20
>=20
> 	After going over the plan with Kent, we would like to continue =
the agenda from the
> last interim meeting on Thursday. That is to say, Kent will continue =
with the comparison
> of solutions.  =46rom last time and in parallel with this, the WG =
discussion around the requirements=20
> seems to be converging on a detailed level of refinement of the =
requirements.  We will
> recap the status here and goals.
>=20
> 	The details of the meeting are here:
>=20
>=20
> The NETCONF Data Modeling Language (netmod) Working Group will hold a =
virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am =
PDT; 2pm GMT).
>=20
> The title is =E2=80=9COpenconfig Solutions Discussion (continued)=E2=80=9D=
.
>=20
> The WebEx is:
>=20
> Meeting number:640 686 530
> Meeting password:1234
> Audio connection:
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 640 686 530
> Meeting link: =
https://ietf.webex.com/ietf/j.php?MTID=3Dmf12aa8d28a159614cb415f2f32dcbebf=

>=20
>=20
>=20
> 	--Tom (as WG co-chair)
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 30 08:03:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95391B5E29 for ; Wed, 30 Sep 2015 08:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgDJ1pyJF21S for ; Wed, 30 Sep 2015 08:03:02 -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 C2E591B5E28 for ; Wed, 30 Sep 2015 08:03:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15504; q=dns/txt; s=iport; t=1443625382; x=1444834982; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=7XpgkTZMn+5Smw5FdI9RnlCDeuwzEKS0bVBfevA+zSs=; b=LW6qSR+IogF2UKaZjVR3ii5KqXhW6UxNChe9Z7iwEzHjgM4F+4BDcQ7u y2riPxFaFDgMtIR0kl5Gx8DQ04E8eKP4AXkbQE/mYOmdO2pM4GAcbYWnP YBrHfRYdPoNMWbKr7gyZGGacwJZriqNziznGkqND2QjhhZGdkgsBzNHVH o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcBABM+AtW/xbLJq1eglfFJYJWAoIDAQEBAQEBgQuEJAEBAQMBeBELDgoJFgQLCQMCAQIBRQYBDAgBAYgiCMthAQEBAQEBBAEBAQEBAQEBARmGc4R9hEJShCwFhz6GdYdFjROBT4c2igaEVoNvY4JEgT89iAslgSEBAQE
X-IronPort-AV: E=Sophos;i="5.17,612,1437436800";  d="scan'208,217";a="605455531"
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; 30 Sep 2015 15:02:59 +0000
Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8UF2xTH015693; Wed, 30 Sep 2015 15:02:59 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:  <5603F9C2.2000500@cisco.com> 
From: Robert Wilton 
Message-ID: <560BF9A3.4090603@cisco.com>
Date: Wed, 30 Sep 2015 16:02:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060508080304030905000600"
Archived-At: 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 15:03:04 -0000

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

Hi Kent,

Just some quick comments inline ...

On 30/09/2015 15:31, Kent Watsen wrote:
> [As a contributor]
>
>
> I find that the term "system" is a bit ambiguous in this context.  It 
> is talking about the NMS, the server, or both together?
>
> [KENT] I believe that we're talking about the NETCONF/RESTCONF/ 
> server, specifically in how it processes update requests.
>
>
> Anyway, I've tried to define them relative to the configuration 
> operations being performed.
>
> [KENT] Perhaps these could be collapsed if we use the terms 
> "a/synchronous server" ?

Personally, I think that defining the operations is arguably more useful 
because it is feasible that you could have a server that supports both 
sync and async operations and allows the client to choose which 
semantics should be used for a particular request.


>
>
> Synchronous configuration operation - A configuration request that the 
> server applies synchronously with respect to the client request.  
> Before the server replies back to the client indicating the success or 
> failure of the operation it MUST semantically validate the contents of 
> the request and update the intended configuration of the target 
> datastore.  If the request is to the running datastore then the 
> configuration change MUST also be applied in the system before the 
> server replies back to the client.  The reply to the client indicates 
> whether there are any semantic errors or system errors from applying 
> the configuration change.
>
>
> [KENT]  This generally matches my understanding, but here are some 
> thoughts to improve it:
>
> 1. I think the language "semantically validate" would exclude an 
> ephemeral datastore.  We could put a qualifier on it, but I think it 
> can be removed entirely as each datastore already has its own 
> semantics around how it processes update requests.

My aim here is potentially tied to the definition of intended config, 
were I am suggesting that the system has to at least have been checked 
that the request is well formed and any YANG constraints in the data 
model have been met, before it is accepted as intended config, otherwise 
it would be rejected.


>
> 2. I like how you call out the running datastore, but it is somewhat 
> NETCONF-specific.  How about something like "If the request impacts 
> the intended configuration (see term), then..."

Yes your text is better and I agree that we should avoid making the 
description NETCONF specific at all.

>
> 3. "applied in the system" seems too open ended, how about this: 
>  "...MUST also be propagated to and processed by the operational 
> components of the server before..." ???

So my aim here was to tie it back to the definition of "applied 
configuration", but this could probably be expressed in a more direct 
way, e.g. perhaps ".... MUST update the applied configuration in the 
system before the server replies ..."


>
>
>
> Asynchronous configuration operation - A configuration request that 
> the server applies asynchronously with respect to the client request.  
> Before the server replies back to the client indicating the success or 
> failure of the operation it MUST semantically validate the contents of 
> the request and update the intended configuration of the target 
> datastore.  If the request is to the running datastore then the 
> configuration change is applied to the system after the server has 
> replied back to the client.  The reply to the client only indicates 
> whether there are any semantic errors in the configuration change.
>
> [KENT] For the most part, my comments on this are the mirror image of 
> the comments made above.   One additional comment though, when reading 
> in the first sentence "with respect to the client" I was thinking that 
> these terms are actually independent of the protocol.  For instance, 
> they could equally well be defined for a system that only had CLI 
> access.  So, in that sense, the word "client" in the first sentence, 
> and client/server elsewhere generally, may be ground for some confusion.

Perhaps rather than "client request" we could just use "config request", 
and rather than "replies back to the client" use "responds to the config 
request" or similar?

>
>
> Synchronous system - NETCONF/RESTCONF client/server interactions that 
> processes all configuration operations as synchronous configuration 
> operations.
>
> Asynchronous system - NETCONF/RESTCONF client/server interactions that 
> processes all configuration operations as asynchronous configuration 
> operations.
>
> [KENT] again, maybe we can collapse the number of terms from 4 to 2 by 
> calling these "a/synchronous server" - what do you think?

As per my first comment, personally I see this problem as being framed 
around how requests are handled, and besides I think that describing a 
system or server as being sync or async is open to many different 
conflicting interpretations.

Thanks,
Rob


>
>
> Thanks again,
> Kent
>
>
>


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


  
    
  
  
    Hi Kent,

    

    Just some quick comments inline ...

    

    
On 30/09/2015 15:31, Kent Watsen wrote:

    

    

      
      

        [As a contributor]

      

        

      

      

        

      

      
        

          
I find that the term
            "system" is a bit ambiguous in this context. It is talking
            about the NMS, the server, or both together?

        

      
      

        

      

      

        [KENT] I believe that we're talking about the
        NETCONF/RESTCONF/<foo> server, specifically in how it
        processes update requests.

      

        

      

      

        

      

      
        

          
Anyway, I've tried to
            define them relative to the configuration operations being
            performed.

          

        

      
      

        

      

      
[KENT] Perhaps these could be
          collapsed if we use the terms "a/synchronous server" ?

    

    

    Personally, I think that defining the operations is arguably more
    useful because it is feasible that you could have a server that
    supports both sync and async operations and allows the client to
    choose which semantics should be used for a particular request.

    

    

    

      

        

      

      
        

          


            Synchronous configuration operation - A configuration
            request that the server applies synchronously with respect
            to the client request. Before the server replies back to
            the client indicating the success or failure of the
            operation it MUST semantically validate the contents of the
            request and update the intended configuration of the target
            datastore. If the request is to the running datastore then
            the configuration change MUST also be applied in the system
            before the server replies back to the client. The reply to
            the client indicates whether there are any semantic errors
            or system errors from applying the configuration change.

          

        

      
      


      

      


      

      
[KENT] This generally matches my understanding, but here are
        some thoughts to improve it:

      


      

      
1. I think the language "semantically validate" would exclude
        an ephemeral datastore. We could put a qualifier on it, but I
        think it can be removed entirely as each datastore already has
        its own semantics around how it processes update requests.

    

    

    My aim here is potentially tied to the definition of intended
    config, were I am suggesting that the system has to at least have
    been checked that the request is well formed and any YANG
    constraints in the data model have been met, before it is accepted
    as intended config, otherwise it would be rejected.

    

    

    

      


      

      
2. I like how you call out the running datastore, but it is
        somewhat NETCONF-specific. How about something like "If the
        request impacts the intended configuration (see term), then..."

    

    

    Yes your text is better and I agree that we should avoid making the
    description NETCONF specific at all.

    

    

      


      

      
3. "applied in the system" seems too open ended, how about
        this: "...MUST also be propagated to and processed by the
        operational components of the server before..." ???

    

    

    So my aim here was to tie it back to the definition of "applied
    configuration", but this could probably be expressed in a more
    direct way, e.g. perhaps ".... MUST update the applied configuration
    in the system before the server replies ..."

    

    

    

      


      

      


      

      
        

          


            Asynchronous configuration operation - A configuration
            request that the server applies asynchronously with respect
            to the client request. Before the server replies back to
            the client indicating the success or failure of the
            operation it MUST semantically validate the contents of the
            request and update the intended configuration of the target
            datastore. If the request is to the running datastore then
            the configuration change is applied to the system after the
            server has replied back to the client. The reply to the
            client only indicates whether there are any semantic errors
            in the configuration change.

          

        

      
      


      

      
[KENT] For the most part, my comments on this are the mirror
        image of the comments made above.  One additional comment
        though, when reading in the first sentence "with respect to the
        client" I was thinking that these terms are actually independent
        of the protocol. For instance, they could equally well be
        defined for a system that only had CLI access. So, in that
        sense, the word "client" in the first sentence, and
        client/server elsewhere generally, may be ground for some
        confusion.

    

    

    Perhaps rather than "client request" we could just use "config
    request", and rather than "replies back to the client" use
    "responds to the config request" or similar?

    

    

      


      

      
        

          


            Synchronous system - NETCONF/RESTCONF client/server
            interactions that processes all configuration operations as
            synchronous configuration operations.

            

            Asynchronous system - NETCONF/RESTCONF client/server
            interactions that processes all configuration operations as
            asynchronous configuration operations.

          

        

      
      


      

      
[KENT] again, maybe we can collapse the number of terms from
        4 to 2 by calling these "a/synchronous server" - what do you
        think?

    

    

    As per my first comment, personally I see this problem as being
    framed around how requests are handled, and besides I think that
    describing a system or server as being sync or async is open to many
    different conflicting interpretations.

    

    Thanks,

    Rob

    

    

    

      


      

      


      

      
Thanks again,

      
Kent

      


      

      
        

          


            

          

        

      
    

    

  


--------------060508080304030905000600--


From nobody Wed Sep 30 08:09:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB481B5E3D for ; Wed, 30 Sep 2015 08:09:58 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTaO4hseP_fb for ; Wed, 30 Sep 2015 08:09:52 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C56B1B5E2B for ; Wed, 30 Sep 2015 08:09:51 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 15:09:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 15:09:30 +0000
From: Kent Watsen 
To: Lou Berger , Nadeau Thomas , netmod WG 
Thread-Topic: [netmod] Thursday Interim Meeting Agenda
Thread-Index: AQHQ+vCNRPkpiMpHfUagLQWsH0EPhp5U1o8A///iNQA=
Date: Wed, 30 Sep 2015 15:09:30 +0000
Message-ID: 
References:  <1501dae1b68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <1501dae1b68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:/tdleik1OSQSwPmd/rvQWDMjQI1xOTJufbT1zNAzZXV4WmRGRgfQb9xCjeBFR4WILe65eiaXUSwhoLnjKqs7lsbwvP2MAJ44VdkcsRPI7KC1jCKJcEfRYcVRTzW9aNziF+KS5f3sUqVC8kRGnwxH9Q==; 24:wcRTFuXS0LGu29I2xCjbCW/M9OOz95LLx/fneRcIe7Oir592uT0soMzZXLbFwnK5GQhQpiW/DS0+bW1dpSecKeN7Kldzpw8VXHVod097sYk=; 20:FqltidhEzkrlK/ZwJhMNyg6jTRhnBGLihqtBuIFuUvzbRA5+/hj9yDURuq9fsvFEmnmv67rhhAfjGATP4h8pmA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(24454002)(377454003)(199003)(479174004)(68736005)(11100500001)(19580405001)(54356999)(105586002)(101416001)(76176999)(50986999)(2950100001)(81156007)(106116001)(62966003)(102836002)(99286002)(15975445007)(66066001)(5008740100001)(86362001)(4001350100001)(2900100001)(5002640100001)(106356001)(36756003)(4001540100001)(64706001)(77156002)(83506001)(5007970100001)(92566002)(87936001)(40100003)(19580395003)(16799955002)(46102003)(5001960100002)(122556002)(5004730100002)(189998001)(5001770100001)(5001830100001)(5001860100001)(551544002)(97736004)(10400500002)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6CF7BA4E9C2A1746B724EA804478CEB8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 15:09:30.0429 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: Re: [netmod] Thursday Interim Meeting Agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 15:09:58 -0000

Hi Lou,

We (the chairs) are in the process of closing the issues filed against
draft-chairs-netmod-opstate-reqs.   There is a documented process (state
machine) for this here:
https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-track
ing.  The issues are closed via WG consensus, specifically the VERIFY
state confirms the consensus on the mailing list.

So far we're off to a slow start - only 1 of 7 issues has made it to the
EDIT state.  I believe progress is being impeded by a lack of
participation from some.  Still, the WG will complete this work in time
and publish an updated draft, so that it san be referenced by follow-on
solution drafts, in both the NETMOD and NETCONF WGs.

Thanks,
Kent



On 9/30/15, 2:56 AM, "Lou Berger"  wrote:

>Tom, chairs,
>
>At the last meeting, I believe I heard that a statement of consensus -
>i.e., a consensus call -  on the requirements would be made by the
>chairs, =20
>on list. (With the understanding that there are details of the
>requirements=20
>that will need to be documented, presumably in a WG version of the chairs
>requirements draft.)
>
>Are we at the point yet were this call can/will be made?
>
>Thanks,
>Lou
>
>
>
>
>
>On September 29, 2015 3:53:56 PM Nadeau Thomas 
>wrote:
>
>>
>> 	After going over the plan with Kent, we would like to continue the
>>agenda=20
>> from the
>> last interim meeting on Thursday. That is to say, Kent will continue
>>with=20
>> the comparison
>> of solutions.  From last time and in parallel with this, the WG
>>discussion=20
>> around the requirements
>> seems to be converging on a detailed level of refinement of the
>> requirements.  We will
>> recap the status here and goals.
>>
>> 	The details of the meeting are here:
>>
>>
>> The NETCONF Data Modeling Language (netmod) Working Group will hold a
>> virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am
>>PDT;=20
>> 2pm GMT).
>>
>> The title is =B3Openconfig Solutions Discussion (continued)=B2.
>>
>> The WebEx is:
>>
>> Meeting number:640 686 530
>> Meeting password:1234
>> Audio connection:
>> 1-877-668-4493 Call-in toll free number (US/Canada)
>> 1-650-479-3208 Call-in toll number (US/Canada)
>> Access code: 640 686 530
>> Meeting link:=20
>> https://ietf.webex.com/ietf/j.php?MTID=3Dmf12aa8d28a159614cb415f2f32dcbe=
bf
>>
>>
>>
>> 	--Tom (as WG co-chair)
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 30 08:44:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FF41B5ECF for ; Wed, 30 Sep 2015 08:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDScbbUeLLVM for ; Wed, 30 Sep 2015 08:44:21 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5371B5EB3 for ; Wed, 30 Sep 2015 08:44:21 -0700 (PDT)
Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB538.namprd05.prod.outlook.com (10.141.73.24) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 15:44:04 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 15:44:04 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 15:44:04 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Thread-Index: AQHQ+5bVY+r8w1658UewPXEWKgfK5w==
Date: Wed, 30 Sep 2015 15:44:04 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:MlhEijHmS6lZVBI2A2//lsXnGhyJSe6bLeMIpYHE/jRiME9hDwBgbQhWVjYAI5osXjba/Kw3VEGpciord0tkgrmv9sBTW9KYYhvNrxEUrxAIhTUJjTxaa2K08ZmoDkRcAbvHkky3FTJ/hvRb/lfwWQ==; 24:bdVacB+4MWZDYvmqQLy8HCVc22DjRdW+ncynv3X+g4WEh4W9Y1lXZOAZ8M5FFSoFxN4OJMnQMV/AxOmLJlrob72rd4c29a/PY/uas1Q0YZY=; 20:LJqrm1GmN2GsOGyHXreVwtzCigMS24w3Oy8uFuNPKZeV/jGpIc+uF/L3D0SdbShVHxQSoWkvwcN+pe/UnOflDA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(164054003)(2351001)(5001960100002)(107886002)(83506001)(189998001)(64706001)(50986999)(66066001)(102836002)(229853001)(122556002)(87936001)(68736005)(36756003)(110136002)(105586002)(15975445007)(5004730100002)(81156007)(4001540100001)(2900100001)(97736004)(106116001)(11100500001)(5007970100001)(40100003)(5001830100001)(5001860100001)(10400500002)(99286002)(19617315012)(5002640100001)(2501003)(54356999)(92566002)(4001350100001)(62966003)(101416001)(16236675004)(77156002)(106356001)(5008740100001)(86362001)(19580395003)(46102003)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2315152E2A92kwatsenjunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 15:44:04.0508 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB538; 2:3WhdNbJNl4Y9DXI+Fisk7i63FTDeX6AmE1q6QsPak3dNm02Y117lawJkQqB8vEpGgzpiikPpp2Ns7A6ObgmlK7ETagWiNDUfqoh8qE/wHVqs659UIYxT7ph0/A+cHy4eMom1MCLoXNWW5fEQXCBEEswNLrcLD6Uwli9mGQobyus=; 23:BclxQDqxOR3Aa92N92KtcuWzPhZJaNObOReNst9ZuAsjvOa1Qtbtry61YC1U3rjS8NE8QcnIYZhjwMCvIvpkc13C/FlB0pXam9HrMV/89NTZZlH7/v3NRvHhIzUZJbPUIZCq5HkK/sY+m9+nHRxTLXPX4+seZAHYskDEX+pQjsehVpyasfMF5e+qsXqZg/jh
X-OriginatorOrg: juniper.net
Archived-At: 
Subject: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 15:44:23 -0000

--_000_D2315152E2A92kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


It's time to tackle another issue, just before tomorrow's meeting, and this=
 time I'm picking a hard one:

https://github.com/netmod-wg/opstate-reqs/issues/5

Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub=
 issue tracker.    Please first read the comments posted there and then con=
tinue the discussion here on the mailing list (not on the GitHub issue trac=
ker).

Note that this issue is closely tied to the definition of "applied configur=
ation", which is exactly what issue #4 regards (https://github.com/netmod-w=
g/opstate-reqs/issues/4), for which Mahesh and Einar have posted comments o=
n already.   As these two issues (#4 and #5) are so highly related, I'm goi=
ng to simultaneously open the other issue for discussion now as well.

Thanks,
Kent


--_000_D2315152E2A92kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable














It's time to tackle another issue, just before tomorrow's meeting, and this=
 time I'm picking a hard one:














Already Carl, Mahesh, Einar, and And=
y have posted 18 comments on the GitHub issue tracker.    Please =
first read the comments posted there and then continue the discussion here =
on the mailing list (not on the GitHub issue
 tracker).







Note that this issue is closely tied to the definition of "applie=
d configuration", which is exactly what issue #4 regards (https://github.com/netmo=
d-wg/opstate-reqs/issues/4), for which Mahesh
 and Einar have posted comments on already.   As these two issues (#4 =
and #5) are so highly related, I'm going to simultaneously open the other i=
ssue for discussion now as well.







Thanks,


Kent









--_000_D2315152E2A92kwatsenjunipernet_--


From nobody Wed Sep 30 08:52:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D31B5EBE for ; Wed, 30 Sep 2015 08:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4xF42mC_tSJ for ; Wed, 30 Sep 2015 08:52:32 -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 5FFDB1B4497 for ; Wed, 30 Sep 2015 08:52:32 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2B697A14; Wed, 30 Sep 2015 17:52:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5P0lNRFaShb2; Wed, 30 Sep 2015 17:52:30 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Sep 2015 17:52:30 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5071120058; Wed, 30 Sep 2015 17:52:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8tn5bILSxrHT; Wed, 30 Sep 2015 17:52:29 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9D0720055; Wed, 30 Sep 2015 17:52:28 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 73243377958B; Wed, 30 Sep 2015 17:52:27 +0200 (CEST)
Date: Wed, 30 Sep 2015 17:52:26 +0200
From: Juergen Schoenwaelder 
To: Nadeau Thomas 
Message-ID: <20150930155226.GA26234@elstar.local>
Mail-Followup-To: Nadeau Thomas , netmod WG 
References:  <5C236103-0F38-427E-888F-78537B1A2269@lucidvision.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5C236103-0F38-427E-888F-78537B1A2269@lucidvision.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Thursday Interim Meeting Agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 15:52:35 -0000

On Wed, Sep 30, 2015 at 10:54:18AM -0400, Nadeau Thomas wrote:
> 
> 	After discussing a bit more with Kent, we wanted to slightly amend 
> the agenda for tomorrow to first start out with trying to wrap up the
> discussion around the requirements.  We will review the issues 
> as they are listed on the NETMOD Github issue tracker and try to
> come to conclusions about the open issues:
> 
> https://github.com/netmod-wg/opstate-reqs/issues
>

We can review the issues but what we really need I think are proposals
to define the terminology. Not creating proposals works well by
reviewing issues in an interim online meeting. Perhaps Kent can come
up with a proposal, put it down somewhere (e.g. a revision of the I-D)
and then let the mailing list bash out the details.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 30 08:59:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048211B5ECB for ; Wed, 30 Sep 2015 08:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlGoqZaMzV8f for ; Wed, 30 Sep 2015 08:58:58 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447161B5E7E for ; Wed, 30 Sep 2015 08:58:58 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 15:58:56 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 15:58:56 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: opstate-reqs #4: Provide a tighter definition of "applied configuration"
Thread-Index: AQHQ+5jp1v6hLihUyE+oXDRPZo9RIA==
Date: Wed, 30 Sep 2015 15:58:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:KVhphApPINUPuJrtSSpk/ug2fsZOCtvbWz8oo5k2J5JKCw/AEvopLn4oNqCTtFOEkXk0pEhKneKDQyvKd0EXFUGRndDWV5LxTQGVHclKuFrkIQTZphkAKhbn3r3vV3rjmIKyyu4nDKkIh3getzV6Vg==; 24:ffp+aCEaglOXXGPoc5g08ZdBZcoWCZDbiEsVP3t9PnuBJPDxaCbQGGSFwgX07a2vISMveOcCzWgUEStLTbi2xhIZyasogEJ7R8NqXw4vZcQ=; 20:u/uM9iYCj2GzqAnU7J6EfL7fEM1SRtESnhOUpGiLb3ntZYzRNFBuMMO1XI6S30enAblcawX1lGF9M0Amlkb+Tg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(164054003)(15975445007)(2351001)(4001540100001)(97736004)(19617315012)(68736005)(66066001)(81156007)(77156002)(62966003)(102836002)(5002640100001)(5001860100001)(2900100001)(10400500002)(450100001)(99286002)(4001350100001)(36756003)(83506001)(106356001)(101416001)(11100500001)(5001830100001)(105586002)(54356999)(189998001)(87936001)(40100003)(5008740100001)(50986999)(106116001)(64706001)(5001960100002)(5007970100001)(92566002)(110136002)(86362001)(2501003)(16236675004)(229853001)(5004730100002)(46102003)(122556002)(107886002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D23154CFE2AB8kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 15:58:56.2316 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 15:59:01 -0000

--_000_D23154CFE2AB8kwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Again, let's tackle a hard issue before tomorrow's interim meeting - this t=
ime the definition of "applied configuration":

https://github.com/netmod-wg/opstate-reqs/issues/4

Currently, draft-chairs-netmod-opstate-reqs has this definition:

   o  applied configuration - this data represents the state that the
      network element is actually in, i.e., that which is currently
      being run by particular software modules (e.g., the BGP daemon),
      or other systems within the device (e.g., a secondary control-
      plane, or line card).

But, as Robert states in the issue:

    The definition of "applied configuration" is slightly vague, and there
    seems to be multiple interpretations of it on the WG alias, and
    hence a tighter specification of it would be useful.

    In particular:

      - does it include support for templating (as per openconfig-netmod-op=
state-01 section 7.3.)?
      - is it allowed to represent system created objects that have no corr=
esponding configuration?
      - how does it relate to the state of the system after a equivalent sy=
nchronous config commit (if at all)?


Already Mahesh and Einar have posted comments on the GitHub issue tracker. =
  Please first read the comments posted there and then continue the discuss=
ion here on the mailing list (not on the GitHub issue tracker).

PS: This issue is highly related to issue #5, which was also just opened fo=
r discussion on the mailing list.

Thanks,
Kent


--_000_D23154CFE2AB8kwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <1B73E06833E49F41ADA0E75E980E16BC@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














Again, let's tackle a hard issue before tomorrow's interim meeting – =
this time the definition of "applied configuration":
















Currently, draft-chairs-netmod-opstate-reqs has this definition:









   o  applied configuration - this data represents the =
state that the



      network element is actually in, i.e., t=
hat which is currently



      being run by particular software module=
s (e.g., the BGP daemon),



      or other systems within the device (e.g=
., a secondary control-



      plane, or line card).









But, as Robert states in the issue:









    The definition of "applied configuration" is slight=
ly vague, and there



    seems to be multiple interpretations of it on the WG alias, a=
nd 



    hence a tighter specification of it would be useful.









    In particular:









      - does it include support for templating (as per openc=
onfig-netmod-opstate-01 section 7.3.)?



      - is it allowed to represent system created objects th=
at have no corresponding configuration?



      - how does it relate to the state of the system after =
a equivalent synchronous config commit (if at all)?















Already Mahesh and Einar have posted comments on the GitHub issue tracker. =
  Please first read the comments posted there and then continue the di=
scussion here on the mailing list (not on the GitHub issue tracker).













PS: This issue is highly related to issue #5, which was also just opened fo=
r discussion on the mailing list.









Thanks,



Kent










--_000_D23154CFE2AB8kwatsenjunipernet_--


From nobody Wed Sep 30 16:54:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6531A0143 for ; Wed, 30 Sep 2015 16:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxNkHNHop4R2 for ; Wed, 30 Sep 2015 16:54:27 -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 829751A0122 for ; Wed, 30 Sep 2015 16:54:27 -0700 (PDT)
Received: by pablk4 with SMTP id lk4so54101734pab.3 for ; Wed, 30 Sep 2015 16:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PxApUCzDHa82wufOm8V1SxFBOZhfbdlBDYeotujRDOI=; b=Ku5qZkfJde2xzT9ustF+g6JbSL8wNPQz71cc0x8LdTqK+udnO6cLYnTeQ06aNybyw2 UillOrbH/0y6h2yu+0dhfNZvevUx3jnT+Zwga3Yw3bKjpDG6UJy/t0agUB+Xuj/TdH6l Qhf0kTeg+IjmqhvVVAi3K/LwBeZyoOarM2rPtXM302CWICNVFjpKgSqvTe81KXdzVa7J 9dZef78i1Q4RCegpHigzs206ZPd8hDVj7glb+3WXTujwb4pSRPHi7Iqch66mTE2OzBS7 V5IXIssSwZYIa87L+uv4IfuNn0DlMFGE/QxJOIUcUdzSNocRe4Hfuj3w8n3hB6nDLl2q YabQ==
X-Received: by 10.66.119.135 with SMTP id ku7mr8087860pab.21.1443657266872; Wed, 30 Sep 2015 16:54:26 -0700 (PDT)
Received: from ?IPv6:2001:420:290:1266:b89a:6885:c2c3:62ed? ([2001:420:290:1266:b89a:6885:c2c3:62ed]) by smtp.gmail.com with ESMTPSA id ux7sm2829524pac.10.2015.09.30.16.54.25 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Sep 2015 16:54:25 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_457148C1-D5B2-48F3-9AC9-A67F71612208"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mahesh Jethanandani 
In-Reply-To: <560BF9A3.4090603@cisco.com>
Date: Wed, 30 Sep 2015 16:55:10 -0700
Message-Id: 
References:  <5603F9C2.2000500@cisco.com>  <560BF9A3.4090603@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Sep 2015 23:54:30 -0000

--Apple-Mail=_457148C1-D5B2-48F3-9AC9-A67F71612208
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

One comment.

> On Sep 30, 2015, at 8:02 AM, Robert Wilton  wrote:
>=20
> Hi Kent,
>=20
> Just some quick comments inline ...
>=20
> On 30/09/2015 15:31, Kent Watsen wrote:
>> [As a contributor]
>>=20
>>=20
>> I find that the term "system" is a bit ambiguous in this context.  It =
is talking about the NMS, the server, or both together?
>>=20
>> [KENT] I believe that we're talking about the NETCONF/RESTCONF/ =
server, specifically in how it processes update requests.
>>=20
>>=20
>> Anyway, I've tried to define them relative to the configuration =
operations being performed.
>>=20
>> [KENT] Perhaps these could be collapsed if we use the terms =
"a/synchronous server" ?
>=20
> Personally, I think that defining the operations is arguably more =
useful because it is feasible that you could have a server that supports =
both sync and async operations and allows the client to choose which =
semantics should be used for a particular request.
>=20
>=20
>>=20
>>=20
>> Synchronous configuration operation - A configuration request that =
the server applies synchronously with respect to the client request.  =
Before the server replies back to the client indicating the success or =
failure of the operation it MUST semantically validate the contents of =
the request and update the intended configuration of the target =
datastore.  If the request is to the running datastore then the =
configuration change MUST also be applied in the system before the =
server replies back to the client.  The reply to the client indicates =
whether there are any semantic errors or system errors from applying the =
configuration change.
>>=20
>>=20
>> [KENT]  This generally matches my understanding, but here are some =
thoughts to improve it:
>>=20
>> 1. I think the language "semantically validate" would exclude an =
ephemeral datastore.  We could put a qualifier on it, but I think it can =
be removed entirely as each datastore already has its own semantics =
around how it processes update requests.
>=20
> My aim here is potentially tied to the definition of intended config, =
were I am suggesting that the system has to at least have been checked =
that the request is well formed and any YANG constraints in the data =
model have been met, before it is accepted as intended config, otherwise =
it would be rejected.
>=20
>=20
>>=20
>> 2. I like how you call out the running datastore, but it is somewhat =
NETCONF-specific.  How about something like "If the request impacts the =
intended configuration (see term), then..."
>=20
> Yes your text is better and I agree that we should avoid making the =
description NETCONF specific at all.
>=20
>>=20
>> 3. "applied in the system" seems too open ended, how about this:  =
"...MUST also be propagated to and processed by the operational =
components of the server before..." ???
>=20
> So my aim here was to tie it back to the definition of "applied =
configuration", but this could probably be expressed in a more direct =
way, e.g. perhaps ".... MUST update the applied configuration in the =
system before the server replies =85"

If I understand this correctly, we are still talking about =93applied =
configuration=94 as configuration that has been written to =
datastore/hardware/line card etc. It does not imply that anything has =
come out of it, including whether the configuration is usable. That =
operating configuration (and I just introduced another term) will be =
reflected by derived state.

Is that true?

>=20
>=20
>>=20
>>=20
>>=20
>> Asynchronous configuration operation - A configuration request that =
the server applies asynchronously with respect to the client request.  =
Before the server replies back to the client indicating the success or =
failure of the operation it MUST semantically validate the contents of =
the request and update the intended configuration of the target =
datastore.  If the request is to the running datastore then the =
configuration change is applied to the system after the server has =
replied back to the client.  The reply to the client only indicates =
whether there are any semantic errors in the configuration change.
>>=20
>> [KENT] For the most part, my comments on this are the mirror image of =
the comments made above.   One additional comment though, when reading =
in the first sentence "with respect to the client" I was thinking that =
these terms are actually independent of the protocol.  For instance, =
they could equally well be defined for a system that only had CLI =
access.  So, in that sense, the word "client" in the first sentence, and =
client/server elsewhere generally, may be ground for some confusion.
>=20
> Perhaps rather than "client request" we could just use "config =
request", and rather than "replies back to the client" use  "responds to =
the config request" or similar?
>=20
>>=20
>>=20
>> Synchronous system - NETCONF/RESTCONF client/server interactions that =
processes all configuration operations as synchronous configuration =
operations.
>>=20
>> Asynchronous system - NETCONF/RESTCONF client/server interactions =
that processes all configuration operations as asynchronous =
configuration operations.
>>=20
>> [KENT] again, maybe we can collapse the number of terms from 4 to 2 =
by calling these "a/synchronous server" - what do you think?
>=20
> As per my first comment, personally I see this problem as being framed =
around how requests are handled, and besides I think that describing a =
system or server as being sync or async is open to many different =
conflicting interpretations.
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>>=20
>> Thanks again,
>> Kent
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_457148C1-D5B2-48F3-9AC9-A67F71612208
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

One comment.

On Sep 30, 2015, at 8:02 AM, =
Robert Wilton <rwilton@cisco.com> wrote:


 =20
    
 =20
  

    Hi Kent,

    

    Just some quick comments inline ...

    

    
On 30/09/2015 15:31, Kent Watsen =
wrote:

    

    

      
      

        [As a contributor]

      

        

      

      

        

      

      
        

          
I find =
that the term
            "system" is a bit ambiguous in this context.  It is =
talking
            about the NMS, the server, or both together?

        

      
      

        

      

      

        [KENT] I believe that we're talking about the
        NETCONF/RESTCONF/<foo> server, specifically in how it
        processes update requests.

      

        

      

      

        

      

      
        

          
Anyway, =
I've tried to
            define them relative to the configuration operations being
            performed.

          

        

      
      

        

      

      
[KENT] =
Perhaps these could be
          collapsed if we use the terms "a/synchronous server" =
?

    

    

    Personally, I think that defining the operations is arguably more
    useful because it is feasible that you could have a server that
    supports both sync and async operations and allows the client to
    choose which semantics should be used for a particular request.

    

    

    

      

        

      

      
        

          


            Synchronous configuration operation - A configuration
            request that the server applies synchronously with respect
            to the client request.  Before the server replies back =
to
            the client indicating the success or failure of the
            operation it MUST semantically validate the contents of the
            request and update the intended configuration of the target
            datastore.  If the request is to the running datastore =
then
            the configuration change MUST also be applied in the system
            before the server replies back to the client.  The =
reply to
            the client indicates whether there are any semantic errors
            or system errors from applying the configuration change.

          

        

      
      


      

      


      

      
[KENT]  This generally matches my =
understanding, but here are
        some thoughts to improve it:

      


      

      
1. I think the language "semantically validate" =
would exclude
        an ephemeral datastore.  We could put a qualifier on it, =
but I
        think it can be removed entirely as each datastore already has
        its own semantics around how it processes update requests.

    

    

    My aim here is potentially tied to the definition of intended
    config, were I am suggesting that the system has to at least have
    been checked that the request is well formed and any YANG
    constraints in the data model have been met, before it is accepted
    as intended config, otherwise it would be rejected.

    

    

    

      


      

      
2. I like how you call out the running datastore, =
but it is
        somewhat NETCONF-specific.  How about something like "If =
the
        request impacts the intended configuration (see term), =
then..."

    

    

    Yes your text is better and I agree that we should avoid making the
    description NETCONF specific at all.

    

    

      


      

      
3. "applied in the system" seems too open ended, =
how about
        this:  "...MUST also be propagated to and processed by the
        operational components of the server before..." ???

    

    

    So my aim here was to tie it back to the definition of "applied
    configuration", but this could probably be expressed in a more
    direct way, e.g. perhaps ".... MUST update the applied configuration
    in the system before the server replies =85"

If I =
understand this correctly, we are still talking about =93applied =
configuration=94 as configuration that has been written to =
datastore/hardware/line card etc. It does not imply that anything has =
come out of it, including whether the configuration is usable. That =
operating configuration (and I just introduced another term) will be =
reflected by derived state.

Is that =
true?


    

    

    

      


      

      


      

      
        

          


            Asynchronous configuration operation - A configuration
            request that the server applies asynchronously with respect
            to the client request.  Before the server replies back =
to
            the client indicating the success or failure of the
            operation it MUST semantically validate the contents of the
            request and update the intended configuration of the target
            datastore.  If the request is to the running datastore =
then
            the configuration change is applied to the system after the
            server has replied back to the client.  The reply to =
the
            client only indicates whether there are any semantic errors
            in the configuration change.

          

        

      
      


      

      
[KENT] For the most part, my comments on this are =
the mirror
        image of the comments made above.   One additional comment
        though, when reading in the first sentence "with respect to the
        client" I was thinking that these terms are actually independent
        of the protocol.  For instance, they could equally well be
        defined for a system that only had CLI access.  So, in that
        sense, the word "client" in the first sentence, and
        client/server elsewhere generally, may be ground for some
        confusion.

    

    

    Perhaps rather than "client request" we could just use "config
    request", and rather than "replies back to the client" use 
    "responds to the config request" or similar?

    

    

      


      

      
        

          


            Synchronous system - NETCONF/RESTCONF client/server
            interactions that processes all configuration operations as
            synchronous configuration operations.

            

            Asynchronous system - NETCONF/RESTCONF client/server
            interactions that processes all configuration operations as
            asynchronous configuration operations.

          

        

      
      


      

      
[KENT] again, maybe we can collapse the number of =
terms from
        4 to 2 by calling these "a/synchronous server" - what do you
        think?

    

    

    As per my first comment, personally I see this problem as being
    framed around how requests are handled, and besides I think that
    describing a system or server as being sync or async is open to many
    different conflicting interpretations.

    

    Thanks,

    Rob

    

    

    

      


      

      


      

      
Thanks again,

      
Kent

      


      

      
        

          


            

          

        

      
    

    

  


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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_457148C1-D5B2-48F3-9AC9-A67F71612208--


From nobody Wed Sep 30 17:04:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095D21AC405 for ; Wed, 30 Sep 2015 17:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbLBf3OmCvq8 for ; Wed, 30 Sep 2015 17:04:52 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 4C5D61A1A36 for ; Wed, 30 Sep 2015 17:04:52 -0700 (PDT)
Received: (qmail 6640 invoked by uid 0); 1 Oct 2015 00:04:49 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 1 Oct 2015 00:04:49 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id Pc4i1r00L2SSUrH01c4lAY; Wed, 30 Sep 2015 18:04:48 -0600
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=NEAV23lmAAAA:8 a=T0ZuanxOAAAA:8 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=OUUqdS4Chs7nh41d2QsA:9 a=QKmM6oexnOJmdO1L:21 a=TG-Ke7JHlMlUNfid:21 a=pILNOxqGKmIA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=9uUzcS5Nrb8A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=qx6pNcGEw2mPYmG+zUJ3rkH3lp5VVwuyy4kLf8bWIW0=;  b=Ilxppyqwz9jsQFMz+K+JbBzNmnxIQoEZSV6TGv4w8EAYZ7Gz9qHL1fRLD+dxklnN/SYiVpVd5d+k+ZE4x7bT/FtkIvuMjeRX1Xjtg1clI7NZ3Ea7ENUqzSjSE2eyJXJO;
Received: from box313.bluehost.com ([69.89.31.113]:36980 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZhRMZ-0007Tf-P8; Wed, 30 Sep 2015 18:04:43 -0600
To: Kent Watsen , Nadeau Thomas , netmod WG 
References:  <1501dae1b68.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
From: Lou Berger 
X-Enigmail-Draft-Status: N1110
Message-ID: <560C7897.5080800@labn.net>
Date: Wed, 30 Sep 2015 20:04:39 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Subject: Re: [netmod] Thursday Interim Meeting Agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Oct 2015 00:04:54 -0000

Kent,
    Thank you for the update.  A couple of points below.

On 9/30/2015 11:09 AM, Kent Watsen wrote:
> Hi Lou,
>
> We (the chairs) are in the process of closing the issues filed against
> draft-chairs-netmod-opstate-reqs.   There is a documented process (state
> machine) for this here:
> https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-track
> ing.  The issues are closed via WG consensus, specifically the VERIFY
> state confirms the consensus on the mailing list.
>
> So far we're off to a slow start - only 1 of 7 issues has made it to the
> EDIT state.  I believe progress is being impeded by a lack of
> participation from some.

Given the level of discussion to date and the previous statements by the
chairs, I hope you're not suggesting that we once again need to debate
each point before it's "verified".  In fact, at the last meeting I
thought I heard that each requirements was at least in the "verify"
state and that the chairs would soon make a call on mailing list
verification -- based solely on new issues raised.  Did I miss something?

>   Still, the WG will complete this work in time
> and publish an updated draft, so that it san be referenced by follow-on
> solution drafts, in both the NETMOD and NETCONF WGs.

So given the formal WG process, isn't time for the draft to at least be
a wg draft?

Thanks,
Lou

>
> Thanks,
> Kent
>
>
>
> On 9/30/15, 2:56 AM, "Lou Berger"  wrote:
>
>> Tom, chairs,
>>
>> At the last meeting, I believe I heard that a statement of consensus -
>> i.e., a consensus call -  on the requirements would be made by the
>> chairs,  
>> on list. (With the understanding that there are details of the
>> requirements 
>> that will need to be documented, presumably in a WG version of the chairs
>> requirements draft.)
>>
>> Are we at the point yet were this call can/will be made?
>>
>> Thanks,
>> Lou
>>
>>
>>
>>
>>
>> On September 29, 2015 3:53:56 PM Nadeau Thomas 
>> wrote:
>>
>>> 	After going over the plan with Kent, we would like to continue the
>>> agenda 
>>> from the
>>> last interim meeting on Thursday. That is to say, Kent will continue
>>> with 
>>> the comparison
>>> of solutions.  From last time and in parallel with this, the WG
>>> discussion 
>>> around the requirements
>>> seems to be converging on a detailed level of refinement of the
>>> requirements.  We will
>>> recap the status here and goals.
>>>
>>> 	The details of the meeting are here:
>>>
>>>
>>> The NETCONF Data Modeling Language (netmod) Working Group will hold a
>>> virtual interim meeting on Thursday, October 1, 2015 at 10am EDT (7am
>>> PDT; 
>>> 2pm GMT).
>>>
>>> The title is Openconfig Solutions Discussion (continued).
>>>
>>> The WebEx is:
>>>
>>> Meeting number:640 686 530
>>> Meeting password:1234
>>> Audio connection:
>>> 1-877-668-4493 Call-in toll free number (US/Canada)
>>> 1-650-479-3208 Call-in toll number (US/Canada)
>>> Access code: 640 686 530
>>> Meeting link: 
>>> https://ietf.webex.com/ietf/j.php?MTID=mf12aa8d28a159614cb415f2f32dcbebf
>>>
>>>
>>>
>>> 	--Tom (as WG co-chair)
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>